.Net dll dosen't load in Application EXE

[Aapthan]

Hallo All,

I am currently developing Cryptographic algorithm for Smartcards. I use VS 2012 C#.net Express Edition to code the Algorithm, along with BouncyCastle.dll.

BouncyCastle.dll for .net is developed under .net2.0

My program works perfectly in LV 2011 Environment, but when I build the Application EXE, the program searches for the .dll.

Before using the .net dll in Labview, I have done the following soultion suggested by NI: (Labview.exe.Config)

<?xml version ="1.0"?>
<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0.30319"/>
   </startup>
</configuration>

I used the same solution for the Application EXE but it always promts a dialog for the .net DLL.

I have attached the snapshot of the Application folder and its Data folder.

Experts suggetion is kindly adviced.

Thank You

Raj

[tyk007 · Accepted solution]

When you run a VI in the IDE, LabVIEW.exe is the process hosting the CLR. When you build an executable that is the application that is hosting the CLR. So the advice given to edit/create "LabVIEW.exe.config" for development in the IDE, as you indicated, needs to be applied to "Signature_Gen.exe.config" for your runtime application.

I see you have a "Signature_Gen.config" file but it needs to be "Signature_Gen.exe.config", just like the LabVIEW example.

[Aapthan]

Thank you tyk007,

I realised this after a few minutes that .exe was missing.

Thank you

Raj

[Ray.Abram]

Can you post the step you used to use the DLL in labview ?

Did u just use the import DLL wizard ?

[Andrey_Dmitriev]

---

@Ray.Abram wrote:

Can you post the step you used to use the DLL in labview ?

Did u just use the import DLL wizard ?

---

Take a note - this is 7 years old thread.

Technically we talking about .net here, so the DLL Import Wizard is not applicable.

In very short words, you have to place .net constructor on the BD:

Then, if we talking about very recent versions (Bouncy Castle C# .NET release for .NET 6.0 & LabVIEW 2024) you can select .net Core Constructor:

Then select BouncyCastle.Cryptography.dll and choose appropriate constructor:

Follow Bouncy Castle doc from this point, but take a note that .NET Core support added to the latest LV is "experimental", could have some issues.

Refer to the Help Using .NET with LabVIEW and examples located in "<LabVIEW>\examples\Connectivity\Dot NET" and "examples\Connectivity\Dot NET Core" folders as "getting started".

[rolfk]

And unless that bouncyCastle dll is a much much newer version, I would posit that using a .Net DLL that was current when .Net 2.0 was the state of the art is absolutely certainly worse than not using any cryptography. In cryptography, what was top notch 5 years ago is just about enough now and will be obsolete in another 3 years. You better use no security than bad and outdated security!

[Mark_BlueMax]

It sounds like the path for the DLL was not known by the application, but was known by LabVIEW Dev system.

Having run into this many times, I found the easiest fix is the Copy the contents of the (Labview.ini) file for your development (/Program Files/NI/{version}/ into the .ini file for your built application.  A simple way to do this is to copy the LabVIEW.ini file into your release folder and rename this file to {appName}.ini.  

What this does is your application (exe) is essentially a small version of LabVIEW.exe, so it will look for path information the same way LabVIEW does, but giving it the same information in the (INI) file that LabVIEW has, its pathing will work the same.  You do need to adjust for how your target installation machine will the pathed for it to work correctly once installed with installer.

[Andrey_Dmitriev]

---

@Mark_BlueMax wrote:

It sounds like the path for the DLL was not known by the application, but was known by LabVIEW Dev system.

Having run into this many times, I found the easiest fix is the Copy the contents of the (Labview.ini) file for your development (/Program Files/NI/{version}/ into the .ini file for your built application.  A simple way to do this is to copy the LabVIEW.ini file into your release folder and rename this file to {appName}.ini.  

What this does is your application (exe) is essentially a small version of LabVIEW.exe, so it will look for path information the same way LabVIEW does, but giving it the same information in the (INI) file that LabVIEW has, its pathing will work the same.  You do need to adjust for how your target installation machine will the pathed for it to work correctly once installed with installer.

---

I'm just very curious about how it will work. It is true that LabVIEW will 'remember' the path to the .NET DLL which was loaded. The built application will first check this path twice — once relative to the app folder, then absolute as was used in dev environment, and after that, it will check the folder where the application is located. However, this information is not stored in an INI file. The LabVIEW.ini file will store the path to the last project and last opened/edited VI, but not the path to the .NET assembly, so I don't think it will work.

Please refer to the KB article instead: Specify the Path for the .NET Assemblies Called From LabVIEW