Problems with builds in 2009

[Val Brown]

OK, so has anyone else had problems with transferring projects from 8.6.1 to LV 2009?

I have one major project that originally had large problems even running in 2009 but that was solved by uninstalling 8.6.1 and 2009 then reinstalling 2009 alone. It seems that there has been some significant reorganization done in the SPT, esp in the Wavelet Analysis subs. Ok so that DID get sorted out (essentially by the "virgin" install of 2009) but now when I do my build -- of a project that builds perfectly well in 2009 -- I can get the project to build BUT, i get the following error message when trying to run the built EXE:

"LabVIEW: File is not a resource file.

The file 'BuiltAPP.EXE' could not be loaded"

Any good ideas, besides backing down to 8.6.1?

Edited August 13, 2009 by Val Brown

[Staffan]

I am also having problems when moving one of my projects from 8.6.1 to 2009.

The problem is the Installer. The property window will not open and LabVIEW hangs. At first first it seems normal (CPU/Mem Usage (in Task Man)). After a while CPU goes to 0 but mem usage increases very slowly, but the property window does not open.

I created a new Installer without any problems and I can build it from the project view. But when I try to open the property window LabVIEW hangs.

One of my smaller project has no problem.

/Staffan

[battler]

I suppose this means I may experience even worse problems going from 8.0 to 2009...

[NitinT]

I am also having problems when moving one of my projects from 8.6.1 to 2009.

The problem is the Installer. The property window will not open and LabVIEW hangs. At first first it seems normal (CPU/Mem Usage (in Task Man)). After a while CPU goes to 0 but mem usage increases very slowly, but the property window does not open.

I created a new Installer without any problems and I can build it from the project view. But when I try to open the property window LabVIEW hangs.

One of my smaller project has no problem.

/Staffan

Hey Staffan,

Could you post your question on the LabVIEW discussion forums board so that an AE can help out. Also, update this thread with a link to the NI post. Thank you

Nitin

[Staffan]

I have posted it on the NI forum.

http://forums.ni.com...hread.id=434634

/Staffan

[Christian_L]

I have posted it on the NI forum.

http://forums.ni.com...hread.id=434634

/Staffan

You'll likely need to include your 8.6.1 project that is causing the problems with your posting on the NI forum in order for NI to be able to look into the problem. As you mentioned this doesn't happen for every project and so the AEs and R&D will need something specific to look at to figure out what is going on.

[ESST]

Hi,

I ended up whit a similar(I don’t remember the exact error text) issue during a8.6.1 to 2009 project upgrade.

The problem was under "Advanced" in the build setup, I had notselected "Use Labview 8.x file Layout". When selected, no problem, buildsgalore. Your mileage may vary.

Espen

[gmart]

Hi,

I ended up whit a similar(I don’t remember the exact error text) issue during a8.6.1 to 2009 project upgrade.

The problem was under "Advanced" in the build setup, I had notselected "Use Labview 8.x file Layout". When selected, no problem, buildsgalore. Your mileage may vary.

Espen

ESST,

Did your project also use the SPT toolkit? What was your exact error? It would be helpful to know this to better understand why toggling the checkbox worked for you.

[ESST]

Hi,

Your right, should have documented that better.

The project does not use the SPT toolkit, at least not directly.

I do NOT get the error when I use a build specification that I made under 8.6.1.

I get the error when I set up a new build using "Build specification(right click)/ New/ Application(EXE)", and build it without modifying theadvanced tab(selecting "Use Labview 8.X file layout").

Selecting "Use Labview 8.X file layout" on the new build removes theerror.

Error build:

Correct build:

The destination path and build name is one of several tried.

Looks like it might be related to the location of the Comsoft profibus PXI carddrivers.

PS. I have not had any problems with the cards or driver under 8.6.1 (nottested under 2009, HW not available), and the support from Comsoft is great.

[gmart]

ESST,

