bpreis

QUOTE (Omar Mussa @ May 16 2008, 03:18 PM) We're considering* an improvement to the Locate Distributions feature. The improvement we're considering might* work something like this: In the example of DCD May '06 vs. DCD May '07, if the system detects that the original distribution by which the part was installed is May '06, we will ask for that, but now the user will have an opportunity to tell us they don't have the original distribution, at which point we'll ask for an alternative distribution that 1) had been installed on the system at some point and 2) is known to contain the exact same missing part (which could be DCD May '07 in this example). You might* be able to try this feature if you're a beta member, possibly*. *Use of safe language intentional so as to avoid volcanoes, earthquakes, and otherwise violent reactions from the gods.

The Additional Installers list is built from files found in C:\Program Files\National Instruments\Shared\MDF\Manifests. The xml files there represent the additional installers and their dependencies. The fact that your Additional Installers page is missing some installers, like the LabVIEW 8.5 RTE, would suggest that the files representing those installers are not present. But since you found those installers in the ProductCache folder, I'd expect there to be a file in the \Manifest folder as well. I recommend going to Add\Remove Programs> National Instruments Software, then select all and press Repair. -Bob QUOTE (PalamarTM @ May 15 2008, 05:27 PM)

QUOTE (Cat @ Apr 9 2008, 09:50 AM) While that does work, you might run into trouble later wrangling new support files into the installer build spec. New support files could be produced by rebuilding your exe if it links to additional dependencies in the future. Something you might want to try is assigning a unique folder name to the Support Directory in each exe build spec. You can do this on the destinations page, clicking Support Directory and changing the default folder name from "data" to something else. Alternatively, you could try putting each build spec into its own unique parent folder so that the data folder contents from your exe builds won't have a chance to collide when adding them in the Installer Builder.

QUOTE (Aristos Queue @ Apr 25 2008, 01:13 AM) I believe the wait functions (Wait Until Next ms Multiple and Wait ms) wired to zero are another, slightly more intuitive way, to do this. It had a few practical uses in LV RT.

QUOTE (orko @ Apr 7 2008, 12:05 AM) It's just VI Server calls to the Project API to add files, however, it's a little more complicated when adding targets. You might find resource\Framework\Providers\lvdesktop.llb\PC_New.vi useful. Pass it your project reference and the project's "Root" reference (to the "Item" input). The "BehaviorGUIDs" input allows you to restrict the displayed results. The RT and PDA project wizards for example would use known BehaviorGUIDs so that the dialog only presents supported target types. I'm not sure how liberal we are about giving out GUIDs and such and I unfortunately don't have a list of all the possible BehaviorGUIDs anyway, but some other LV person (or PSE) who trolls here might be able to help you more with that particular input. After invoking that VI, you should be able to continue operating on the project refnum by adding files to your new target with VI Server. If you're dealing with shared variables, be aware that much of their VI Server interface is private, but there is a primitive VI-based API in vi.lib\variable\* that might help. Good luck!

QUOTE(venkatesh @ Dec 30 2007, 11:24 PM) Hi J. Venkatesh, I viewed your attached error message: "Error loading 'nilvaiu.dll'. A dynamic link library (DLL) initialization routine failed." Unless this is related to the Application Builder or Installer Builder features of LabVIEW, you might have better luck posting this topic to a more relevant LAVA category. Did you build an executable or installer with a VI that requires this DLL? From your description, it sounds like this error dialog occurs when you simply drop a Measurement I/O VI on the block diagram. -Bob

QUOTE(Justin Goeres @ Dec 6 2007, 10:34 PM) I've uploaded the zip file again to the same location.

I'd start by changing the batch file to echo on pause register.vbs pause to verify that your vbs actually runs and see what the call to register.vbs is returning QUOTE I think Ton is on to something here. It's possible register.vbs is not being called at all if the current working directory is different from the install directory. In that case you should try: echo on pause cd "%1" register.vbs pause and modify the Installer Build spec to pass "[iNSTALLDIR]" (with quotes) as a command line argument. %1, %2, etc is the syntax used to access command line arguments passed to a batch file. -Bob

QUOTE In LV 8.2 (maybe even earlier) you can browse VI Server properties and methods with Ctrl+Shift+B.

You can try the /u parameter, but I didn't see any support for it when looking at some internal references. Also if you don't have access to the setup.exe file for some reason after installing, this wouldn't work. Another thing you could try is installing a shortcut file configured to launch Add/Remove programs. It's not ideal but it saves you some mouse clicks. QUOTE

<--- Lurker since '03, but graduated from lurker to n00b forum troll recently.

Hi Staffan, The missing/renamed files issue you're seeing might be the same issue Justin was seeing. I've updated Justin's thread with the CAR # (4E2BHO5U) for tracking purposes. Here's a link to some files that seemed to help Justin work around the issue: ftp://ftp.ni.com/outgoing/vi.lib.zip Let me know if this helps.

Hi Staffan, The behavior you're seeing is expected and is documented in the 8.5 readme (readme_AppBldr.html). Basically lvlibs are not treated like containers in app builder, starting with 8.5. As to why that decision was made, I'm not sure, but I do know it's intentional. QUOTE I don't think this is related to the problem Justin was seeing, but if you happen to encounter more installer builder problems after applying the workaround mentioned above, feel free to post a followup to this thread. Thanks.

For reference, this has been documented in CAR 4E2BHO5U.

Justin, Sorry for the delay - got a lot on my plate atm . I downloaded your sample project and saw exactly the symptom you described. However, I noticed that when I delete the exe build spec from the Destination View of the Source Files page of the installer build spec, then re-add it, the tree information is re-populated correctly. It's only after I click OK (closing the build spec editor) and re-open the build spec when I see the bug appear. It's messed up in the same way on all subsequent loads. Another weird thing I noticed was that even though only one of the files appears to be incorrect in the UI, the XML seems to tell a different story - seems that both Write Numeric.vi files have the wrong FileTag I'm still investigating, but wanted to let you know I'm on the same page -B

So if I understand everything, You started with an exe build spec, which builds correctly. Your first pass through the installer builder lets you add files on the source files page, but the icons are all wrong in the project view, while the files all look correct on the destination view. After closing and reopening the build spec, the source file page has deteriorated further - icons are still messed up in the project view and the destination view now has completely wrong file information After all this, the installer builds fine and installs fine, but there are files the exe cannot find that happen to belong to classes (and an lvlib?) I'd agree those xml tags look wrong, like we somehow switched up the files when gathering information from the UI. Do you have a set of steps or files I could use to recreate the exe and installer build specs to reproduce the problem? Ideally, I'd like to make an exe, which hoses my installer builder source files page like what you've shown in the screenshots. I suspect it'll cascade into similar problems from that point on. Sounds like one key to this puzzle is to use classes and possibly an lvlib in the exe build spec. Let me know if you have more specifics on how to get into this state. Thanks.

Hey Justin, That looks like a pretty major problem. Do you have some code you'd be willing to share - perhaps not the entire project but enough to reproduce what you've seen? Thanks.