469,964 Members | 1,729 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,964 developers. It's quick & easy.

Reference confusion - manifest has multiple references to multiple versions of assembly

I'm having a problem with what appears to be some sort of confusion with
references. I have a single solution with a dozen projects which has been
working quite nicely for a while. The references between projects in the
solution were established through project references, not by browsing to an
assembly DLL. All of the projects are strongly named and use key files. Each
project's AssemblyInfo.cs specifies the assembly version, where the assembly
key file is and sets AssemblyDelaySign(true).

Here's where the problem started. There was an administrative decision made
to change the name of the assemblies, change the name spaces and to generate
new key files. Now things have stopped working for what appear to be some
confusion over the version of assemblies being consumed.

One symptom: There is only one version of an assembly, but if I look into
the manifest of a consumer of that assembly, I see two different references
to that assembly using two different public keys and slightly different
names.
The first one is ".assembly extern BCGI.CTSxCore"
The second is ".assembly extern BCGI.CTSxCore as BCGI.CTSxCore_6".

I don't know where the confusion is coming from and would greatly appreciate
it if someone could point me at a couple of likely reasons why this
confusion is being generated.

Another symptom: At build time, there are two different error lines that
say, in essence, that a dependency couldn't be copied to the run directory
because it would conflict with another dependency of the same name but a
different key token value.
--
Richard Lewis Haggard
www.Haggard-And-Associates.com
Apr 11 '06 #1
1 2961
I did not figure out why this happened, but it was fixed by deleting all of
the references and then re-establishing them. After that, the manifest for
each assembly cleared up and the duplicate references were gone.

Still - what happened? Why did changing the key files result in duplicate
(sort of) assembly references? This sort of implies that a reference is a
static entity that, once established, doesn't update or change in any
fashion automatically. Is that true?
--
Richard Lewis Haggard
www.Haggard-And-Associates.com

"Richard Lewis Haggard" <HaggardAtWorldDotStdDotCom> wrote in message
news:uy**************@TK2MSFTNGP05.phx.gbl...
I'm having a problem with what appears to be some sort of confusion with
references. I have a single solution with a dozen projects which has been
working quite nicely for a while. The references between projects in the
solution were established through project references, not by browsing to
an assembly DLL. All of the projects are strongly named and use key files.
Each project's AssemblyInfo.cs specifies the assembly version, where the
assembly key file is and sets AssemblyDelaySign(true).

Here's where the problem started. There was an administrative decision
made to change the name of the assemblies, change the name spaces and to
generate new key files. Now things have stopped working for what appear to
be some confusion over the version of assemblies being consumed.

One symptom: There is only one version of an assembly, but if I look into
the manifest of a consumer of that assembly, I see two different
references to that assembly using two different public keys and slightly
different names.
The first one is ".assembly extern BCGI.CTSxCore"
The second is ".assembly extern BCGI.CTSxCore as BCGI.CTSxCore_6".

I don't know where the confusion is coming from and would greatly
appreciate it if someone could point me at a couple of likely reasons why
this confusion is being generated.

Another symptom: At build time, there are two different error lines that
say, in essence, that a dependency couldn't be copied to the run directory
because it would conflict with another dependency of the same name but a
different key token value.
--
Richard Lewis Haggard
www.Haggard-And-Associates.com

Apr 11 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Santhu | last post: by
16 posts views Thread by Kent | last post: by
68 posts views Thread by Jim Langston | last post: by
275 posts views Thread by Astley Le Jasper | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.