Referenced DLLs in your .NET Application

Does the CLR work differently in the Visual Studio versus outside the Visual Studio environment when it comes to loading referenced dlls?  
In the Visual Studio when you look at the properties of a referenced dll, you see its absolute path. However, how does the CLR search for a referenced dll in the Visual Studio environment versus outside the Visual Studio environment?

In particular, are the .NET Framework Libraries in the GAC for easy access?
Lawrence AverySystem DeveloperAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jacques Bourgeois (James Burger)PresidentCommented:
The CLR first looks into the application's configuration file and in the machine.config file to see if there is a redirection there that tells it to use a newer version of the dll than the one specified in the application manifest.

In then also looks in there for a Codebase entry, that could define the location of the dll.

If nothing is found, it looks in the application directory.

If the dll is not there, it looks in the GAC.

If still not found, it triggers an exception.

The GAC takes the role that the old System directory did for Windows. It is a repository for dlls that could be shared by many applications.

But it is a lot more useful, because it can hold many versions of the same dll and provides each application with the version with which it was compiled. Since putting something in there is done through an application (gacutil, it works under the hood when you install and uninstall dlls in the GAC), it has good control and prevents a bad installation from destroying the job done by another. Working in there requires administrator privileges, which also prevents the user from filling it with crap.

Because of that last requirement, it is not recommended to put your own dlls in there, but to install in the application directories. This is why Visual Studio copies the dlls that are not part of the framework in the application directory when you compile the application.

However, if you work for a company that has a standard dll that is used by many in-house applications, the GAC might be the best place for that dll.
0
Naman GoelPrinciple Software engineerCommented:
Please refer to following link:

http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

actually it should not matter you are using Visual studio or something else, AppDomain is loading everything that are referenced in same way.
0
Lawrence AverySystem DeveloperAuthor Commented:
You know I always thought if the dll had a strong name, it would automatically check the GAC first of all the areas it searches.
Additionally, the question about the .NET libraries being referenced. AM I correct that the .NET Library .dlls are being referenced in the GAC versus what the PATH property indicates for the dll in the Visual Studio environment?
0
Become a Microsoft Certified Solutions Expert

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Jacques Bourgeois (James Burger)PresidentCommented:
You have it a little in reverse. If the dll does not have a strong name, then the framework will look only in the application directory, nowhere else.

If the dll has a strong name, it can be in many different locations, and the GAC is not the first on to be checked. A dll in the application directory will always be the first. You might have added a Codebase entry in the application, machine or some other config file telling the system where to get the dll, maybe in a Common directory somewhere on the computer, or on a remote connection. Think of it, if you took care of specifying where the dll is, it would not make sense for the system to look in the GAC first.

The path in Visual Studio is not a direct indication of where the dll will be loaded from when ran in Visual Studio. The Copy Local property of each reference will determine that.

As soon as you set Copy Local to True, which is the default for dlls that you reference through Browse or Project, Visual Studio will make a copy of the dll in the application compile directory (bin by default) and use that copy instead of the one pointed to by the path. That way, if you work in a team, another programmer can continue working on the dll without causing you problems, because you are working on a copy of the dll. The path is recorded through, in order to copy again should you scrap the bin directory or delete the dll from bin to force Visual Studio to fetch a newer version.

In order to use the dll pointed to by the path, Copy Local should be set to False. In such a case, dlls in the GAC will be used the usual way, dlls that are not in the GAC will be referenced by a temporary Codebase.
0
Lawrence AverySystem DeveloperAuthor Commented:
Check this article out and look at the Section called Private Assemblies:
Read the fourth and fifth paragraphs of that section. Tell what you think of this guy
Ted Pattison says.


http://msdn.microsoft.com/en-us/magazine/cc164080.aspx
0
Jacques Bourgeois (James Burger)PresidentCommented:
In more words that I did, it comes to what I said before: it is not recommended to put your own dlls in the GAC, but to install in the application directories.

