Error 1172 When Calling a .NET Assembly

[dafemec]

I have a subVI that calls an assembly. What I am seeing is that the assembly needs to reside in the directory of the top-level VI that is (eventually) calling the subVI, not just in the directory of the subVI itself as the Knowledgebase article suggests. (Yes, I have added the assembly to my list via Tools >> Advanced >> .NET Assembly References...) This is maddening! Thanks in advance for any help you can provide.

[KileenC]

Hi,

Is the top-level VI making any .NET calls at all? If so, the .NET Assembly Reference would still need to be located in the same directory of that top-level directory.

Note that .NET has 2 types of assemblies: private and shared. A private assembly is used by only one application while a shared assembly is shared amongst different applications.

By default, when a C# program is compiled, the assembly produced will be a private assembly. This assembly (DLL/EXE) needs to be placed in the same folder as the calling application.

Shared assemblies are placed in the Global Assembly Cache. This Global Assembly Cache stores .NET assemblies specifically designated to be shared by several applications on that computer. If you do not want to
worry about specific locations of your .NET Assembly Reference, you can consider making a shared assembly. Refer to the Microsoft KB for more information:

Microsoft KB 315682: How To Install an Assembly in the Global Assembly Cache in Visual Basic .NET

Hope this helps!

Kileen C.
NI

[dafemec]

This did the trick! Many thanks!

[KileenC]

Awesome!! Those are my favorite responses. 🙂

Kileen C.
NI

[Jim Theisen]

I would like to add something to this thread. 

I have a sub vi that is basically let say a .net wrapper vi.  This vi handles the interaction with any .net dll that we create. 

I have a higher level vi that has a call to this .netwrapper.vi.  This higher level vi does not have any other .net interaction at all.

When this higher level vi calls the .netwrapper.vi it gives me the 1172 error about the assembly is not found.  If I stop my higher level vi and go over to the .netwrapper sub vi and run it with the exact same values that just got set by the higher level vi, it works fine.

Also, if I simply copy the .net dll into the same dir as the higher level vi, it works. 

So from what I am seeing is that the .net dll would have to be in the same dir as every vi calls the .netwrapper vi.  So, where does it end?  Do I have to make sure that my dll is in every dir that I have that has a vi in it?

The reason I did this .netwrapper.vi was because I read that as long as that vi is in the same dir as the .net dll, and none of my higher level vis dont do .net stuff, which they dont, this architecture should work.

Any help would be appreciated.

[Lycangeek]

The rules are different for LV 7 and 8, so let me summarize. Feel free to post back with more specific questions for your case.

LV 7: The top-level VI determines what is known as the Application Base for the .NET code - this is the directory that should contain the .NET assemblies. Thus it is a requirement that the assemblies are copied to the root directory of whatever VI is the main VI. The only other option here is to install the assemblies into the GAC, which is always visable.

Since that isn't a great solution, we changed it in LV 8. .

LV VI's have what is known as a linker. Basically, it tracks the location of dependencies, such as subVIs. In LV 8, we extended this to support .NET assemblies. Thus, each VI now stores the relative path from the VI to the assembly it needs. This means you get what you thought you were going to get - independence on what the top-level VI is (as long as your wrapper and .NET assemblies maintain their relative positions to each other).

In addition, the recommended way of programming with .NET in LV 8 is to use the LV 8 concept of a project. The project now defines the Application Base for the .NET code, similar to how the top-level VI used to. But because of the linker, it isn't mandatory that your assemblies be in the Application Base.