At wits end dealing with "Assembly's manifest does not match assembly reference". Need help understa

[Richard Lewis Haggard]

We are having a lot of trouble with problems relating to failures relating
to 'The located assembly's manifest definition with name 'xxx' does not
match the assembly reference" but none of us here really understand how this
could be an issue. The assemblies that the system is complaining about are
ones that we build here and we're not changing version numbers on anything.
The errors come and go with no apparent rhyme or reason.

We do not see where the problem is coming from. We've done the obvious
things (look at the reference properties, make sure that the version number
shown is the same as the one in the DLL's file properties) and don't see
where the problem is coming from. The version numbers look right. We've
looked high and low for stale copies of the assemblies and, while multiple
copies of the various assemblies exist, they all appear to be the same
revision.

Background:
We're building a number of C# classes which are being hosted in C# exe test
programs, ASP.NET pages, conventional ASP pages and VB programs.
Building C# class assemblies in Dev Studio 2003.
The codebase is contained within two Dev Studio solutions.
- One is a small set of c# classes that haven't changed in months.
- The other is the on going development effort.
When a new project is added, it's AssemblyInfo.cs file gets two and only two
changes:
- AssemblyDelaySign(true) and
- the AssemblyKeyFile points to a key file that is shared across the entire
project.
The project post build event has two lines in it
- Sn -Vr "$(TargetPath)"
- and a DOS copy command to put the signed assembly in a common staging
area.
There are interop classes that permit unmanaged code to access the classes.
The managed code makes use of the classes directly.
The project TestAccount is set as the startup project.
When TestAccount builds, copies of the various assemblies are copied to its
product output directory.
The assemblies are not being added to the GAC.

Typical failure:
- Object a, which is in assembly B, is successfully created through the use
of new B.
- An exception is thrown when a function in a is called.
- The exception says that the located assembly's manifest definition does
not match the assembly reference.

Questions:
Q1) Under what conditions can a mismatched version error manifest?
Q2) How can we find and fix the reason(s) for the multiple, sporadic
manifest mismatch problems?
Q3) When TestAccount.exe runs, what is the process that executes that lets
it know what assembly versions to look for?
Q4) Where are these values stored?
Q5) What is the search path for the target assemblies?
Q6) Why does the object creation succeed but the call to the object's
function throw an exception?

 

[Nick Malik [Microsoft]]

We are having a lot of trouble with problems relating to failures relating
to 'The located assembly's manifest definition with name 'xxx' does not
match the assembly reference" but none of us here really understand how
this could be an issue. The assemblies that the system is complaining
about are ones that we build here and we're not changing version numbers
on anything. The errors come and go with no apparent rhyme or reason.

We do not see where the problem is coming from. We've done the obvious
things (look at the reference properties, make sure that the version
number shown is the same as the one in the DLL's file properties) and
don't see where the problem is coming from. The version numbers look
right. We've looked high and low for stale copies of the assemblies and,
while multiple copies of the various assemblies exist, they all appear to
be the same revision.

Background:
We're building a number of C# classes which are being hosted in C# exe
test programs, ASP.NET pages, conventional ASP pages and VB programs.
Building C# class assemblies in Dev Studio 2003.
The codebase is contained within two Dev Studio solutions.
- One is a small set of c# classes that haven't changed in months.
- The other is the on going development effort.
When a new project is added, it's AssemblyInfo.cs file gets two and only
two changes:
- AssemblyDelaySign(true) and
- the AssemblyKeyFile points to a key file that is shared across the
entire project.
The project post build event has two lines in it
- Sn -Vr "$(TargetPath)"
- and a DOS copy command to put the signed assembly in a common staging
area.
There are interop classes that permit unmanaged code to access the
classes.
The managed code makes use of the classes directly.
The project TestAccount is set as the startup project.
When TestAccount builds, copies of the various assemblies are copied to
its product output directory.
The assemblies are not being added to the GAC.

Typical failure:
- Object a, which is in assembly B, is successfully created through the
use of new B.
- An exception is thrown when a function in a is called.
- The exception says that the located assembly's manifest definition does
not match the assembly reference.

Questions:
Q1) Under what conditions can a mismatched version error manifest?

