Version conflicts between local and GAC

  • Thread starter Thread starter Bob Altman
  • Start date Start date
B

Bob Altman

All,

I have a couple of strong name signed library assemblies stored on a local disk
(e.g. C:\My assemblies\). Assembly A calls into assembly B. These two
assemblies are built by the same solution. Assembly A has a "project reference"
to assembly B.

I have an application that calls into both assemblies. When I added the
assembly references in this application, I pointed it at the assemblies in C:\My
assemblies\.

So, the point here is that my app calls A, which calls B, and my app directly
calls B, so B is both directly referenced by my app and indirectly referenced
through A.

Now, if assembly B in C:\My assemblies is at version 1.0.0.1, but I have version
1.0.0.0 of assembly B installed in the GAC, then I get the following warnings
when I try to compile my app:

Consider app.config remapping of assembly "A, ...."
from version "1.0.0.0" [C:\WINDOWS\assembly\GAC_MSIL\...]
to version "1.0.0.1" [C:\My assemblies\...]
to solve conflict and get rid of warning.

warning MSB3247: Found conflicts between different versions
of the same dependent assembly.

So, what's the deal here? I have verified that assembly A (in C:\My assemblies)
was most recently built with version 1.0.0.1 of assembly B. Why is VS looking
in the GAC when I told it to find my assembly in "C:\My assemblies"? In
general, if I have an older version of an assembly installed in the GAC, can I
not compile with the current version of the assembly without this warning?

TIA - Bob
 
Hi Bob,

As fort the warning you saw, it is due to the following reason:

** You have referenced a strong-named assembly in your project

** There are two copy of this assembly on the machine(one in GAC and one in
your project's local private folder), however, the GAC one's version
doesn't match the one you referenced.

** The .net framework runtime will always lookup the GAC first for
strong-named assemblies(and private probing path is used at the later
stage). Here is a good reference explain the .NET clr's assembly locating
steps:

#How the Runtime Locates Assemblies
http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

Also, the assembly path you used to reference assembly in Visual Studio(at
design/compile) time is totally different from how the .NET runtime will
search for assembly when the application is actually running. the Reference
path in VS project is only providing a location where you can get a copy of
the assembly so as to compile/buildd the application(it has nothing to do
at runtime).

here are some other good reference about assembly's loading and version
redirection:

#How to load an assembly at runtime that is located in a folder that is not
the bin folder of the application
http://support.microsoft.com/kb/837908

#Redirecting Assembly Versions
http://msdn2.microsoft.com/en-us/library/7wd6ex19(VS.71).aspx

Hope these help you.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.



--------------------
From: "Bob Altman" <[email protected]>
Subject: Version conflicts between local and GAC
Date: Thu, 27 Mar 2008 17:49:36 -0700

All,

I have a couple of strong name signed library assemblies stored on a local disk
(e.g. C:\My assemblies\). Assembly A calls into assembly B. These two
assemblies are built by the same solution. Assembly A has a "project reference"
to assembly B.

I have an application that calls into both assemblies. When I added the
assembly references in this application, I pointed it at the assemblies in C:\My
assemblies\.

So, the point here is that my app calls A, which calls B, and my app directly
calls B, so B is both directly referenced by my app and indirectly referenced
through A.

Now, if assembly B in C:\My assemblies is at version 1.0.0.1, but I have version
1.0.0.0 of assembly B installed in the GAC, then I get the following warnings
when I try to compile my app:

Consider app.config remapping of assembly "A, ...."
from version "1.0.0.0" [C:\WINDOWS\assembly\GAC_MSIL\...]
to version "1.0.0.1" [C:\My assemblies\...]
to solve conflict and get rid of warning.

warning MSB3247: Found conflicts between different versions
of the same dependent assembly.

So, what's the deal here? I have verified that assembly A (in C:\My assemblies)
was most recently built with version 1.0.0.1 of assembly B. Why is VS looking
in the GAC when I told it to find my assembly in "C:\My assemblies"? In
general, if I have an older version of an assembly installed in the GAC, can I
not compile with the current version of the assembly without this warning?

TIA - Bob
Click to expand...
 
Steven Cheng said:
Hi Bob,

As fort the warning you saw, it is due to the following reason:

** You have referenced a strong-named assembly in your project

** There are two copy of this assembly on the machine(one in GAC and one in
your project's local private folder), however, the GAC one's version
doesn't match the one you referenced.

** The .net framework runtime will always lookup the GAC first for
strong-named assemblies(and private probing path is used at the later
stage). Here is a good reference explain the .NET clr's assembly locating
steps:

#How the Runtime Locates Assemblies
http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

Also, the assembly path you used to reference assembly in Visual Studio(at
design/compile) time is totally different from how the .NET runtime will
search for assembly when the application is actually running.
Click to expand...

Yes, I understand how the .Net runtime binds to assemblies at run-time. But
this is a compile-time issue. Let me ask a simpler question:

I have a DLL installed in the GAC. I want to compile with a newer version
version of that same DLL plus another DLL that references that same DLL (both
are not in the GAC). Is there any way to do this without getting the compiler
warning?

Bob
 
Never mind, I figured it out. Turns out that it has nothing to do with the fact
that I have something installed in the GAC. Rather, I actually do have an
assembly that is referencing the version that exists only in the GAC.

The upshot of this is that the warning is really for the reason that it states:
I really do have references to different versions of the same assembly. The
fact that the reference was satisfied out of the GAC was just a red herring.

Bob
 
Thanks for your reply Bob,

I'm glad that you've figured out the issue. Also glad that the Visual
Studio works in the correct way :)

Have a good day!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for your reply Bob,

I'm glad that you've figured out the issue. Also glad that the Visual
Studio works in the correct way :)

Have a good day!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
I'm glad that you've figured out the issue. Also glad that the Visual
Studio works in the correct way :)
Click to expand...


It would have been helpful if the warning message clearly told me which
assemblies were involved in the version conflict. It turned out that the
assembly that brought in the conflicting version was indirectly referenced
by another assembly. In other words:

My app references A and B
A references B and C
C references an older version of A

I didn't realize (until I did a lot of digging) that assembly C was even
part of the issue. I was focused on looking at assemblies A and B, since
those are the only assemblies I directly use. Even the "diagnostic" build
log didn't point me at assembly C as being the culprit. I had to use ildasm
to go digging through the assembly manifests looking at external references.

I guess it's time for a trip to MS Connect for an "enhancement" request...

Bob
 
Thanks for your followup Bob,

Yes, for projects that may contain large number of assemblies and complex
reference graph, it would be helpful to point out the error point. Sure,
you're welcome to submit this as feature request on the connect site.
Really appreciate your feedback.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
 
Glad I found this thread (sorry you ran into it also, however). I have run
into the same issue with System.dll and System.Drawing.dll, and reading this
thread I wasn't sure what exactly the ultimate resolution was. Can you share
how the warning was addressed, or was it?
 
Back
Top