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/arch...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.
--
"Richard Lewis Haggard" <HaggardAtWorldDotStdDotCom> wrote in message
news:uXGxVPIOGHA.3576@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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.
>[color=green][color=darkred]
>>> Questions:
>>> Q1) Under what conditions can a mismatched version error manifest?[/color]
>>
>> 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.[/color]
>
> 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.
>[color=green][color=darkred]
>>> Q2) How can we find and fix the reason(s) for the multiple, sporadic
>>> manifest mismatch problems?[/color]
>>
>> First off... why are you placing the dlls into a 'common staging area'?[/color]
> 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.
>[color=green]
>> 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'.[/color]
>
> 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.
>[color=green]
>> Don't look at version numbers. Since you are using delay signing, look
>> at the manifest itself.[/color]
> Which I did not know how to do before someone was nice enough to tell me
> about ildasm. See above.
>[color=green]
>> 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.[/color]
> 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.
>[color=green][color=darkred]
>>> Q3) When TestAccount.exe runs, what is the process that executes that
>>> lets it know what assembly versions to look for?[/color]
>>
>> run search.msn on 'probe .net'[/color]
> 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.
>[color=green][color=darkred]
>>> Q4) Where are these values stored?[/color]
>>
>> 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.[/color]
> And idlasm is how to inspect these values. See? 25 years in the software
> business and I can still learn new things.
>[color=green][color=darkred]
>>> Q5) What is the search path for the target assemblies?[/color]
>>
>> you should get this data when you look up the 'probe'[/color]
> Then again, maybe not. See my response to Q3.
>
> ==
> Richard Lewis Haggard
>
> "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
> news:85OdneCbR697HWDeRVn-sw@comcast.com...[color=green]
>> "Richard Lewis Haggard" <HaggardAtWorldDotStdDotCom> wrote in message
>> news:OOcclp%23NGHA.1832@TK2MSFTNGP11.phx.gbl...[color=darkred]
>>> 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?[/color]
>>
>> 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.
>>
>>[color=darkred]
>>> Q2) How can we find and fix the reason(s) for the multiple, sporadic
>>> manifest mismatch problems?[/color]
>>
>> 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.
>>
>>[color=darkred]
>>> Q3) When TestAccount.exe runs, what is the process that executes that
>>> lets it know what assembly versions to look for?[/color]
>>
>> run search.msn on 'probe .net'
>>[color=darkred]
>>> Q4) Where are these values stored?[/color]
>>
>> 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.
>>[color=darkred]
>>> Q5) What is the search path for the target assemblies?[/color]
>>
>> you should get this data when you look up the 'probe'
>>[color=darkred]
>>> Q6) Why does the object creation succeed but the call to the object's
>>> function throw an exception?[/color]
>>
>> 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.
>> --
>>
>>[/color]
>
>[/color]
