.NET components not found when using exe - LV2011

[mibo0691]

Hello all,

for the last two days i've searched dozens of articles and threads but could not find a working solution yet.

I wrote an app for the the windows taskbar tray in LV2021sp1, implementing the NotifyIcon Library using .NET components to achieve the taskbar icon functionality. It works well on this system (Win10x64), however i must provide a version for LV2011 runtime also. Converting the sources down to LV2011 and executing from dev environment works fine. For LV2011 environment i use a virtual machine also running Win10x64.

However if i build an exe file in 2011 and try to start it, a search dialog pops up, prompting the user to locate the .NET assembly "System.Windows.Forms.dll". The .NET Framework is by default present on the system (.NET 2.0, 3.0, 3.5, 4 is installed in Windows 10). If i manually navigate to the file's path (C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll) and select it, the runtime application starts. But that's not a suitable end-user use case. Selecting the same file from .NET folder v4.xxx when prompted generates a dll loading error.

I already tried:

- Copying the System.Windows.Forms.dll into the LV project source folder and specifying it to be placed in the built application's root folder and/or the data folder. Still the built exe ignores / does not find the dll.

- Adding an <applicationName>.exe.config file beneath the executable according to this article.

- Go through all the VI's, editing all .NET constructor nodes and selecting the .NET dll files i previously copied from \Windows\...\.NET folders directly into the project's source folder.

- Trying to select System.Windows.Forms(2.0.0.0) instead of (4.0.0.0) for the constructor nodes, however .NET always refuses and automatically promotes to 4.0.0.0 (even if i place a LabVIEW.exe.config beneath the LabVIEW.exe that enables loadFromRemoteSources).

- Execute on a different machine to spare out the probability of faulty installed .NET

Any hints or help would be really appreciated!

Thanks in advance.

[rolfk]

.Net had a major version change between framework 2.0 and 3.0. Applications need to elect at startup with what version they want to startup and can't (easily) access framework assemblies that are compiled for a framework version on the other end of that fence.

LabVIEW changed its preferred .Net framework version from 2.0 to 4.0 around version 2013 or so. So your assembly may not be available in .Net 2.0 and since you use an old version of LabVIEW it instantiates the 2.0 Framework and then fails to find the framework assembly.

You need to place a manifest file aside your executable similar to this but its name needs to be adjusted according to your executables name.

[mibo0691]

Hello rolfk,

thanks for the quick answer. You wrote that my assembly may not be available in .NET 2.0 which LV2011 is using. However the NotifyIcon library i used was built in even older LV vers. 9.0 so it should definitely work in 2011 - or am i missing something here?. It's even working in the 2011 dev system, just not for the built exe. And also, going up to LV2021 with the same lib works fine for both dev-system and Runtime 2021 executable.

Already before opening up this post i created a manifest file along the existing *.exe file (with the correct naming) as you mentioned. Did not work either, unfortunately.

Some other ideas, maybe?

[mibo0691 · Accepted solution]

Hello again,

i have found a workaround. Not the best solution because it does not solve the problem from its roots, but it's working.

The solution was already proposed in this thread before:

https://forums.ni.com/t5/LabVIEW/Specify-or-Set-a-NET-Assembly-DLL-Call-or-Search-Path-for-a/m-p/376...

In the build options of the application, a custom ini file must be selected to be created. This ini file must contain the following line:

viSearchPath="<topvi>:\*;C:\Windows\Microsoft.NET\Framework\v2.0.50727"

This addes the location of the .NET dll file(s) to the default search paths of the executable. The file is then automatically found at executable startup and the application loads with no prompts.