References and VS Build Failures

[Chris Marsh]

All

I have a Visual Studio 2003 .NET project which was failing to build, on the
grounds that one of the [third party] assemblies (ICSharpCode.SharpZipLib)
was unable to be copied to the bin folder as it would overwrite another
assembly in the build folder with the same name but of a different version.
My first thought was that one of our projects referenced a later version of
this assembly, and that I would need to update our projects and rebuild them
in the right order in order that our assemblies all referenced the same
version of the third party assembly in question.

I could not find any of our projects that referenced any other version, by
doing a full text search of all .csproj files on my machine. I checked the
machine.config, but no information about the assembly in question was in
evidence. I checked the GAC, and the assembly in question was not registered
there. I deleted every bin and obj folder of every project, and rebuilt the
lot. I still had the same error. I searched the whole machine for instances
of the assembly dll, and checked the version of all of them - version 0.6.0
(which is what was being complained about) was not in evidence, only version
0.5.0. There were also a couple of instances of version 0.84.0, but these
were connected ot other applications, and appeared to have no connection to
my projects. I searched the registry for the assembly name, and came up with
nothing.

Eventually, I registered version 0.5.0 in the GAC, and received no more
complaints. This treats the symptom, but I don't know why - nor do I know if
this solves the underlying problem or whether I've merely hidden it. Where
was VS getting the reference to version 0.6.0 from?

Can someone give me any pointers opf what I've missed, so that I can
understand what's going on, and solve the problem conclusively?

Many thanks in advance!

 

[WenYuan Wang [MSFT]]

Hello Chris,

I guess your project may reference to some other assembles which indirectly
reference to ICSharpCode.SharpZipLib dll. Thus, there is no any entry
(which reference to SharpZipLib.dll directly) in your .csproj file. Because
SharpZipLib dll doesn't exist in GAC, the project failed to compile. After
you registered it in GAC, the issue goes away. As far as I know, there is
no tool to list all assembles which referenced (directly/indirectly) in
project easily. One way is to use .Net Reflector to check each reference in
your project.
http://www.aisto.com/roeder/dotnet/

Hope this helps
Best regards,

Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Chris Marsh]

Wen

Thanks very much for the response. I've spent a lot of time studying
assembly binding over the past couple of days, and I have a much greater
understanding now - but still have some learning to do.

I guess your project may reference to some other assembles which
indirectly
reference to ICSharpCode.SharpZipLib dll. Thus, there is no any entry
(which reference to SharpZipLib.dll directly) in your .csproj file.
Because
SharpZipLib dll doesn't exist in GAC, the project failed to compile. After

Ah, but the project didn't fail to compile because the assembly could not be
found, it failed because two versions of the same assembly were being copied
to the bin directory of the project. This is where my confusion lies - if
one (we don't know which one) of the referenced assemblies is referencing
version 0.6.0.0 of the ICSharpCode.SharpZip assembly and trying to copy it
to the bin directory, why is the build not failing on the grounds that this
version (0.6.0.0) cannot be found? And why does copying the
ICSharpCode.SharpZipLib assembly version 0.5.0.0 the GAC prevent whichever
assembly was referencing version 0.6.0.0 kicking up a fuss? I thought that
this was one of the points of strong naming, so that if a particular version
of an assembly is referenced then this is the version that will be bound.

you registered it in GAC, the issue goes away. As far as I know, there is
no tool to list all assembles which referenced (directly/indirectly) in
project easily. One way is to use .Net Reflector to check each reference
in
your project.
http://www.aisto.com/roeder/dotnet/

Yes, I started using this yesterday - thanks for the tip.

In addition to actually solving this specific problem, I'm also trying to
use it as a base for gaining a much more in-depth understanding of assembly
binding by the runtime. Someone posted some really useful articles, but it
occurred to me that what would be great would be a flow chart detailing all
steps taken by the runtime in order to resolve assembly bindings. Does
anyone know if one of these exists? If not I'll have a crack at knocking one
up in Visio - possibly people in this group may like to critique it
afterwards. I'd rather someone else had already done it for me, though

Thanks again.

Cheers!

 

[WenYuan Wang [MSFT]]

Hello Chris,
Thanks for your reply.

There must be something make VS IDE put SharpZip assembly into bin folder
when building. But, I am afraid it's not easy for us to find out the exact
root cause without further information captured when the problem occurs.

I haven't a flow chart for assembly runtime binding. Hope the following
document helps.
http://msdn2.microsoft.com/zh-tw/library/yx7xezcf(VS.90).aspx
[How the Runtime Locates Assemblies]

Have a great day,
Best regards,

Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.