.net constructor error 4

[adcpc]

Hi,

I'm trying to build an executable of a VI which use a .NET DLL. The VI runs fine when started from the development environment (tested with LabVIEW 2009 and 2011 on Win7 32bits).

However, when started as executable on the same computer, I get a constructor node error 4. The build is correctly done and the DLL is listed in the dependencies.

I've been looking about the .net configuration files and even try to force LabVIEW to use .net framework v2, v3 and v3.5 instead of v4 but the result is always the same.

Any idea on how to solve this ?

Thanks,

Alexandre

[Alex.T]

Hi Alexandre,

Is this a .dll that you have created yourself? If so, make sure that the .dll exists either within the hierarchy of where the executable is running or within the default .NET DLL directory. Just as a quick test, have you tried copying and pasting the .dll so that it is within the same folder of the executable?

LabVIEW will first check the current application directory structure and then the default directory. If the DLL you're referencing doesn't lie in either of these, this is what could be throwing the error. 

Thanks,

[adcpc]

Hi Alex,

No, it's not a DLL created by myself.

I've seen that LabVIEW includes the DLL in a subfolder named "Data" during the build process. If I delete this Data folder once the build is done, the executable will ask for the DLL. I can then give the path of the original DLL and the executable works without any error.

However, as long as I leave the DLL in build subfolder, I get the constructor node error 4. Is there any way to force LabVIEW to use a defined DLL instead of making a local copy for the build ?

Thanks,

Alexandre

[Alex.T]

Hi Alexandre,

The data folder incorporated by your Application will actually incorporate dependancies of the DLL itself, rather than just this single DLL. These dependancies also need to be referenced appropriately in order for your application to run successfully.

Developer Zone Article - File Management with .NET Assemblies

LabVIEW .config files can apply to a saved project, shared library, or stand-alone application. Refer to Configuring a .NET Client Application for more details about using configuration files with .NET.

- A .config file can be used to specify parameters for loading of specific .NET assemblies. This is how we could reference a static assembly found in common .NET installations.

If you move a VI that uses a private assembly to a different folder or computer, you must keep the assembly in the same location relative to the VI. If LabVIEW cannot find an assembly file in the GAC, the directory that contains the project, or the relative path stored in the VI, LabVIEW prompts you to find the assembly file.

- This is the behaviour we're exhibiting at the moment. I recommend that we ensure that the assembly can be located in the GAC (Global Assembly Cache). As LabVIEW is currently prompting you to search for the assembly, this means that it currently can't be found. 

If you build a VI that uses a private assembly into a shared library or stand-alone application, LabVIEW copies the associated private .NET assembly files to the data subdirectory in the same directory as the library or application.

- This is for the benefit of program modularity; if your application is loaded onto a computer that doesn't possess your referenced .NET DLL, we can make sure that it is always carried around with the application.

I hope this helps!

[adcpc]

Hi Alex,

Thanks for your reply.

As recommeded, I tried to place the DLL in the GAC, using the gacutil.exe tool. However, it seems that the assembly has to have an assembly manifest. I get the error "The module was expected to contain an assembly manifest" when trying to place the assembly in the GAC. I did not found how to create the required assembly manifest, so I assume that it has to be done by the DLL developper.

I also tried to place all existing DLLs from the source folder to the data folder and it worked. So it seems that the DLL I'm using is somehow using functions which are in other DLLs but LabVIEW can't see that. That's why it only copies the DLL which I'm using. Am I right ?

By the way, my project shows the required DLL in the "Dependencies" but if I do a right-click on it, I don't get access to the "Replace with..." option. I would like to use a copy of DLL which is on a network folder instead of using a local copy of DLL, in case of moving the project to another computer. How can I do that ?

Thanks,

Alexandre

[Alex.T]

Hi Alexandre,

You're correct. The .dlls that are called from the DLL that you are making use of in your LabVIEW Project must be located in one of the standard directories that we discussed earlier; this is why placing the associated DLLs which are being called within the same directory structure as the VI which calls them allows your program to execute successfully.

The path difference that is maintained between the called DLLs and your VI are relative; therefore by referencing your DLL on the networked server will function for your specific setup, you'll have to be careful with the folder structure you use when you transport your code to another computer; a small change in directory structure may result in an incompatible reference to your networked DLL. This is why the DLL used in the project is replicated in the directory; it's much simpler to carry the DLL around with the main file the same way you would carry Sub VIs which it is dependant on.

Thanks,