[RESOLVED] DLL copy local issue

[hopia]

Hello, I need help on DLL that is set Copy Local = false. Upon running the program, i receive this error message.

An error occurred creating the form. See Exception.InnerException for details. The error is: Could not load file or assembly 'MyPersonalLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.


Basically, i just use "Imports MyPersonalLib" and Whenever the DLL's property Copy Local = true, there is no error.


Do i miss something? Is there anything i need to do to have this program work even on Copy Local is set to false?

[NeedSomeAnswers]

hmmmm,

What do you think happens when you set Copy Local = false ? it does not copy the dll across with your exe into the output directory.

So if you then try and run your program, surprise surprise the dll is missing and it cant run!!

Your referencing that dll so you need to include it in your package, the question is really why would you not do so??

[SJWhiteley]

Why do you want to set CopyLocal to False?

The main assembly needs to know how to find the referenced assembly; it will first look in it's own folder. This is where the 'local copy' will be placed.

[techgnome]

Imports has nothing to do with the problem. It's simply a developer shortcut so you don't have to type the full namespace when you use something in it. That's all, nothing more, nothing less.
What's at the heart of the issue is the reference itself and how it was created in the first place. What the copy local does is when you compile the app, it will go to the source where the file was originally found and copy it to the outputFolder of the app. For the most part, this should be turned on, UNLESS 1) the file you're referencing can be found on the target systems IN THE SAME PLACE. or 2) What you're referencing is found in the GAC, and can also be found in the GAC on the target system (see previous point about it being in the same place).
So... it sounds like you have a reference to thhis DLL, only it's not where the IDe is expecting it (app folder) ... and that's why you're getting the error.

-tg

[hopia]

hmmmm,
What do you think happens when you set Copy Local = false ? it does not copy the dll across with your exe into the output directory.

--> Yes, it will not create copy of the DLL on the debug folder.

So if you then try and run your program, surprise surprise the dll is missing and it cant run!!

--> Exactly.

Your referencing that dll so you need to include it in your package, the question is really why would you not do so??

--> I'm referencing the DLL, however, i don't want my DLL to be with my EXE file. I want my DLL to reside on specific folder. Time will come other programs will call that DLL too. To be safe, i want to store it in 1 folder.

Why do you want to set CopyLocal to False?

-->I don't want to have local copy of my DLL on debug folder. I want my DLL to be placed in 1 folder.

The main assembly needs to know how to find the referenced assembly; it will first look in it's own folder. This is where the 'local copy' will be placed.

-->How can i do it? I mean, on the Properties of the project --> References, i already set the path to my folder where i want my DLL to reside.

Imports has nothing to do with the problem. It's simply a developer shortcut so you don't have to type the full namespace when you use something in it. That's all, nothing more, nothing less.
What's at the heart of the issue is the reference itself and how it was created in the first place. What the copy local does is when you compile the app, it will go to the source where the file was originally found and copy it to the outputFolder of the app. For the most part, this should be turned on, UNLESS 1) the file you're referencing can be found on the target systems IN THE SAME PLACE. or 2) What you're referencing is found in the GAC, and can also be found in the GAC on the target system (see previous point about it being in the same place).
So... it sounds like you have a reference to thhis DLL, only it's not where the IDe is expecting it (app folder) ... and that's why you're getting the error.

-tg

Local copy should be turned on? What if i have lots of projects using that DLL. Let's say it is dbConnectionDLL, then each project will have that DLL. When the time came that i need to revise dbConnectionDLL then i would have to replace all the DLL placed on each project. Isn't good to turn it off?

Yes, the error message says it cannot find the DLL i'm using where in fact i set the path of the DLL (Properties --> References). How can i get rid of this error while local copy is set to false?

[techgnome]

Local copy should be turned on? What if i have lots of projects using that DLL. Let's say it is dbConnectionDLL, then each project will have that DLL. When the time came that i need to revise dbConnectionDLL then i would have to replace all the DLL placed on each project. Isn't good to turn it off?

Yes, the error message says it cannot find the DLL i'm using where in fact i set the path of the DLL (Properties --> References). How can i get rid of this error while local copy is set to false?

You sign it and install it into the GAC.

-tg

[hopia]

You sign it and install it into the GAC.

-tg

Thanks tg. do you have any references or related tutorial?

[techgnome]

Nope... I avoid loading things into the GAC.

-tg

[FunkyDexter]

Here's an MSDN article on how to do it:-
https://msdn.microsoft.com/en-us/lib...v=vs.110).aspx

[SJWhiteley]

Nope... I avoid loading things into the GAC.

I would tend to concur. I think this pushes us back into DLL Hell.

[FunkyDexter]

I'm 50/50. If your objective is to maintain a single instance of a dll on the machine then the GAC's the right way to go about it. If you want different consumers to be able to access different versions of it then, yeah, it's DLL hell by a different name and I'd go with Copy Local even if that meant that two consumers that actually wanted the same version had to have their own instance - it's just easier to manage.

The thing is, if you want different versions then there really is no good way of managing it - you've got configuration management to do and no tool is going to avoid that for you.

[techgnome]

It's better managed I think...the problem with DLL Hell is when you had multiple copies registrered... at least the GAC is a single repository so only one version can be installed into the GAC at any given time... but you could still potentially run into versioning issues, which is its own Level of Hell.

-tg

[NeedSomeAnswers]

--> I'm referencing the DLL, however, i don't want my DLL to be with my EXE file. I want my DLL to reside on specific folder. Time will come other programs will call that DLL too. To be safe, i want to store it in 1 folder.

Nope... I avoid loading things into the GAC.

I would tend to concur. I think this pushes us back into DLL Hell.

A agree your looking at this from an old perspective.

