LC2010 Ap Building keeps adding NI_Reports and NI_HTML references

[wa5ycg]

I just converted to LV2010 on Vista.  When trying to build an application with an old source, the result wants to load a bunch of vi's from a folder that the Ap Builder created called NI_Reports and NI_HTML at run time.  Why and how do I clean this up?

Steve

[Austin_S]

Hi Steve,

Here is a link to an NI KnowledgeBase article that I believe addresses what you're talking about.  It also includes steps to clean this up and not leave all of these files in the application.  It was written for Labview 8.6, but should still be applicable for LV2010. 

http://digital.ni.com/public.nsf/allkb/2AE85CF95217E60786257540000D818C?OpenDocument#end

Please let us know if this works for you.

[wa5ycg]

Austin:

Well, it kinda helps.  I think I see what the note was referring to, but when I go looking through LV2010, none of the items listed in the note are there.  I am still quite lost.  Am I the only one using NI Reports and compiling?

Steve

[Paul-D]

Hi Steve, this is Paul from Applications Engineering at NI.

I'm not exactly clear what your problem is, but it sounds like you need to add those files into your build specifications, so that they are included in the executable.

If this continues being an issue, you may want to try creating a new project, and adding your VIs.  Doing this should help you build the proper dependencies.  You will also have to create a new build spec, at which point you can ensure those VIs.

I would also recommend checking out:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/creating_build_specs/

[wa5ycg]

Thanks for the link.  Definitely some useful information.  However, I do not understand why going from LV8.5 to LV2010, I need to do something different to get NI Reports to Build without these extra steps.  Why now at RunTime, I need to include vi's from the NI_Reports and NI_HTML subdirectories of the target directory?  There are not even any warnings after the build.  Should I have not been warned that the resulting EXE was not complete?

S

[Paul-D]

Steve, I believe the issue here is with your dependencies.  I just created a project on my own in LV 8.6.1 (the lowest version I have installed), and put some HTML and report Generation VIs in, created a build spec, then reopened that project in LV 2010, and built the executable, and did not experience the same problems.  I did notice that the NI_HTML and NI_REPORTs folders were included in my build folder.  Did you experience this?  If so, did you by chance delete them?  Are you running that executable out of the build directory?

Also, check the project in LV2010, and look under the dependencies.  Do you see LV_report.lvclass?  Do you also see NI_HTML.lvclass?  They should be there.

Additionally, look under your build specs for this exe, and check under "Additional Exclusions".  I have 'Remove unused members of project libraries' checked, by if your LV is confused, maybe try unchecking it so that these dependencies don't get left out.

If you want to find out more about dependencies, check out:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/viewing_dependencies/

[wa5ycg]

Paul:

Thanks for your help.  We are very close now.  I did check to make sure that the two classes are in the dependencies, and the "do not included unused..." box is checked.

The problem is the NI_reports and NI_HTML directories.  If I distribute the application or move the EXE file, these directories have to go with the application.  This adds a lot of work for us, and unnecessary confusion for our customers.  WHY?  Isn't there some way to just have these vi's compliled as before?  Why were they named the same anyway?

Steve

[Paul-D]

Steve,

I just created a new project in 2010 only and including those VI's but did not experience the same problems.

Try this for me:

1. Create a New Project and Save

2. Add a VI to this project and throw some Report and HTML VIs into it, and connect up any required inputs (we can't compile if they're broken.

3. Create an EXE, leave all the options as default, set the startup as that VI you created, and make sure you know the build location

4. Build the exe, and go and observe the folder.  You shouldn't see the VI_HTML and VI_REPORTS folder.

If you do still see those, we may need to look at upgrading/repairing the Report Generation Toolkit included with your newer version of LabVIEW.  This can be performed through Add/Remove Programs and performing a Repair on LabVIEW 

If you didn't see those, try creating a new project in 2010 and re-adding your old VIs.

If you still see them, then something is going on with your old VIs, and we may have to look at replacing each of those Report Generation VIs from the Toolkit in 2010.

Let us know if you have more questions.

Paul

[wa5ycg]

OK, Gents, I think that I stumbled onto the problem.  When I created a new project (as opposed to the old one that I carried from LV 8.5), everthing compiled fine.  On closer examination, the "Use LabVIEW 8.x file layout" box was checked which forced all the files into a flat format, which caused file name collisions, which caused the classes to be listed externally to resolve the problem.  I uncheck the box, no collisions, problem solved....

BUT...

No all of the directory path statements within the program don't work in the EXE.  They work fine when running the vi's, but not now when they are compiled.  I assume that it is because those vi's are no longer doing relative path statements from a flat file.  Now how to I fix this, yet still maintain the ability to run the same code as vi's?

Steve

[JordanG · Accepted solution]

Hey Steve,

Make sure all the paths you are calling are based off of one start point that is accessible from both EXE and the developer environment. You can use this KnowledgeBase article as the initial path reference and either build or subtract from this example.

http://digital.ni.com/public.nsf/allkb/FD7DE8BC8FFC256C862565F4006BE363?OpenDocument

Make sure the builds specificationss you're using are putting the files you're calling into the same relative location.

Hope this helps!

Jordan