Thanks for the thorough response. The problem is due to the file named "CFG-I/O-Bytes.vi". It contains a slash which is not valid for the OS. This is not a problem if the VI is inside an LLB since that was allowed. During the process of building an application with the non "8.x layout", files are written to disk. Since that filename is not valid, the error results. The error was reported to R&D (# 158487).

The workaround is to check the checkbox (which is the default when loading older projects). Also, you could try to rename the VI during the build process. You will need to have the files under My Computer so you can individually rename that one file.

[ESST]

Thank you gmart,

Did not notice the "/", should have, guess I read "I/O" asjust a regular word . Jumped on the 8.x and id not look back (till now).

I would rather not mess with the third party drivers, even the names. Makes things allot easier when contacting a service department, or when upgrading/patching.

For me the solution will be to continue to use the 8.x work around. I am not using LVOOP, directly or indirectly in this project, so name conflicts are not really an issue.

[Val Brown]

I'm still having my original problem: using SPT and even the Obsolete SPT. The build "succeeds" (whether or not I check "Advanced/Use 8.x..." option) but then I get "...not a Resource" when trying to run the "successfully" built EXE.

[jgcode]

I am getting this annoying one.

Another project with the same VI builds ok!

<edit>

B*st*rd

Seems it was to do with looong file paths - not that the above told me that

This error info did tho:

Problem sol-ved.

I am wondering if this has anything to do with the new way exe's get built?

Look at the path in the error:

C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb

That path is referring to a VI inside my executable!

This may be a bigger issue that I first thought

Edited August 26, 2009 by jgcode

[gmart]

I am wondering if this has anything to do with the new way exe's get built?

Look at the path in the error:

C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb

That path is referring to a VI inside my executable!

This may be a bigger issue that I first thought

With the new format for applications, files are stored relative based on the source files' layout. Because of this, it is possible for the destination file paths to get long while building. There is information on the change in the upgrade notes.

[jgcode]

destination file paths to get long while building

As always thanks for replying Gmart

What I am trying to establish is - is it just the build were long file paths may be a problem?

And if it passes the build the exe will always be fine?

Or could a situation arise that if LabVIEW tries to resolve a path in an executable (depending on where it is in a folder hierarchy) it could be corrupt due to the limitation of characters in the Windows OS?

[gmart]

As always thanks for replying Gmart

What I am trying to establish is - is it just the build were long file paths may be a problem?

And if it passes the build the exe will always be fine?

Or could a situation arise that if LabVIEW tries to resolve a path in an executable (depending on where it is in a folder hierarchy) it could be corrupt due to the limitation of characters in the Windows OS?

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

[hooovahh]

Yeah that windows character size limitation is a bugger. We hit it several times when dealing with SVN. If you do a checkout in your my documents then it starts out a C:\documents and settings\[user name which may be long]\[user name which may be long]'s documents\ That eats a large chunk of the possible 255 characters. Then if you have a long path in the SVN it will become a problem.

It can also become a problem with VIPM if you are building a project with a long package name, and have long file names in the VI. Once all the VIs are saved they are put into a LLB so as long as the package is built there shouldn't be a problem with the package being installed on another machine.

I am very glad to see that LabVIEW now has a more useful error message. Previously LabVIEW would return a General I/O error.

To avoid this problem I would say use the advanced build option of Use 8.x layout. It will build the EXE in a flat structure like in previous versions of LabVIEW.

[jgcode]

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

This is great news wrt to the build.

Internally LabVIEW does not have the same restrictions as e.g. Windows OS.

So whilst the build process may become corrupted, once the EXE is build and if it gets moved LabVIEW can handle the long path names.

Cool

To avoid this problem I would say use the advanced build option of Use 8.x layout.

Are you kidding me! No more files outside the EXE, all those class methods hidden, - I am never going back...never I tell you....

But seriously, the build process failing all the time with long files names is starting to annoy me.

And thats just from evaluation. I am really worried when if comes to out Source Tree too, if it going to be quite deep already.

I can see this being a huge PITA.

[gmart]

This is great news wrt to the build.

Internally LabVIEW does not have the same restrictions as e.g. Windows OS.

So whilst the build process may become corrupted, once the EXE is build and if it gets moved LabVIEW can handle the long path names.

Cool

Are you kidding me! No more files outside the EXE, all those class methods hidden, - I am never going back...never I tell you....

But seriously, the build process failing all the time with long files names is starting to annoy me.

And thats just from evaluation. I am really worried when if comes to out Source Tree too, if it going to be quite deep already.

I can see this being a huge PITA.

The word "corruption" is scary and not really what is happening during the build. We get an error while building due to OS limitations. Nothing is corrupted. Words mean things and the last thing we need is someone googling this problem and seeing the word "corruption" .

Regarding the long path names, one thing you can do to mitigate the problem is to change your destination directory to something shorter. I know that may not be possible in all cases, but that will buy you some extra characters. Alternatively, you can quit being so descriptive with path names and go back to the DOS days of 8.3 filenames .

[Rolf Kalbermatter]

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

I'm sure you guys know that already but there is a way under Windows to avoid that problem. It requires to use the Widechar Windows File API and format the path in something like "\\?\a:\path to very long filename". Not all APIs do support that and it would often fail for shell APIs but it is at least a way to circumvent that problem. Not sure about the usability of this on FAT volumes though.

Rolf Kalbermatter

[jgcode]

The word "corruption" is scary and not really what is happening during the build. We get an error while building due to OS limitations. Nothing is corrupted. Words mean things and the last thing we need is someone googling this problem and seeing the word "corruption" .

Regarding the long path names, one thing you can do to mitigate the problem is to change your destination directory to something shorter. I know that may not be possible in all cases, but that will buy you some extra characters. Alternatively, you can quit being so descriptive with path names and go back to the DOS days of 8.3 filenames .

While I understand your point on the correct terminology for the masses, IMHO if the build was failing due to errors when porting between PCs then it has become corrupted.

The reason wasn't clear originally and was very frustrating.

Once I understood the issue, I was able to solve it by dragging the top level to the desktop and the build compiled without errors.

Unfortuneatly, our Source Tree is already well defined, so I can't so this, and I state this again, I can see this being a huge PITA.

Whilst I love the change that everything is packed inside of the exe, spending an additional 68 characters to define this file: LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb from LV8.x to LV9.0 when there already is a known limitation of characters is just fixing one problem but adding to another.

As for 8.3 filenames it seems NI prefers to promote descriptive files names

Do not use names like VI #1.vi or Untitled.vi when something like Save Data to Spreadsheet File.vi or Convert Voltages to Engineering Units.vi will do the better job. Try to include action words like Open, Close, Save, Calculate, Update, etc. for subVIs that do something. Use words like Display, Panel, View, Screen, etc. for user interfaces.

http://zone.ni.com/devzone/cda/tut/p/id/5560

[gmart]

Once I understood the issue, I was able to solve it by dragging the toplevel to the desktop and the build compiled without errors.

Unfortuneatly, our Source Tree is already well defined, so I can't so this,

What do you mean by your source tree is well defined? What I suggested doesn't require you to change your source layout. All you'd need to do is change the destination directory in the build spec to a shorter location (ex. C:\temp). That should reduce the destination path lengths. If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location.

[jgcode]

What do you mean by your source tree is well defined? What I suggested doesn't require you to change your source layout. All you'd need to do is change the destination directory in the build spec to a shorter location (ex. C:\temp). That should reduce the destination path lengths. If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location.

Yes sorry, we have been evaluating 2009 (and it looks like we are going to upgrade now) so I have been playing with stuff so that is why I did a drag and drop to the desktop and was happy that it solved the problem.

As for the Source Tree comment yes, sometimes (if thats how I want to do it for that project) I want to keep my (latest) build under my dist folder which happens to be a defined folder structure under the Source Tree. I would prefer to avoid the build to C:\temp (or where ever) and copy and paste back under the Source Tree to check the build in, or for other reason mentioned.

However, from all the discussion and even more playing around I have been doing, I have come to the same conclusion as you - so I think the solution above is the way to go. The reason for this is, even though I still think it adds to a problem, the benefits of having a cleanly built EXE in LV2009 do out way the above (for me anyway). By human nature, I would prefer not to have change the way we do stuff but I think I can overcome that inertia with a little time.

Coz at the end of the day, having no external files in my exe - is just way too sexy (hey that rhymes)

Thanks for your back and forth dialog on this Gmart. It helped me get my head around this new feature.

Edited August 27, 2009 by jgcode

[Mellroth]

...If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location...

Why couldn't LabVIEW itself use a temporary build location and then copy the build to the specified location?

Relying on users to put builds in a certain folder just because Windows/LabVIEW has a problem with long file paths, is not that nice.

The application might build just fine on my system, but not on my colleagues system, just because his name is X characters longer than mine.

A temporary build location, could also help when the build destination is within a SCC hierarchy, where some destination files are locked.

In LV <8.6, LabVIEW builds everything just fine, then it might complain that the files are write protected, and throws all build files away.

With a temporary location, LabVIEW could prompt the user to fix the destination problem, instead of throwing the build files in the trash

/J

[Rolf Kalbermatter]

Why couldn't LabVIEW itself use a temporary build location and then copy the build to the specified location?

Relying on users to put builds in a certain folder just because Windows/LabVIEW has a problem with long file paths, is not that nice.

The application might build just fine on my system, but not on my colleagues system, just because his name is X characters longer than mine.

A temporary build location, could also help when the build destination is within a SCC hierarchy, where some destination files are locked.

In LV <8.6, LabVIEW builds everything just fine, then it might complain that the files are write protected, and throws all build files away.

With a temporary location, LabVIEW could prompt the user to fix the destination problem, instead of throwing the build files in the trash

It could worsen the problem on some machines where the temp location has been configured by system admins to be deeply nested. In fact the default temp location in Windows at least under XP is something like "C:\Documents and Settings\<long or not so long user name>\Local Settings\Temp" already, which doesn't look very much like a short path to me.

Rolf Kalbermatter