.NET private assembly, build application not executable

[smercurio_fc]

OK, I'm confused now. I've got this large application that's using a couple of private .NET assemblies we got from somebody else. The application works just fine in the development environment (LabVIEW 8.2), but when I build the application, the application is not executable and I get that oh so useful message "The VI is not executable. The full development version of LabVIEW is required to fix the errors." No clues as to what the problem actually is. Anyway, I did a little playing around creating a simple project with one VI that called the constructor for the classes in these prvate .NET assemblies. It turns out that whenever I reference one of these assemblies I am unable to build an executable that will actually run. I have not encountere this problem with other .NET assemblies, which leads me to believe it's something to do with these particular assemblies. Thing is, if I write a wrapper .NET assembly around these private .NET assemblies and use the wrapper .NET assembly, then the executable runs just fine! Am I missing something obsecenely obvious with building the app? Are there any special properties a .NET assembly needs to have in order for it to work in an executable? I thought it might have been due to it not finding the assembly but I even created a .config file with the build application specifying search paths. That didn't help, and given the fact that the wrapper .NET assembly works I don't think it's an issue with it not finding the .NET assemblies. One thing that it might be due to, but I'm not sure since I don't know the innards of what LabVIEW is doing with .NET is that both of the private .NET assemblies have a class with the same name, but they're in different namespaces. Just grasping at straws here, really.

Any clues or tips on what to check?

By the way, I cannot submit the private assemblies since they're proprietary.

[Paul M.]

Hello,

There is a chance that the private assembly isn't getting copied to the application directory when compiling the application. If the private assemblies have dependencies on another assembly, LabVIEW cannot detect this when building the app, the code breaks when run from the application.  Have a look at this KB if you haven't already:

http://digital.ni.com/public.nsf/websearch/9E1CFF2B47EC4FD386257116005FAB3E?OpenDocument

Hope this helps!

[Lycangeek]

I can't think of anything off the top of my head. A few things that could give more insight...

1. Go to www.sysinternals.com and download the Debug Viewer. Run that and then run your application. If we are getting a .NET execption, we'll dump it there. I don't think we'll see one, but it's a good thing to check.

2. Use the Fusion Logger to see what is being loaded or not - if it's a problem on not finding the assembly, the loader will report it. You can read about how to set that up here: http://detritus.blogs.com/lycangeek/2005/03/in_previous_pos.html

3. This is more effort, only because of the details to walk through...however, at sysinternals, you could download the File monitor. Set the filter to be only your application and see what file i/o errors you may be getting. It's likely to be a LOT of activity - you might set the filter to errors only or something.

Anyway, some things to try.

[smercurio_fc]

To Paul: No, that's not the problem. That was the first think I checked. All the required DLLs are in the app's directory.

To Brian: Those are good suggestions and well worth a try. If it were a .NET exception I would have expected some sort of system error or something else. It's just that the run-time engine thinks the VI is not executable. Since my original post I finished the wrapper DLLs in order to build an executable that would actually run, but I still have the code from before so I can try it on that.

Side note: the app builder seems a bit quirky as of late. When I was rebuilding my application with the wrapper DLL it kept insisting that my main VI was not executable, even though it was. I had to remove all the files from the project as well as the build specification, re-add the files and recreate the build specification in order for the application to be built. Using LV 8.2.

[smercurio_fc]

Brian, here's what I've found, or rather what I didn't find:

• Debug Viewer: did not display anything when I ran the app
• Fusion Logger: did not display anything when I ran the app. This was very curious, so I tried the Calculator VI that you had in your blog. The Fusion Logger still did not display anything when I ran that example. I also tried in LV 7.1 - nothing. I'm almost positive I set it up correctly, as all that was mentioned in your blog as just setting a couple of registry keys. To check it out I launched Visual Studio .NET 2003 and the Fusion Logger did show entries when it launched, so I'm pretty sure it was working correctly. It was just that LabVIEW did not trigger any entries.
• File Monitor: I've used this tool before, and it can make your head spin with the volume of information that's in it. Still, it did not yield anything to point to say "a-ha! that's the problem". There were a number of "NOT FOUND" entries, but all of those seemed "normal" as they had to do with the run-time engine starting up and seeing if this or that existed. I saw the same entries when I ran the built app that uses my wrapper DLL. I did not see anything related to the private .NET assemblies I was using.
  

I can safely say that I'm quite befuddled by all this, but using the wrapper DLL seems to work as I can get an application built that will actually run. I have no idea why, but I have something that works.

[Lycangeek]

Well, I'm glad that the wrapper is working for you, although I'd love to know what about the other assembly is causing the problem...but I'd probably need the assembly to figure it out, which I can't have...oh well.

As to the fusion logger - my guess is that you have the .NET 2.0 framework installed on your machine. LV selects the latest framework when it runs, unless you provide a configuration file specifying the .NET framework version to use.

In that case, you'd need to use the .NET 2.0 fusion viewer. Since the one you were running showed the VS.NET 2003 assemblies, I know you were running the 1.1 fusion viewer. fyi, really.

[smercurio_fc]

Yeah, unfortunately due to their proprietary nature I can't provide the assemblies. Annoying.

I do indeed have the 2.0 .NET framework. I forgot that I had it, as I was doing some web development work a while back with Visual Web Developer Express. I did specify a labview.exe.config file to force LabVIEW to use the 1.1 framework but that made no difference with respect to the Calculator VI. Creating a myApp.exe.config file specifying the 1.1 framework was likewise ineffective. The 2.0 SDK sits in at 350 MB, and with the measly DSL connection we have at work I can't download it during normal business hours, so I'll have to do it off-line. I'm going to try it since I'm curious as to the results, but it won't be for a couple days. I'll post an update in case I find anything.

Thanks for the suggestions.

[Lycangeek]

Well, I know if you create a file called LabVIEW.exe.config, put it in the same directory as LabVIEW.exe and put this in it

<configuration>
<startup>
<requiredRuntime version="v1.1.4322">
</startup>
</configuration>

then it will work. This is what I do when I need to debug issues w/ 1.1

[smercurio_fc]

That's what I had (except that the line "<requiredRuntime version="v1.1.4322">" requires a "/" before the ">").

My mistake when trying the Calculator VI was that I hadn't clicked the "Refresh" button after running the VI. I realized this when I restarted Fusion Logger. There still were no entries when I ran my app, though.

Totally bizarre.

[Lycangeek]

oops - yeah, that's what happens when you try to reformat the XML so that it shows up on the forum...