One work about XCOPY deployment. This is the first thing I show to my students when we discuss deployment. It is indeed the simplest possible form of deployment if it works for the application, meaning a simple thing that do not require to install extra dlls in the GAC or outside of the application directory.

But it has a few drawbacks: it will not create a desktop or startup menu shortcut to launch the application. This has to be done manually. It won't add an entry in the Control Panel so that the user cannot uninstall the application from there. He has to manually delete the directory.

So as a first deployment strategy, it is not very interesting. But as an update strategy, it is a very viable solution for simple programs.
0
Lawrence AverySystem DeveloperAuthor Commented:
In the fifth paragraph it indicates the GAC is searched first and you indicate that is not the first.  Did I misread what the article said?
0
Jacques Bourgeois (James Burger)PresidentCommented:
It looks as if we do not have the same 5th paragraph. I do not see anything about the GAC in the 5th paragraph, the one that begins with "One of the biggest advantages". But I see something in the 8th paragraph.

However, this is in contradiction with something that is said later. If you look at the first paragraph after the 3rd block of code: You should see that the CLR is going to load the DLL in the ApplicationBase directory because that is always the first directory searched by the CLR during the probing process.

When an author contradicts itself, I am always suspicious of the whole article.

And by the way, be careful about taking information wherever you find it on the Internet. The link you provided points to something that was written in October 2003, when framework 1.1 was brand new. A lot has happened in the last 10 years, although, for the sake of the current discussion, most what is said there still holds once you disregard the contradictions.

My experience shows that the second statement describes what happens: the application directory is always the first directory searched.

I have been working with the framework since 2 years before it was officially released, as a consultant and trainer, so I see a lot of projects during a year. I encountered a few instances were programmers had a dll deployed in the GAC, but installed an older version of the dll in the applications directory for one application, because that older application was not working with the new version of the dll, and they decided that installing that old version in the GAC was useless since that older version was used only by that one application. The dll in the application directory was automatically used.

Note that you usually do not need to care about that stuff. The decision to put a dll in the GAC is an important one. And once it is taken, except for very special scenarios, you have no reason to deploy the dll any other way later. You might not be aware of this, but many different versions of the same dll can coexist in the GAC. This is the main reason for strong names. Applications will launch with the copy of the dll they have been compiled with, unless a redirection has been defined in a configuration file.

The best way for you to make sure is to test the thing. That is what I always end up doing when I see contradictions everywhere.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Lawrence AverySystem DeveloperAuthor Commented:
My question on the actual .NET Framework Library dlls ( v2, 3, 4.0 , .etc ); when you reference them in Visual Studio, looking at their properties each resides under a directory mostly C:\Program Files(x86)\Reference Assemblies\..... or C:\Windows\Microsoft.NET\Framework\...


When you deploy your .NET Application, where is the .NET APPLICATION finding the .NET Framework 2,3, 3.5, 4.0 dlls? How does it look for them?  I mentioned above that the .NET FRAMEWORK libraries are accessed in the GAC, but looking at my GAC it would appear not so. Why I say that  is that I don't see all the .NET Framework dlls there in my GAC.
Obviously, they're are not in your application directory.
0
Lawrence AverySystem DeveloperAuthor Commented:
I found the answer by using some testing code. The CLR will look at that corresponds to the runtime specified not what is necessarily specified in the Visual Studio Reference folder.

See attached testing material.
If you change the app.config runtime version- alternating them, you will find what versions of the .NET dlls it is using in the application. You definitely see the change. The only thing I am curious about is when a dll that was in (.NET 2.0, 3.0, 3.5) but not in .NET 4.0, what happens. DO I have to put some kind of redirection in to get my dll from a previous version?
Using-different-CLRs-2-to-4.txt
0
Naman GoelPrinciple Software engineerCommented:
Yes, also gac will searched for same type of public key token regardless of references.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.