kennoncotton

QUOTE(LaserDrive @ Apr 19 2007, 11:02 AM) Or if you are using 8.2 you can right click on a build specification and choose Duplicate, to get a new copy of the build spec. And as part of duplicate on an installer spec Application Builder will generate a new Distribution ID and Upgrade Code, so that the new installer spec generates an installer that won't do an upgrade / uninstall of the output of the original installer spec. We had the Product Code visible prior to 8.0 in the UI as an indicator and you could generate a new one, mainly because it seemed common to reuse a .bld script to generate a new exe (new program, not just new version) and you probably didn't want the installer to upgrade. We took it out of the UI in 8.0 because we thought with separate projects people wouldn't run into this as much. We are contemplating putting back in, but for average Joe LabVIEW User it is a little strange to see a GUID like that, even more so to see 2. And if we put it back in it would probably be as a control so that you could have 2 installer specs with the same info if you wanted them to actually affect one another. I guess that is the real dilemma is it more common to want to set these codes to be the same (need to be able to set them in the UI) or to want them to be different (just an indicator or not visible at all)?

QUOTE(crelf @ Apr 10 2007, 11:23 AM) LabVIEW decides whether to use a relative link or system search path based on what you type into the 'Library name or path' control in the Call Library Function configuration dialog. If you put just a name, when you press OK LabVIEW will search your system path (and then your VI Search path, I think) for the library and load it from there. If you put in a path when you press OK LabVIEW will verify the DLLs existance and store a relative link from the VI to the DLL. Using just the library name does mean if your path environment variable is different on different machines you may get a search dialog on other machines. And yes if the DLL is different on different systems you could have trouble, if there is a function available in XP that is not in 2000 your VI will be broken, if the parameters differ the call could fail, if the underlying code is different then the behavior could be different. The OS calls I've used and seen others use Microsoft generally does a good job keeping the API compatible (at least on all NT OSes, 9x<->NT has differences). If there is a difference in the API then a case structure or conditional disable or dynamic VIs can be used to call the correctly configured instance. I would say in general it is a robust enough thing to do, but obviously test on all the platforms, specifically in areas where you are concerned there may be a platform difference. The http://sine.ni.com/devzone/cda/epd/p/id/4935' target="_blank">Windows Utilities LLB for instance has been around since LabVIEW 4 and Windows 95? / NT 4? and still works. There is a DLL included in the .zip but many of the VIs call directly into the Windows DLLs

Actually Application Builder will determine if the DLL used in the Call Library Function Node is a system DLL / whether to include it or not based on the way it is referenced in the Call Library Function Node. If you have the full path to the DLL in the Call Library Function Node (c:\windows\system32\win32.dll), LabVIEW will store a relative link from the VI to the DLL and Application Builder will copy it assuming that it is not a system DLL. If the Call Library Function Node only contains the name of the DLL (win32.dll), LabVIEW will not store a relative link and will search the system path to load it and Application Builder will not copy it assuming that it is going to be in the system path of any machine you are going to put the DLL on. Since you did not include the DLL directly in your project or build specification, I suggest checking all the Call Library Function Nodes in your application. Load your start up VIs and dynamic VIs and go to Edit>Find and Replace and search for the Call Libary Node. You should be able to open each one you find to see where win32.dll is being called and change it to just have the file name and not the full path, save the VI and then try building again. If it happens to be a VI from NI let us know and we'll fix the VI. Kennon

QUOTE(machyaer @ Feb 23 2007, 05:23 AM) Max, There are a couple of command line arguements that you can pass, INSTALLDIR and DISTROOT, in the Run executable after installation portion of the Installer Properties that will give you the information you are looking for. Here is a link to the help topic for that dialog: http://zone.ni.com/reference/en-XX/help/371361B-01/lvdialog/adv_installer_settings_db/' target="_blank">http://zone.ni.com/reference/en-XX/help/37...er_settings_db/ Kennon

