Why are assemblies loading from the GAC?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Schemer - 20 Jun 2006 17:25 GMT

Hello,

I'm building a project in VisStudio 2005. I have .Net component that put
several assemblies in the GAC. However, I want to test local versions of
those assemblies. In my VisStudio2005 project I explicitly reference the
assemblies in a particular directory, and set CopyLocal=TRUE.

When I start my project in the debugger, I see that the assemblies I'd like
to debug aren't getting loaded; instead, the version in the GAC is.

What's going on?
(I'm pretty sure this I used to be able to debug my local dlls.)

Thanks for any help.

Reply to this Message

Michael Nemtsev - 20 Jun 2006 19:22 GMT

Hello Schemer,

Because CLR start looking for assebmly from the GAC.
To override this behaviour you need to redirect it in the config file to
the version in you private folder.
Seems that u need specify assemblyBinding tag in config

S> I'm building a project in VisStudio 2005. I have .Net component that
S> put several assemblies in the GAC. However, I want to test local
S> versions of those assemblies. In my VisStudio2005 project I
S> explicitly reference the assemblies in a particular directory, and
S> set CopyLocal=TRUE.
S>
S> When I start my project in the debugger, I see that the assemblies
S> I'd like to debug aren't getting loaded; instead, the version in the
S> GAC is.
S>
S> What's going on?
S> (I'm pretty sure this I used to be able to debug my local dlls.)
S> Thanks for any help.
S>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Schemer - 20 Jun 2006 19:51 GMT

Thanks for the reply.
If you mean the .csproj file, I already have this:
<Reference Include="Digger.Backhoe, Version=4.0.0.394, Culture=neutral,
PublicKeyToken=93e298a0f6b95eb1">
<HintPath>..\..\..\..\exports\duw32\Digger.Backhoe.dll</HintPath>
<SpecificVersion>False</SpecificVersion>
<Private>True</Private>
</Reference>

Or is there another configuration file I should look at?

> Hello Schemer,
>
[quoted text clipped - 20 lines]
> "At times one remains faithful to a cause only because its opponents do
> not cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Michael Nemtsev - 20 Jun 2006 20:00 GMT

Hello Schemer,

Your.exe.config file

if it missed, add in from the project. Add New->App.config

S> Thanks for the reply.
S> If you mean the .csproj file, I already have this:
S> <Reference Include="Digger.Backhoe, Version=4.0.0.394,
S> Culture=neutral,
S> PublicKeyToken=93e298a0f6b95eb1">
S>
S> <HintPath>..\..\..\..\exports\duw32\Digger.Backhoe.dll</HintPath>
S> <SpecificVersion>False</SpecificVersion>
S> <Private>True</Private>
S> </Reference>
S> Or is there another configuration file I should look at?
S>
S> "Michael Nemtsev" <nemtsev@msn.com> wrote in message
S> news:1799a79b399b918c862cf37167639@msnews.microsoft.com...
S>

>> Hello Schemer,
>>
[quoted text clipped - 22 lines]
>> "At times one remains faithful to a cause only because its opponents
>> do not cease to be insipid." (c) Friedrich Nietzsche

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

Marina Levit [MVP] - 20 Jun 2006 20:01 GMT

No, he is talking about the application configuration file. The project
file is only used for visual studio so it knows what files are part of your
project, etc.

The CopyLocal property is just to tell visual studio whether or not to copy
the file over to wherever the DLL or executable is being compiled to. It is
completely unrelated to anything that happens at runtime, and again, is only
for visual studio.

> Thanks for the reply.
> If you mean the .csproj file, I already have this:
[quoted text clipped - 31 lines]
>> "At times one remains faithful to a cause only because its opponents do
>> not cease to be insipid." (c) Friedrich Nietzsche

Reply to this Message

"Jeffrey Tan[MSFT]" - 21 Jun 2006 11:18 GMT

Hi Schemer,

Thanks for your post!

Yes, I can reproduce out this behavior. CLR will always load the signed
assembly from GAC not your local copy of assembly.

Actually, this behavior is defined by the design of CLR probing logic,
please refer to the article below:
"How the Runtime Locates Assemblies"
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx

As you can see the CLR runtime will always check GAC before private
folders. This behavior can not be changed in .Net1.1. However, in .Net2.0,
you can override the probing logic by hosting CLR, please refer to our
Fusion developer Junfeng Zhang's blog below:
"Override CLR Assembly Probing Logic ---
IHostAssemblyManager/IHostAssemblyStore"
http://blogs.msdn.com/junfeng/archive/2006/03/27/561775.aspx

Anyway, in your scenario, I think the simplest workaround is uninstalling
the assembly from GAC.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Schemer - 21 Jun 2006 12:27 GMT

Thanks for all the replies.

It appears that when my local dlls had the same version number as those in
the GAC, the assemblies in the GAC were loaded (even when the local dlls
were referenced specifically).
When my local assemblies have a different version number, they get loaded
and I can debug them.

> Hello,
>
[quoted text clipped - 10 lines]
>
> Thanks for any help.

Reply to this Message

"Jeffrey Tan[MSFT]" - 22 Jun 2006 03:06 GMT

Hi Schemer,

Thanks for your feedback!

Yes, .Net assembly Strong Name signature is consisted of : its simple text
name, version number, and culture information (if provided) ---- plus a
public key and a digital signature. Once these parts remain the same, 2
assemblies are the same. So your local copy of assembly is the same as the
one you deployed to the GAC. Because of the CLR assembly locating
algorithm, CLR rumtime will always prefer to load GAC copy of your
assembly. Actually, in this scenario, I think it does not matter if CLR is
using the local copy or the GAC copy of assembly, because they are the
same. :-)

Once you changed the version in your local copy of assembly, its Strong
Name signature is changed, so the signature verfication algorithm believes
that your assembly is not the same as the one in the GAC. Since your
project is referring the local copy assembly in the "Add Reference" dialog,
at rumtime, CLR does not believe the one in GAC is what you are referring,
it will use the one in your private bin folder. That's why changing the
version number will prohibit the CLR from loading GAC version of assembly.
Hope this information helps you.

In this scenario, I recommend you not sign the assembly first, and use the
non-Strong Named assembly for debugging purpose. After fully testing, you
may deploy it to the GAC with signing the assembly. I think this way is
more convinient than changing the version number of your local copy
assembly, since after testing the local copy, you still have to deploy it
to GAC again.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Why are assemblies loading from the GAC?

Free Magazines