JaysonR

Cool. As I mentioned above, the best thing would be for the 'build all' button to detect dependencies and build the specs in the proper order. That way, the order shown will not matter.

That is definitely what we have desired, but that definitely a lot more complicated to do correctly. I think it's safe to say that won't be in SP1, but you'll get a fix for your issue

I have taken ownership of the CAR and will try to see that it gets fixed in SP1.

making them alphabetical and then sorting them will arrange them correctly. Then you need to change the sort to custom and change the names back again. So that is one work around. But an annoying one at best.

I understand that it is annoying, and I will try my best to make sure it gets fixed. Why do you need to change the names back again? In the meantime, is it not possible to just pick names that will allow it to be sorted the way you want it all the time?

I assume that the reason it's out of order might be that build specs are sorting by either name, path or type? Perhaps a workaround would be to name the build specs in such a way that when you sort them alphabetically, it will put them in the order you'd want to build them?

I see what the problem is, and I will make sure that it gets addressed ASAP. Hopefully in the meantime, you can make use of the sort order option. To do this:

right click on the build specifications node and select "Arrange By" and pick name. That should do an alphabetical sort. You can also sort by type, but then installer wouldn't come in last. You should be able to drag/drop the build specs, but it seems like you aren't able to drag/drop build specifications. I will make sure this gets fixed.

>>I just double checked and am afraid to report that you will be stuck with 2 copies of the INI file.<<

Thanks for checking. At least I know I'm not missing something.

So far I'm not seeing any real advantage to the new app builder. Maybe it's great for large projects, but for me it's been a step backward.

George

I guess I'd just really need to understand your setup to see if there's anything we can do about it. I'm not sure if there will be a solution for you, but there might be. I will also relay your feedback to see if there's something that can be done about this in the future.

I want to develop a install application using NSIS, and I want to silently install LabVIEW Runtime Engine Using NSIS Scripts.

So I must know whether LabVIEW runtime Engine was be installed in Windows,How to? search registry? which Key?? Thanks!

The LabVIEW 8.0 run-time engine registry entry is at:

HKEY_LOCAL_MACHINE\SOFTWARE\National Instruments\LabVIEW Run-Time\8.0

There is a key called Path in there. That will point to where the run-time engine is installed on the system.

Hope this helps.

Jason,

We seem to be going in circles a bit. I understand how I can add a variable to my WINNT directory in the installer. However that same file is also included in the directory with the executable because it's part of the executable build script. I have it as part of the executable build script so I can test how the program functions without having to run the installer. So now the file gets put in two places when I only want it in one place. Unless there's a way that I'm missing to tell the installer to put just the executable in a particular folder, it seems that I'm always going to have to have two copies of files if I want to have files installed in directories other than where the executable is.

George

I just double checked and am afraid to report that you will be stuck with 2 copies of the INI file.

Jason,

>>If you want to have your ini file moved to the WINNT folder, you need to add it as an item from the project, not the build rule. <<

Sorry I don't follow what you mean here. In my build spec for the executable I tell it send the Tescom.ini file to the WINNT dir. If I build just an executable I don't know how else to tell it where to put that file. And since I need to build the executable before I can run the installer I'm stuck with the structure in the build spec.

George

Well if you only intend to put the Tescom.ini file in the WINNT directory for the installer, you can specify that in the installer editor. Rather than adding it as a file to include in the EXE editor, do the following:

On the installer, go to the Source Files page.

Expand My Computer and find your Tescom.ini file. Add it to the corresponding MSI variable for your WINNT directory. If it doesn't exist, I believe you can create a new directory mapping to add it there.

Hope this helps.

Yeah, the new application builder is somewhat different than the old one. With the installer, adding a build specification adds everything from the build specification to the specified directory. The output is treated as an atomic entity.

If you want to have your ini file moved to the WINNT folder, you need to add it as an item from the project, not the build rule. The same type of thing needs to be applied to the lvXXX DLLs. I don't believe there is another way for you to get around that one.

I'll take these comments and run it by some people to see if something can be done about this in the future.

The easiest way to make sure that your changes are reflected in the project is to always have the project open when you make your edits. Basically, always start with the project window open, and open all VIs from within the project. I know it takes some getting used to, but I think that it will prove to be useful.

As far as the error when building an executable, I'm working on having better error reporting. However, this problem shouldn't come up too much as long as the project is open when making all of your edits or name changes.

As far as the installer issue, the installer should preserve the hierarchy of the build output. So by including the build specification, the data directory and other directories created as specified by the build specification should automatically appear on the installed system. The only catch is if you create a folder that goes beyond the root level of the MSI directories listed. Other than that, the hierarchy should be preserved.

How is your build specification configured? Perhaps there's just a misconfiguration that is causing the installer to dump all the files in to one directory.

Having an INI file isn't necessary. In fact, unless you specify an INI file to be copied over (in versions 7.1 and below), the application builder doesn't create one for you. The INI file is created when the application is first launched.

The INI file contains settings similar to that of the LabIVEW.ini. It has settings that can help with webservers, VI server access and other settings that deal with colors for graphs and other user defined options. However, not all settings are stored in the INI file of the application.

There are also tokens that can be used to specify what run-time engine is used when the app is run.

A lot of people won't find the INI file all that useful, however there are some definite use cases for them.