The limitation is not the long, qualified in memory names, they will stay "long" after the build process, the problem is the filename on disk. On disk LibA.lvlib:ClassA.lvclass:anything.vi is c:\somewhere\anything.vi, if you have 2 Project Libraries that have anything.vi in them, then they must be in separate folders because the OS won't allow them 2 files of the same name to be saved in the same location on disk. Or they have to be in separate LLBs because a LLB is a essentially a single directory. So your project has 2 VIs of the same filename in memory because they are different qualified names and life is great in the development environment. When we build an app we essentially create a single LLB of all the VIs and stick it into the EXE, unless you create multiple destinations and specify parts of your source to go to those different destinations. So those 2 files of the same name are going to be stuck into the same LLB, which means either we fail because you are putting 2 files of the same name in the same directory or we let the last one copied into the LLB 'win' or we rename the duplicates and update all static linkages. We chose to rename any duplicates going to a destination and update the static linkages and since we don't know about the dynamic linkages we give a warning about them being renamed. The thought was more of the links are probably static and would be updated so the EXE would work without any further problem. If you are calling VIs dynamically I recommend you create additional destinations and put each Project Library in its own destination, this does require you add logic for where the VIs will be found when in an exe, but it allows the file names to stay the same. One other caveat about when we do a rename is with LabVIEW Classes and dynamically dispatched VIs, as mentioned those must have matching names so when App Builder finds one it will not put it in the EXE by default but rather create a separate folder for it and put it outside so that its filename can stay the same. This is the way it is going to have to be until we either stop using LLBs as the internal storage mechanism for EXEs or make LLBs support multiple files of the same name being stored inside of them (seems like that would be confusing). I know that doesn't solve the rename problem, I'm honestly not sure when or if we will do that, but hopefully understanding what is going on will help you be able to handle it better. Kennon

The VIs you mention in 1 is the BuildTargetBuildSpecification.vi, well that VI is the supported way of programmatically building an app/dll/installer. A global is no longer used to pass build progress information and there isn't a supported way for you to view that information. Generally with a programmatic build I would think you are calling it from the command line / a batch file that is scheduled to run at a certain time (overnight?) and you don't want to have anything show at all or you don't need anything to show. I'm trying to figure out why you want a programmatic build but are going to be watching it so you want to see progress and be able to cancel. What does Build, Build All or a multi select and Build not give you that you need? Is it a pre build or post build operation that you are doing? Kennon

The LabVIEW Installer Builder doesn't currently support that. However a recursive file listing of the Installer Destination directory will return that set of files, the only problem is it will also return any other files that were prevously there. We do clear some of the subfolders that are generated, like Volume\Bin, but the main folder just gets files copied into it. BTW 8.2 has a Recursive File List VI on the Advanced File IO palette, it exists in 8.0 as well in <vi.lib>\utility\libraryn.llb\Recursive File List.vi. This also isn't currently possible. We intentionally made the programmatic build be completely non-interactive, not to show any UI. Are you wanting the progress dialog to track the progress of the build or to be able to cancel the build or both? I can see us possibly adding an option to show the dialog, but it would be off by default. Kennon

Okay, I didn't think about the DLL being called through a CIN, but the intent of my response is still correct, you need to do some work further up the build chain process to fix the problem. I would say either A) don't include it in the EXE build and instead add it in the installer or B) change the where it is going in the EXE build spec and if necessary where the CIN looks for it. A) If you don't include it in the EXE build, you'll have to manually copy the DLL on your build system to get it to work, but you could include it in the Installer to go into windows\system32 so the EXE will work on your target systems. This is the quick solution. B) A more complicated solution but maybe more "correct" is to modify the CIN so it can find the DLL when the VI containing the CIN is used in the Run-Time Engine / an executable and put the DLL in that relative location in the EXE build instead of in system32. It would then propogate to the Installer build in that relative location. Also I was able to reproduce the behavior of the Installer builder moving the .dll into the [ProgramFilesFolder]\Browser, but I wasn't able to have it automatically make a second copy if it in [systemFolder] with out selecting it from the project and including it there, can you tell me how to reproduce that or email me an example of code that is exhibiting that behavior. Kennon