This is normally a problem when your DLL is compiled. You are referencing
'copy1' of assembly b. You compile the dll and place it in a common folder.
In that common folder is a copy of assembly b... with a different signature.
The most common cause: circular references (a method in assembly b is
referring to an object in assembly a, while a method in assembly a refers to
a class in assembly b. Look for circular references.

Q2) How can we find and fix the reason(s) for the multiple, sporadic
manifest mismatch problems?

First off... why are you placing the dlls into a 'common staging area'?
Check the /bin directory where the dll was compiled... and see if the
manifest for the copy of assembly b in that folder matches the manifest for
the assembly b in your 'common staging area'.

Don't look at version numbers. Since you are using delay signing, look at
the manifest itself.

Also, one good way to kill this problem is to create a solution file that
includes the project files for each of the code bases, and have the project
references make reference to other projects, instead of to a compiled
version of the dll.

Q3) When TestAccount.exe runs, what is the process that executes that lets
it know what assembly versions to look for?

run search.msn on 'probe .net'

Q4) Where are these values stored?

The manifest of an assembly tells the version information for that assembly
and the expected version information for all assemblies that it depends on.
The probe is finding a dll with the right name and the right objects, but
with the wrong manifest (because the dll that it is finding is not the one
that the project file has a reference to when the assembly is compiled.

Q5) What is the search path for the target assemblies?

you should get this data when you look up the 'probe'

Q6) Why does the object creation succeed but the call to the object's
function throw an exception?

Don't know the answer to this. I'm sure others do.

Hope I Helped,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Richard Lewis Haggard]

Thanks Mike. I appreciate your time and responses.

I'm going to respond to your response and then, now that I have a better
idea of what the real problem is, I'll start a new pleading for help.

