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.

Chris

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.

 

Mark

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 
http://digital.ni.com/public.nsf/allkb/32B0BA28A72AA87D8625782600737DE9

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.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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