I think you should be able to remove it but it will need to either be done in the EXE build Specification or in the Call Library Nodes for the DLL or both. Basically the Installer builder attempts to keep all the files in the same relative place from your EXE build because we don't want to break VI linkages or change them while building the installer. It expects that you have everything configured the way you need it in the EXE build and you need to include that exact image. This works well when the EXE is built into one main destination folder and its subfolders, but can break down with items that are linked to are in folders that only share the root folder (c:\) in common, like your EXE preview shows, or the relative paths require going up several folders and then back down. I think what is happening here is the Installer builder is adding zlib.dll to [ProgramFilesFolder]\Browser because it can't calculate a good relative path up out of there to where the EXE builder says it should go. And I'm assuming that you added zlib.dll to the [systemFolder] manually in the Installer(which is the right thing to do). Based on the EXE preview I'm assuming you are either manually including zlib.dll in the EXE build, because it was not there or you manually changed its destination from the Support Folder to system32? Solution A: If you are manually including it in the EXE as a Support File I suggest removing it, because it is in the System folder the linkage to it doesn't get updated and it will be found there. And only manually including it in the Installer Build going to the System folder Solution B: If you are manually changing its destination in the EXE build to go to the System folder, I suggest changing the way the Call Library Nodes are configured. Since the DLL exists in the System Folder it is in the search path for the system and LabVIEW will find it there, we don't need to store a relative link to it. So go to each Call Library Node and make sure you only have the library name listed "zlib.dll" not the full path "c:\Windows\System32\zlib.dll" This will indicate to LabVIEW the DLL resides in a folder in the system search path and it won't store a relative link to it, so the EXE builder won't put a copy of it in the Support folder so it won't be part of the EXE preview or the files the EXE builder tells the Installer Builder to include. But you will have to include the DLL manually as part of the Installer Build so that it is guaranteed to be on the system the installer is run on. Kennon

Willy, You can buy Application Builder and install it on LabVIEW Base or Full Development Systems. If you have it installed on Base or Full it should up under Add Remove Programs. It is possible that instead of being installed App Builder was copied to that machine and not everything was copied that it needed. I suggest getting the installer for App Builder 7.1 Kennon

Willy, Based on what you said I think the problem is due to some missing files in the <labview>\applibs folder, something that shouldn't happen so there isn't a great error for it. Check to see if you have dllshell.lib and lvapp.lib there, if they aren't, I recommend going to add/remove programs and choosing to repair your installation of App Builder or LabVIEW Pro. Kennon

No problem. Sorry this post took a while, it has been a busy week figuring out what we need to be working on based on all the feedback from NI week. Hmm, I was thinking that you would be using this VIs as subVIs not as subpanels. From the testing I've done, I can run a VI from another EXE as a subVI (call by reference) but I can not insert it into a subpanel. It sounds like you have some common UI modules/reuse code, not just a common API or non-UI reuse code, I think my option 3 of doing a source distribution makes the most sense for your setup. I've got a nice autographed copy of that same reference sitting on my desk here, Thanks Jim. You might be having the same problem I had initially in that I didn't have localhost wired into "machine name" on Open Application Reference. I have to admit I didn't compeletely write out a test for this option before I suggested it. But I've cobbled one together between meetings yesterday and finished it up this morning. Basically the attached project builds 2 EXEs. One contains A.vi and B.vi. A.vi opens a reference to B.vi that shows you can use a path with <foo>\some.exe\<bar>.vi in an exe to call VIs that are in that exe. The other EXE uses VI server to access the first EXE and call B.vi, it also tries to insert it into a subpanel, which fails. To show you can view the panel I added an open panel and a loop with a wait to keep it around after the reference closes. One caveat is the first EXE must be running (well at least open) for the second EXE to access it's VI Server, the old method of calling a VI right out of another EXE didn't require it be open. So this should show what is possible using VI Server (or the ActiveX server) abilities of an EXE, but I do think you need a more modular approach on these common features and create a source distribution(s) for them. Hope this helps, Kennon Download File:post-624-1155914696.zip

