Jump to content

Application requires manually specifying .NET dll location

Recommended Posts

I am using MySQL .NET Connector with my LV2013 application which has been working fine for months. Today the new exe started requiring the user to pick the location of the MySQL dlls. Ironically, the dialog opens to the directory with the dlls in it. Currently, the dlls are in the /data directory. I have tried moving them into the same directory as the exe. I did see this post, but it didn't help. I haven't tried putting the dlls into the GAC because it wasn't entirely clear where in the GAC they would go, and in principal, having the dlls in the same directory path as the exe should be enough.


It would appear this is something related to the OS because the exe works on the dev machine - just not the target.


Any suggestions would be greatly appreciated.


Link to comment

As Rolf said in the referenced post, the GAC is the only sure bet for a .NET DLL (assembly). I presume the MySQL assemblies are signed and can be installed in the GAC. If MySQL won't install to the GAC automatically (I suspect it will) you'll need to include an installer that will install a .NET DLL to the GAC because the LabVIEW installer won't. The installer can be built from Visual Studio -most any version.



Link to comment

I get this every now and then.

I build an application and when I run it, it asks for a required dll even though it's right there in the data/ directory where it's expected. Then I rebuild the application - no changes to the source - and it works.

In my case, this is independent from the machine trying to run the application.

Link to comment
  • 2 years later...

I have the same question. I have some third party DLLs installed into the program files folder. As far as I can tell they are unsigned and not in the GAC (the public key token is null).

I can call the DLLs, but when I build an EXE, it shows the browse dialog if the DLL is not in the application folder. Selecting the DLL then does load the program correctly. I would rather not copy the EXE to the DLLs folder or copy all of them (to get all the dependencies) to the application's folder.

Creating a config file with a codebase element didn't seem to help either, probably because the assembly is unsigned.


Does anyone know of a way to point to a non-GAC DLL which is not under the folder of the EXE?

Link to comment

I would check another issue which is not mySQL related but rather generic to .net dll calls:

When you call a .net dll you should have:

1. The required .net version installed, preferable multitarget

2. If you are working from an older Version of LabVIEW you should also have .net 4.0.30319 multitarget installed with a config file next to LabVIEW and next to each of the exes that call that dll through LabVIEW's runtime according to 

3. .net 3.5 enabled under control panel -> add remove apps -> turn on off windows features (uncheck->ok->recheck->ok)

4. run full windows updates 

5. LabVIEW's runtime obviously

Create a vi that calls that dll. If the constructor gives you error 1172 you might have a .net version issue. If the properties calling a method gives your 1195 enable .net 3.5 and run windows update. If LabVIEW crashes you might have tried to tell an old LabVIEW to work with a .net version which is above .net 4 inside the config file.

If I understand correctly then old LabVIEWs were built for .net 2. The config file makes LabVIEW talk with .net 4. The Multitarget allows one .net version talk to another and thus, your problem might be related to a .net update that resulted in .net 4 not being able to talk with the new version.

Good luck.

Link to comment
On 10/20/2017 at 1:10 AM, ShaunR said:

You need to us gacutil.exe. to get it into GAC. It's like with the old ActiveX where you used to call regsrvr32 (but different :P ).

Yeah, doesn't look like a good option here, as there's no VS installed there and it looks like it's against the license to take that utility on its own. Looking at some links from searching for that showed this, which seems to indicate you should be able to call System.EnterpriseServices.Internal.Publish.GacInstall to add an assembly to the cache, but a quick test both with through PowerShell and through LV, both run as admin, failed to install it to the GAC (the method doesn't actually return an error. Instead, the error is logged to the system event log and has no actual useful details).

I think that for this specific project I will either copy the EXE into the DLL's folder or copy the DLL and all its dependencies into the EXE's folder. Ugly, but probably workable for this specific case and less of a hassle than the other options. I would have to check with the client what their preference is, but I doubt it's worth spending any more time on at the moment.



Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By X___
      I usually develop LabVIEW code on and for Windows (I used a MBP in the past, but exclusively developed within a Windows VM running on Parallel Desktop).
      A colleague of mine wanted to run an old app I had released on macOS a few years ago (labVIEW 17 was in the error log), and he reported that the app did not run anymore.
      I figured that since he was using macOS Monterey on an Intel MBP, there might be a chance that releasing the app using LV 2021 would work. Since my MBP runs macOS Catalina, I released it on that, sent him the executable and instructed him to download the 2021 RTE.
      That still doesn't work. I can't even make sense of the mangled error message he sent me.
      I know that Monterey is not even a term on NI's website, but I would assume that some have tried it already and maybe even released LabVIEW apps on it.
      Any hint as to what could be a problem in my workflow would be helpful.
      PS: the app is native G, there is no .NET, Active X or whatnot. I can actually upload the executable if someone wants to try it out on a Monterey Mac.
    • By P.Carpentier
      Hi Everyone,
      Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.
      So, i got an issue when i'm trying to install my build.
      I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"
      When googling this error message or even "winMIF" i can't find anything that match my request
      I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)

      The computer used to build is a Win7Pro with Labview 16.
      The target computer is a WES7 (but I got the same issue on my dev computer ...)

      In advance thank you, 

    • By WMassey
      I am trying to use the HTTP Client VIs to implement a version of the C# code found HERE. Unfortunately there are no NI examples of how the client VIs are to be used and my various attempts to string them together only seem to result in "Error 42" (LabVIEW: Generic Error) from the POST vi, rather than returning the headers and body text.
      I have also tried using DOTNET calls and was at least able to get the login page returned but could not seem to trigger the login.
      I switched to the HTTP Client VIs because they offered an alternate hope and I could at least see where to attach a cookie file with them (though a cookie file may not be the same as reserving space for a session cookie).
      Any guidance would be appreciated!

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.