Public Key changes on Rebuild All?

  • Thread starter Thread starter Rory Plaire
  • Start date Start date
R

Rory Plaire

(Oops, posted to the wrong newsgroup. microsoft.public.dotnet.Csharp
readers please forgive...)

Hi there,

Could someone help me over my lack of knowledge here? I am trying to
find out why, when I use the same key pair, and the assembly version is
constant, does the public key change with each Rebuild All in VS 2003?
This sort of behavior will change the assembly strong name which is a
Bad Thing when trying to actually use code beyond the development
environment...

I want the strong name to remain constant, and by all accounts it
should, given the same version number and key pair...

thanks,
-rory 8)
 
Why do you think the public key has changed? There are any number of
reasons why the version number would change but there's nothing in DevStudio
that would automatically generate a new public key an assembly is built
with.
 
Why do you think the public key has changed? There are any number of
reasons why the version number would change but there's nothing in
DevStudio that would automatically generate a new public key an
assembly is built with.
Click to expand...

Hi Dave,

I have the assembly attribute AssemblyKeyName assigned to AssemblyInfo.cs.
When I do a build, the public key token changes (Sorry, I misspoke -- I
meant the token, not the key.) The token should remain constant if I
understand how everything works (which is probably what is deficient here).
How can one specify an assembly strong name if the token keeps changing?

thanks,
-rory 8)
 
Again, what is happening that makes you think the token has changed? I build
with strong names all the time and this simply does not occur.
 
Again, what is happening that makes you think the token has changed? I
build with strong names all the time and this simply does not occur.
Click to expand...

sn -t assembly.dll

It reports a different token on every rebuild.

thanks,
-r 8)
 
According to the documentation of sn...

"Sn.exe computes the token using a hash function from the public key. To
save space, the common language runtime stores public key tokens in the
manifest as part of a reference to another assembly when it records a
dependency to an assembly that has a strong name. The -tp option displays
the public key in addition to the token. "

Since the token is a hash of the strong name, and so long as the strong name
has unchanged (unless you regenerated it), the hash of the strong name
should also remain unchanged.

You should try using the -tp option to verify that the public key itself has
remain unchanged from build-to-build. If the public key has changed then you
or someone with access to the project has regenerated the public-private key
pair and used a new key. There is no magic, so if the token changed the
public key must also have changed. Do you have any steps in your build
process that issues the command "sn.exe -k keypair.snk"?
 
Since the token is a hash of the strong name, and so long as the
strong name has unchanged (unless you regenerated it), the hash of the
strong name should also remain unchanged.
Click to expand...

Right, this is why I am baffled...

You should try using the -tp option to verify that the public key
itself has remain unchanged from build-to-build.
Click to expand...


Great tip. It appears that the public key doesn't change. I am using the
AssemblyKeyName attribute, so I am using a key in a machine store
container, not a key from a file. The AssemblyKeyFile attribute is empty.

So, since the public key doesn't change, the version doesn't change, and
the assembly name doesn't change... why does the token change.

If the public key has
changed then you or someone with access to the project has regenerated
the public-private key pair and used a new key. There is no magic, so
if the token changed the public key must also have changed. Do you
have any steps in your build process that issues the command "sn.exe
-k keypair.snk"?
Click to expand...


Unfortunately, nothing of the sort. Again, I am using a machine key
container, not a file. So, I am certain that it doesn't change, as the
above test confirmed.

continuing thanks,
-rory 8)
 
have you looked at the 4 part assembly display names of the the two versions
of which the tokens are diffrent
(using ILDASM maybe)

Rahul
 
"Rahul Kapoor" <[email protected]> expressed in the message known
far and wide by the name thusly:
have you looked at the 4 part assembly display names of the the two
versions of which the tokens are diffrent
(using ILDASM maybe)

Rahul
Click to expand...

Hi Rahul,

I did do that, yes. Following your suggestion, I did it again, and this
time I noticed that the tokens for the compiled assemblies are the same,
when they are referenced in the manifest, and they are what I expect them
to be...

Oh, I don't believe it. I just reran sn /? and realized (man, it sure
wasn't clear to me the first 10 times I read it), that sn -t thinks it is
getting a public key infile (not), and sn -T thinks it is getting the
assembly (which it is). Heh... that explains why sn -tp assembly.dll
gives me this huge output... 8P

Whew. Mystery solved. Thanks, Rahul, and especially Dave who stuck
through me on this one...

-rory 8)
 
Back
Top