Todd, Yep in 8.2 we made a change that "fixed" being able to take a .exe (or .dll) rename it to a .llb and view its contents, at least on Windows. Some people have been worried about this being a "security" hole because you can see the VI names and connector panes if you have the same version of LabVIEW the executable was built in. But you can't see the block diagrams or most of the front panels (just the ones you specifically kept), so I don't know how much of a "security" issue it was but it certainly bothered some people. Now if you had debugging turned on in 8.0, App Builder kept the front panel and block diagrams so it really did have your all code, but you shouldn't be handing out debuggable exes. The reason we changed this behavior wasn't for this security issue, but for compatibility with the upcoming Windows Vista. In Vista you can / need to sign your executables (I'm pretty sure XP supports this as well and 2000 might) to show they are legit and if you signed a LabVIEW built EXE or DLL made in 8.0, the EXE/DLL stops working. So we changed the way we put the VIs into the EXE/DLL so that signing the EXE wouldn't "destroy" it, and as a result you can no longer see the contents of one by renaming it to be a .llb or access VIs in it by path from outside of the EXE. As the person who told you that would still work, I think I did misunderstand your question or didn't communicate my answer well, so let's get it in writing . You can still call VIs that are in an EXE, obviously ones you are calling directly/statically but also dynamically through VI Server. But you can only call them dynamically from a VI is in that EXE or running in that EXE's application instance. So if c:\myapplication.exe\a.vi dynamically calls c:\myapplication.exe\b.vi it will work but if c:\foo.exe\d.vi tries to dynamically call c:\myapplication.exe\b.vi it won't work. The reason is sort of related to the Application Instances that Michael referenced, in that c:\myapplication.exe\* is a valid directory for VIs that are in the Application Instance created when c:\myapplication.exe is run, but more that .exes are no longer essentially .llbs (at least on Windows, the didn't change on Mac or Linux). So what do you do about this change of functionality? There are a couple of choices I see: 1. You are basically treating these VIs as exported VIs. So one option would be to create a DLL out of them and have all your EXEs call that DLL. This would make your executable code more modular and is probably the best design choice of these solutions and maybe the least work. 2. Another would be to configure the EXE build specification to have these VIs reside outside of the EXE in a folder or LLB next to the EXE. The problem I see here is making sure all the subVIs the VI you are calling needs are not in the .exe otherwise they won't be found. The work here would be to keep up with the subVIs to make sure they are all outside the EXE. 3. A source distribution of the exported VIs would sort of be a combination of 1 & 2. It would provide DLL modularity, as you would call the exported functions dynamically and would be making the LLB I mentioned in 2 it's own build. Probably the same amount of work as #1. And since you are using LabVIEW to call the VIs, it probably makes more sense than #1 (DLL is best for C++ calling VIs) and would be my recommendation. 4. Enable the ActiveX interface for the EXE you are calling into and use the VI Server ActiveX interface to run the VI (Get a VI Reference, Set the Control Values, Run the VI, Get the Indicator Values), this is a lot of work for the caller of the function and a little for the build specification. 5. If you enable the VI Server for the application you could open an Application reference to that port on your local machine and then use Open VI Reference and call the VI as you did in the past. While it isn't much more work for the caller, you do have to keep your ports numbers straight and keep up with the right settings in the ini files for the EXEs. Alright I've typed enough, Kennon

They should be on the shelves at your local Best Buy, Target, etc. I haven't been to see the Powered by LabVIEW logo on the box yet, but I know some guys who have bought them at a local Target already. So if you need to bring one to NI Week you can stop and pick one up before you leave. I haven't heard anything about them being sold at NI Week, but I haven't asked either. Kennon

Fred, Sounds like you need to modify your project file from the Project Explorer window to add the files you are interested in to your project. App Builder only lets you include files in your build that are in your project. So from Project Explorer right click on My Computer and choose Add File or drag and drop the files under My Computer or choose Project>Add to Project, I'm sure there are some other ways too and you might want to check on help topics about adding files to the project. Kennon

Maybe a the topic is drifting but size is an issue to be concerned with and we do need to consider the entire build & distribution process with respect to size, not just the EXE portion. The run-time engine is big, and installer size (thus download size) is probably more of an issue now that EXE size (although the EXE has to go into that installer). We are looking at ways of trimming the RTE down. Of course we are also looking to add more features to LabVIEW which adds more to the RTE. I don't have any progress to report on it getting smaller but I will pester the right people about it. Kennon

Tim, Sorry I took me a while to respond to this after I said I would in that other thread. Ok, so the other thread mentions that in general if you have an EXE that has plugins, the EXE needs to have everything it needs to run and each plugin should have everything it needs to run, in case the EXE changes or some of the plugins aren't in memory. So that should be it for the 1003 error, right? Well there is new way in LabVIEW 8.0 that you can end up with a 1003 error on your plugin VIs if they use VIs from Project Libraries and your EXE uses VIs from the same project Library. You mentioned Mean.vi which is probably one of the VIs that is broken in your plugin and it is part of a Project Library. Also you probably don't have any of your user.lib VIs in Project Libraries, so that is why you are seeing a difference. The other way to get this 1003 error is by trying to have 2 Project Libraries of the same name in memory at the same time. This doesn't happen in the development environment because there is only one copy of each Project Library. However in an EXE with plugins, where the plugins were built separately from the EXE (Method B from the other post) you can end up with a copy of the .lvlib in the exe and another copy in one or more of the plugins. This seems harmless since the first one in memory is the one that is used (just like VIs), but during the build process we remove unused members of the Project Library in the EXE. And since a VI knows which Project Library it is a member of and a Project Library knows its members. So if the Project Library is already in memory and a VI is loaded that says it is part of the Project Libary, but the Project Library doesn't think the VI is part of it, then the VI will be broken. I think this why you are seeing the 1003 but it works when you load the vi.lib VIs from vi.lib since in there is only one copy of the Project Libraries being used and no references have been removed from them. Lets take a specific example where you are using some of the Analysis VIs and the EXE only uses Histogram.vi and the plugin only uses FIR.vi (I got a CAR on this last week and wrote a long explanation that I'll copy and paste): When the exe is built it includes NI_AALBase.lvlib and Histogram.vi in the exe, since Histogram is the only item in NI_AALBase.lvlib used by the exe, App Builder by default removes all the other references that NI_AALBase.lvib has. The new copy of NI_AALBase.lvlib inside the exe is essentially a Project Library with one item referenced in it (there may be some subVIs if Histogram has any that are part of the .lvlib). When the Source Distribution is built the new copy of NI_AALBase.lvlib inside the source distribution has all its references by default because Source Distributions keep them. Even if you trimmed it down in the Build Specification it would only have a reference to FIR.vi which wouldn't be helpful either. As I said, a VI knows what .lvlib it is a member of and a .lvlib knows what VIs are part of it. So when the EXE is launched it loads the EXE's copy of NI_AALBase.lvlib into memory. Then the EXE is calling the Source Distribution as a plugin so the VI being called tries to load FIR.vi which knows it is part of NI_AALBase.lvlib, well that is already in memory, so the Run-Time Engine can't load the source dist copy of NI_AALBase.lvlib because a library of the same name is already in memory (so it doesn't matter what links that copy contains). But the copy of NI_AALBase.lvlib in memory reports it doesn't have FIR.vi as a member of it (remember the EXE copy only has a link to Histogram.vi). So FIR.vi is broken because its owning .lvlib isn't found. The removal of non-essential items is basically a size optimization, so what can be done? Well, not be optimized, by including the entire Project Library into the EXE and the source distribution. That way the 2 new copies of NI_AALBase.lvlib will have links to all the items in it, so the first one loaded will respect everything else. Either 1) move the NI_AALBase.lvlib out of dependencies into the tree with the rest of your source and include it as a Dynamic VI in the EXE build and Always Include it and its sub items in the Source Distribution. There will still be 2 copies of NI_AALBase.lvlib but they both contain links to all of the items in the Project Library, therefore which ever one loads first, it won't prevent other VIs from running. Also all the items directly referenced by NI_AALBase.lvlib and their dependencies will be included. Or 2) Uncheck "Disconnect Type Definitions and Remove unused Polymorphic VI instances", that also removes unused .lvlib components if it is checked (maybe we should make those separate options). This will cause all the contents of NI_AALBase.lvlib to be included and the contents of all the .lvlibs it links to. Since NI_AALBase.lvlib contains VIs that have references into NI_AALPro.lvlib, all of it and its dependencies will be included, even if they aren't used by the code. So this can get very big and I wouldn't recommend it (for .lvlibs without circular links, this would be okay). With method 1 you could also build the .lvlibs and the files referenced by them and their dependencies into the same location on disk. That there would only be one copy and each build would overwrite it. I have some thoughts on how to make this better for future versions of App Builder/LabVIEW, but right now it only takes what you tell it you need or it takes it all. Kennon

This will work and the uninstaller should still remove the EXE even if the version number has been updated. Make sure you include and new dependent files (new DLLs your EXE might be dependent on). This would be the way to go, make sure you bump the version for your installer. When it runs it will "patch" your system by removing the files you previously specified in the installer build and install the new set of files and leave the drivers (additional installers) alone. Of course if you have upgraded one of your drivers since the last release of your software you should include that new version so that the end application will run as you have been using it. Kennon

Chris, Sorry to chime in late, but I didn't notice this thread until you mentioned it on the Champions Forum. As others have pointed out your -1003 error is most likely due to missing subVIs. And as mentioned VI links are stored as relative links (the only time they might be absolute is if the linkage spans between drive letters, I think but I haven't tried it lately). It is all about location and knowing what you need to include in your distribution, basically each plugin needs to have all its dependencies available in the spot it expects or somewhere in the VI Search path. So yeah I'm agreeing with everyone here so let me try to throw out a couple of new things to help. (Tim some of this will apply to you as well, I saw your thread and started a reply but didn't finish it) Since you are using LabVIEW 8.0 you've got a couple of things you could do to build your plugins: A) When you define you EXE build specification you can choose to create multiple destinations and have your plugins go into those. Such as a .llb for each plug in. This can be done on by creating new destinations on the Destination Page and checking whether or not the destination is a .llb. Then on the Source File Settings page you can specify which destination files or folders are going. The tricky part is having your dependencies in the project so you can specify them to the different locations easily or to a common location. The good thing about doing this through App Builder is your VIs will get relinked for you even though they aren't all in the .exe file. Also by doing this through the EXE builder you'll only have one copy of your dependencies. B) Create your EXE through the EXE build specification as you have already done. Then for each plug in create a source distribution for it, where you remove diagrams and set other settings. Source distributions are new for LabVIEW 8.0 but you can think of them as the old Save with Options on steroids (or on crack if you run into a problem ). So by doing a Source Distribution per plugin you'll get the plug-in VI plus all its dependencies linked into a new hierarchy of your choosing (you can have it all in one .llb or use the custom packaging to make what ever hierarchy you want. Like building an exe all the linkages will be updated. However if 2 plug-ins use the same subVI unless you plan for that in your building, you'll have 2 copies of the VI on disk. This isn't bad unless the 2 VIs are different some how, the first one loaded will "win", etc just like in the development environment. I'd recommend method A if your list of plug-ins is "static" meaning you know for this release you have 3 plug-ins but you want them to be dynamic so that all the hit for loading doesn't happen up front or if a plug-in might not run if a certain hardware isn't installed. Method B would be if you wanted a dynamic set of plug-ins and plan on adding them without updating the exe. Hope this helps some. There is a problem I can think of with .lvlibs using method B that I'll explain on a reply to Tim's post. Kennon

Louis, I checked with the developer who is responsible for the configuration file VIs and he hasn't heard of any reports of LabVIEW 8.0 or the 8.0 installer updating them. We verified on a machine with 7.1 and 8.0 that they aren't updated, so either you found a way to cause this to happen or inadvertently got those VIs loaded from 7.1 and saved them. I know I've done that before, you probably have 2 or 3 copies/versions of LabVIEW on your machine, I've got 10 (5.1 through 8.0.1, and some newer ones ), so I'm always asking "which folder am I loading this from?" and occasionally getting it wrong. Besides uninstalling verifying the files are deleted and reinstalling, another way to go about it is to delete the .llb and then do a repair on LabVIEW 7.1 from Add/Remove Programs, this should reinstall the file, and take less time (I think). My thought on why the installer didn't overwrite the file has to do with the rules that MSI (Microsoft Installer) uses for determining whether or not to overwrite an existing file. Here I think what happened is MSI chose not to overwrite the file, since .llbs are not versioned with a Windows version resource (you can't see a version number on them in Properties under Windows Explorer) and the file had been updated. I'll check with Jennifer to see if she turned up any else. Kennon

Lee, Project libraries and namespaces are great but you do run into a problem when we try to stick all those VIs of the same name into the same folder (or .llb) on disk. So what to do, should App Builder error out about the file already existing? Not everyone is calling code in their .lvlibs dynamically so they don't care if the files get renamed and the static calls get relinked, as long as the code still works. We decided to rename them if they are going to the same location and report a warning instead of an error: The warning appears in the dialog when the build finishes but you have to click the twistie to see it. This will tell you what was renamed after the fact, which doesn't help your code looking for the dynamic VI. I'd advise against trying to figure out how things get renamed, it depends on where the VI is in your hierarchy which of course can change and would be hard to keep up with. So what I recommend is building each project library into its own destination. You can create multiple destinations with App Builder and in 8.0 choose which VIs go into which location. I think a .llb per .lvlib might be in order. You can create the destinations as .llbs right next to your exe or in a sub folder on the Destinations page and then on the Source File Settings page set the .lvlib to go to that destination and check the box to set the destination for all contained items. Now since you are calling VIs in the .lvlib dynamically, you'll need to modify the location you look for them at based on whether or not the call in VI is in the run-time system or development environment. This would be information to include in the instructions on how to use your .lvlib Another thought is to have a VI in your .lvlib that does the dynamic call, but has a unique name that your code outside the .lvlib calls statically. This would be okay if you only have a couple of dynamic calls but would get out of hand if you had a lot of them. I don't want to give up on namespaces yet, so I'll say no, but that would make things easier in this situation. Kennon

Louis, It looks like the portion of App Builder that builds the installer is broken for some reason. The main App Builder dialog launches calls that by reference since it is only valid for Windows, and that is why you are getting the 1003 error about an Open VI Reference. So I doubt you have modified anything inside of <lv7.1dir>\project\wininstall.llb or inside <lv7.1dir>\applibs\distkit\NiMsiDistKit.llb, so the only thing I can think of is the DLL that is called during the installer build process is missing or has been modified. Do you have <lv7.1dir>\applibs\distkit\NiMsiDistKit.dll on your system and is it version 7.0.5? Also do you have <lv7.1dir>\applibs\distkit\MergeMod.dll on your system version 1.10.1029.1? You need to have those 2 files which are installed by the App Builder / LV PDS installer, if you don't have them try to repair your installation. You could also try opening <lv7.1dir>\project\wininstall.llb\Win Install Create.vi to see why it is broken. It is password protected so it might not tell you much. Kennon

Hmm, well, when you open the VI reference you might want to see if the property "Modifications:VI Modifications Bitset" is not 0, if that is the case then the VI has been modified and if it has relinked to subVIs, I think. If you can narrow down a set of code that can reproduce it let me know and I'll append it to the CAR. We enjoy keeping up what ya'll are up to with the features we work on. Not everyone in LabVIEW R&D posts or some of us don't post much but there are always good things to read on LAVA and info-LabVIEW.

Norman, The quick answer is no, application instances can be thought of as 2 separate LabVIEW executables running on the same machine and what goes on in one should not stop execution in another. Notice I said the word should. There has been a report or two of getting into a similar situation. I think what is going on is you have a VI that is running in one application instance (NI.LV.Express) and when that VI is opened in another application instance (lets say Main Application Instance) it needs to be compiled/edited for some reason. LabVIEW recognizes the need to recompile and wants to propagate those changes to the other application instances. However the VI is running (or reserved for running) in the first application instance and therefore can't be edited in the second application instance. LabVIEW is waiting for the VI in the first application instance to stop running, before it runs the VI in the second application instance. Does this sound like what you are seeing? I wasn't 100% sure about this, so I spoke to one of the architects who worked on the application instance. He agreed with the assessment. So I guess to workaround you'd either have to figure out why LabVIEW is trying to edit or recompile the VI or have 2 copies of the code or maybe call it dynamically from your express VI so it isn't running when you open it in the other application instance? There is already a bug report about a similar scenario, so rather than filing another one, I've added a link to this thread. And since I've some interest in knowing which CAR number goes with a problem, the CAR number is 3U1EGOF2. Kennon