This is normally a problem when your DLL is compiled. You are referencing
'copy1' of assembly b. You compile the dll and place it in a common
folder. In that common folder is a copy of assembly b... with a different
signature. The most common cause: circular references (a method in
assembly b is referring to an object in assembly a, while a method in
assembly a refers to a class in assembly b. Look for circular references.

I may have mislead you with the statement about a common staging area. While
this is true for each of the assemblies, it is not true for the test
program. When the test program builds it, of course, copies the assemblies
it cares about into its own output area which is left just as God and
Microsoft (not necessarily in that order) intended. Care was taken to ensure
that circular references not exist.

First off... why are you placing the dlls into a 'common staging area'?

Because that's what my client wants to do. The idea is that by putting the
various assemblies into a common staging area, it will make it easier to
construct installation software and to ensure that all dependencies can be
resolved at run time. Again, in the case of the test executable, this is not
part of the problem since building it resulted in the compiler making local
copies of its referenced assemblies.

Check the /bin directory where the dll was compiled... and see if the
manifest for the copy of assembly b in that folder matches the manifest
for the assembly b in your 'common staging area'.

I just found out about ildasm and ran it. The information in the various
copies of the dlls agree with themselves - but do not agree with the IDE.
For example, ildasm says Data.Class is looking for Data.Security with a
version of 1.1.2244.4532. However, the IDE says that Data.Class is
referencing the Data.Security project and wants revision 1.1.0.0. Multiple
manual deletes and forced rebuilds do nothing to get rid of this. I finally
changed the version number of the assembly being built to agree with the
version being looked for and that permitted my test application to run. Not
an acceptable solution, by any means!

This isn't limited to just the one file. I've seen this mismatch happen on
three separate occassions and there are two other developers who use the
same solution and are struggling with the same problem but different DLLs.

Don't look at version numbers. Since you are using delay signing, look at
the manifest itself.

Which I did not know how to do before someone was nice enough to tell me
about ildasm. See above.

Also, one good way to kill this problem is to create a solution file that
includes the project files for each of the code bases, and have the
project references make reference to other projects, instead of to a
compiled version of the dll.

That is what we do. See above about the version the manifest says is being
looked for and what is actually in the target DLLs.

run search.msn on 'probe .net'

Either this is a typo or I am misunderstanding your intentions. That leads
to www.probe.net/~beakers/ and I don't see anything useful here.

The manifest of an assembly tells the version information for that
assembly and the expected version information for all assemblies that it
depends on. The probe is finding a dll with the right name and the right
objects, but with the wrong manifest (because the dll that it is finding
is not the one that the project file has a reference to when the assembly
is compiled.

And idlasm is how to inspect these values. See? 25 years in the software
business and I can still learn new things.

you should get this data when you look up the 'probe'

Then again, maybe not. See my response to Q3.

==
Richard Lewis Haggard

 

[Nick Malik [Microsoft]]

Hi Richard,

Are you, perchance, using VS2003?
Do you have a situation where one of your projects started its live by
copying another one of your projects and then changing the contents of both?

If this is the case, you may have a situation where one solution file has a
reference to two projects but the projects have the same project GUID. It's
not the most likely thing, but its possible. Something to check. This has
an effect on MSI files as well, which is how I found it (see the blog post
below).

http://blogs.msdn.com/nickmalik/archive/2005/06/21/431206.aspx

I don't know if this is happening, but it's easy to look for. HTH,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

Thanks Mike. I appreciate your time and responses.

I'm going to respond to your response and then, now that I have a better
idea of what the real problem is, I'll start a new pleading for help.

This is normally a problem when your DLL is compiled. You are
referencing 'copy1' of assembly b. You compile the dll and place it in a
common folder. In that common folder is a copy of assembly b... with a
different signature. The most common cause: circular references (a method
in assembly b is referring to an object in assembly a, while a method in
assembly a refers to a class in assembly b. Look for circular
references.

I may have mislead you with the statement about a common staging area.
While this is true for each of the assemblies, it is not true for the test
program. When the test program builds it, of course, copies the assemblies
it cares about into its own output area which is left just as God and
Microsoft (not necessarily in that order) intended. Care was taken to
ensure that circular references not exist.

First off... why are you placing the dlls into a 'common staging area'?

Because that's what my client wants to do. The idea is that by putting the
various assemblies into a common staging area, it will make it easier to
construct installation software and to ensure that all dependencies can be
resolved at run time. Again, in the case of the test executable, this is
not part of the problem since building it resulted in the compiler making
local copies of its referenced assemblies.

Check the /bin directory where the dll was compiled... and see if the
manifest for the copy of assembly b in that folder matches the manifest
for the assembly b in your 'common staging area'.

I just found out about ildasm and ran it. The information in the various
copies of the dlls agree with themselves - but do not agree with the IDE.
For example, ildasm says Data.Class is looking for Data.Security with a
version of 1.1.2244.4532. However, the IDE says that Data.Class is
referencing the Data.Security project and wants revision 1.1.0.0. Multiple
manual deletes and forced rebuilds do nothing to get rid of this. I
finally changed the version number of the assembly being built to agree
with the version being looked for and that permitted my test application
to run. Not an acceptable solution, by any means!

This isn't limited to just the one file. I've seen this mismatch happen on
three separate occassions and there are two other developers who use the
same solution and are struggling with the same problem but different DLLs.

Don't look at version numbers. Since you are using delay signing, look
at the manifest itself.

Which I did not know how to do before someone was nice enough to tell me
about ildasm. See above.

Also, one good way to kill this problem is to create a solution file that
includes the project files for each of the code bases, and have the
project references make reference to other projects, instead of to a
compiled version of the dll.

That is what we do. See above about the version the manifest says is being
looked for and what is actually in the target DLLs.

run search.msn on 'probe .net'

Either this is a typo or I am misunderstanding your intentions. That leads
to www.probe.net/~beakers/ and I don't see anything useful here.

The manifest of an assembly tells the version information for that
assembly and the expected version information for all assemblies that it
depends on. The probe is finding a dll with the right name and the right
objects, but with the wrong manifest (because the dll that it is finding
is not the one that the project file has a reference to when the assembly
is compiled.

And idlasm is how to inspect these values. See? 25 years in the software
business and I can still learn new things.

you should get this data when you look up the 'probe'

Then again, maybe not. See my response to Q3.

==
Richard Lewis Haggard