One of the nice things about .Net is we can have the same dll packaged many times with different programs that use it. With .Net you can have multiple copies of the same dll on a machine in different folders.

Initially it might seem a bit wierd that your having multiple copies of the same file, but dll's are generally tiny files they take up little disk space and so there is very little cost to having multiple of them.

That is the approach i take, and i would recommend you take too, it doesn't cost you anything and will save you a load of bother.

[hopia]

Thanks your for replies. I read GAC on MSDN and I decided not to implement it. However, i still want to maintain my DLL in 1 folder to avoid DLL HELL so i came up with this idea. My workaround is i created a batch file that copy all the DLL i'm using from the source folder to app.path then delete it after the program execution. So far, its working as expected.

I think this workaround will also eliminate DLL HELL.

My objective to maintain DLL in 1 folder was also met.


My workaround: Hope this will help others who has the same issue.

echo off
copy "%ProgramFiles%\Test\Shared\Lib\MyTest.dll" "%ProgramFiles%\MyApp\subfolder" /Y
copy "%ProgramFiles%\Test\Shared\Lib\MyTest_2.dll" "%ProgramFiles%\MyApp\subfolder" /Y
copy "%ProgramFiles%\Test\Shared\Lib\MyTest_3.dll" "%ProgramFiles%\MyApp\subfolder" /Y
copy "%ProgramFiles%\Test\Shared\Lib\MyTest_4.dll" "%ProgramFiles%\MyApp\subfolder" /Y
echo on
"%ProgramFiles%\MyApp\subfolder\MyApp.exe" param1 param2 param3 param4 param5
echo off
del "%ProgramFiles%\MyApp\subfolder\MyTest.dll"
del "%ProgramFiles%\MyApp\subfolder\MyTest_2.dll"
del "%ProgramFiles%\MyApp\subfolder\MyTest_3.dll"
del "%ProgramFiles%\MyApp\subfolder\MyTest_4.dll"

[techgnome]

Ugh... you don't truly understand DLL Hell then ...

DLL Hell happens when you install application 1... and it puts a DLL in a spot... and then registers it...... then you install application 2, which also uses that DLL, but a different version... and it puts it in a different location, then registers THAT version... now you have two conflicting version of the DLL registered with the system... Then comes app 3, 4... and then your app... and what ends up happening is your registry is all scrwed up and you can't tell which one is the registered one, and whether it's even the right one you need. Because of this the common prctice was to ensure that there was only one copy, and you were kind of tied to it.

But with .NET it's different... because .NET assemblies ARE NOT registered, there is no opportunity for the registry to get messed up. because it's expected that the assembly will either be in the application folder or in the GAC, you can't get cross mixing so you don't need to worry about picking up the wrong version.

In short, you're worrying about a problem that doesn't exist, and potentially creating new issues for you down the road.

Also I should note, that program files has limited write capabilities... so there's a chance that your copy scheme will fail.

-tg

[hopia]

What if we are talking the same DLL that have the same version? I mean dbConnectionDLL, let say application1, application2, application3 uses that DLL for DB connection. Is it recommended to store dbConnectionDLL on application folder?

I understand that when there's a new version of dbConnectionDLL, i will have conflict thus i must recompile my program. I case that dbConnectionDLL will stay as is, no more revisions, can i use my workaround? If not, what would you advice me then? Place the dbConnectionDLL on the application folder?

Thanks

[techgnome]

Yes... In each case it would be in the application folder. So if you install three apps that use it you end up with the assembly in three places, one for each application.

-tg

[FunkyDexter]

MMmmm, I'm going to differ... or at least refine.

If you want all your applications to use the same version I would upload it to the GAC. That way, if you update the version later, you only need to upload it once. All your applications will use the updated version.

If you want your applications to use different versions then you should hold them in the application folders. This allows you to manage the version being used by each application independently.

If it's never going to change then it really doesn't matter which you do because the only material difference between the two approaches is how you manage change.

So TG's answer is correct because, from what you've described you fall into the third category, so it doesn't matter. But if you want to ensure that updating the dll for one updates the dll for all, then the GAC would be a better option.

There's another option that I'll include for completeness but I don't recommend it because it's likely to get confusing (not as bad as DLL hell... more like DLL purgatory). You can have one "master" version in the GAC and you can "override" that version for a particular application by putting a different version in that application's application folder. I think this would probably become difficult to manage though so I'd steer clear of it unless you have a very specific requirement.

[TnTinMN]

My 2¢'s worth.

Avoid the GAC as the repository for your development assemblies. The biggest problem with using the GAC is that you are unlikely to include it in your backup program (assuming you back up) and you likely do not want to backup everything in there anyways. Another issue is that you can not reference a assembly in the GAC directly from VS. There is an add-in that allows you to do it, so I guess there must be enough people using this practice to warrant that effort.

If you want a separate repository for certain assemblies, create one. You can even make it easy to reference those assemblies in VS via the Add Reference mechanism by creating a registry key as described in "How to: Add or Remove References By Using the Add Reference Dialog Box" and is the method I use. Depending on your VS version, the folder contents will be listed either in the ".Net tab" or under "Assemblies-Extensions". The path you specify can even be a network folder, though that can be problematic when disconnected.

Also, I seen it implied that the GAC can not store multiple versions. This is not true. The GAC stores an assembly via a combination of its: 1) Name, 2) Version, and 3) its public key token. While its is possible that you could match all three items and create a DLL versioning hell situation, it is highly unlikely. When reference a an assembly with multiple versions in the GAC, VS automatically marks it as version specific.

[hopia]

Thank you for all the replies, this will serve as reference for me in my other projects.

Anyway, i will just deploy my program and DLL on their own application folder.