Strong Naming using AssemblyDelaySign(true) and VSS

  • Thread starter Thread starter Shiro
  • Start date Start date
S

Shiro

Hi

I am having a problem using VSS (Visual SourceSafe) to store delayed
signed assemblies - they are being 'broken' and are needing to be
resigned.

I have found that signing assemblies using AssemblyDelaySign(false)
works fine - in that I can check the resulting assembly into VSS delete
the original from the file system and when I get it back out of VSS it
still works (i.e. is still correctly signed).

I have however found that signing assemblies using
AssemblyDelaySign(true) does not like being checked in/out of VSS. The
signing operation itself works fine but if the resulting assembly is
checking into VSS and the original is deleted, when got back out of VSS
it is broken and needs resigning.

The only obvious difference between the original and the one out of VSS
that springs to mind is when got from VSS it has a new date/time. I do
not want to set VSS to use original DateTime as that brings with it
many other issues, such as failure to get latest is the person's clock
who checks something in is late.

Can anyone tell me how I can late sign yet still use VSS to store the
resulting assemblies?

Thanks

Stuart Wells
 
I have however found that signing assemblies using
AssemblyDelaySign(true) does not like being checked in/out of VSS. The
signing operation itself works fine but if the resulting assembly is
checking into VSS and the original is deleted, when got back out of VSS
it is broken and needs resigning.
Click to expand...

What do you mean by "it is broken"? Are you seeing any exceptions? If so,
could you please provide the exception type and message?

The only obvious difference between the original and the one out of VSS
that springs to mind is when got from VSS it has a new date/time. I do
not want to set VSS to use original DateTime as that brings with it
many other issues, such as failure to get latest is the person's clock
who checks something in is late.
Click to expand...

The timestamp should be completely irrelevant. Might the problem simply be
that you're attempting to use the delay signed assembly on a machine that
does not have a skip verification entry (as created using sn.exe -Vr) for
the incomplete signature?
 
When I say broken, I mean it doesn't think is has been signed - the
usual string name exception:

System.IO.FileLoadException: Strong name validation failed for assembly
'blablabla'.
File name: "blablabla"

I hope you are right about the timestamp - I only mentioned the
timestamp because that is the only difference I can see between the one
I check in and the one I check out.

I use the -Vr when I am coding against not-yet-signed assemblies but
once I am finished and I build the product I check into VSS the
resulting exe/dlls and others can then get them from VSS to use.

What I am observing is that if I have A.exe and B.dll and for arguments
sake B.dll is delay signed, I sign B.dll and then check into VSS A.exe
and B.dll. Someone else then gets from VSS these two assemblies and
they cannot run A.exe because it complains B.dll has failed strong name
verification. If I had not put them in VSS but instead on a file server
(say) and they took a copy instead they can run them.

Therefore, by observation checking into VSS appears to 'break' the
string name for delay signed assemblies.

Does that help explain it any better?

Stuart
 
Shiro said:
When I say broken, I mean it doesn't think is has been signed - the
usual string name exception:

System.IO.FileLoadException: Strong name validation failed for assembly
'blablabla'.
File name: "blablabla"
Click to expand...

This is exactly what's expected when a verification skip entry is not
present on the machine. The verification skip entry (created using sn -Vr)
is what tells the CLR to allow the delay signed assembly to be loaded even
though its strong name signature is incomplete.

I hope you are right about the timestamp - I only mentioned the
timestamp because that is the only difference I can see between the one
I check in and the one I check out.
Click to expand...

The file attributes are irrelevant in strong name verification. Only the
file contents are assessed.

I use the -Vr when I am coding against not-yet-signed assemblies but
once I am finished and I build the product I check into VSS the
resulting exe/dlls and others can then get them from VSS to use.
Click to expand...

If the assemblies that these other folks check out of VSS are delay signed,
they will need to run sn -Vr on their machines in order to add appropriate
verification skip entries.


What I am observing is that if I have A.exe and B.dll and for arguments
sake B.dll is delay signed, I sign B.dll
Click to expand...

Is B.dll still delay signed when you check it in, or have you run sn -R[c]
to apply the full signature?

and then check into VSS A.exe
and B.dll. Someone else then gets from VSS these two assemblies and
they cannot run A.exe because it complains B.dll has failed strong name
verification. If I had not put them in VSS but instead on a file server
(say) and they took a copy instead they can run them.
Click to expand...

Sounds like you might be putting a fully signed (using sn -R[c]) copy on the
file server but checking in an file that has not yet had a signature applied
after its initial compilation as a delay-signed assembly.
 
I compile B.dll and runa batch file that effectively signs it. The
batch files looks like this:

sn -Vx
sn -Rc blablabla.dll MyContainer
sn -v blablabla.dll
sn -Vl

Now if I put this signed assembly in a mergemodule and deploy, or on a
file server it works fine, but if I check it into VSS and then someone
gets it out then it doesn't.

I can categorically say it is definitely the same assembly and not the
wrong one or a different one.

All I can suggest if you believe I am making a fundamental mistake is
to knock up a dummp app like the above, delay sign them, check then
into VSS then, having deleted the originals try getting them out of VSS
again and running them.

We have had this problem for over 2 years now and have to continually
work around the issue...and despite looking for answers from time to
time noone seems to be able to categorically say what it is I must be
doing wrong - as I can only assume I am doing something wrong and that
VSS isn't reall breaking the strong name... :-o else I would have
thought I'd have found many more posts about this.

Stuart

Stuart
 
All I can suggest if you believe I am making a fundamental mistake is
to knock up a dummp app like the above, delay sign them, check then
into VSS then, having deleted the originals try getting them out of VSS
again and running them.
Click to expand...

I tried that before responding to your first post and had no problems
whatsoever. Unless different patching levels of VSS are responsible for the
different behaviour, my guess would still be that you are not checking in a
signed version of the file (or that other folks are checking out an unsigned
copy from some other location in the source tree).

We have had this problem for over 2 years now and have to continually
work around the issue...and despite looking for answers from time to
time noone seems to be able to categorically say what it is I must be
doing wrong - as I can only assume I am doing something wrong and that
VSS isn't reall breaking the strong name... :-o else I would have
thought I'd have found many more posts about this.
Click to expand...

If you use VSS or windiff to compare pre- and post-VSS check-in/out copies
(using a post-VSS copy that causes the loading problem) of the DLL, is there
any difference at all?
 
Hi

The good news is I FINALLY found the solution - but you ain't gonna
believe what the problem was!

The problem was indeed causes by VSS in as much as it wasn't checking
in the signed file!

To replicate try this:

Create a delay signed assembly (as above A.exe and B.dll) such that
A.exe throws the error if you don't sign B.dll.

Then Check it into VSS (unsigned).

Then check them out and sign them.

If you ask VSS for the differences it acknowledges the binary files are
different, so check them back in again.

Run A.exe and all is well.

Delete A.exe and B.dll and get them from VSS again.

Run A.exe and it fails.

Why - because if you look at the History it never check in the signed
ones! Whilst it acknowledges they are different, it seems to consider
them the same during the actual check-in.

Frusrated - you bet, but at least I know understand the problem and
feel better about the delay sign/obfuscation itself.

Thanks for all your help - it made me re-examine all the assumtions I
had already made.

Stuart
 
It looks like the VSS checksum algorithm doesn't account for the trickery
inherent in the delay signing mechanism. One workaround would be to force
VSS to compare file contents rather than checksums at check-in. To do this,
change the "compare files by" setting on the "local files" tab of the VSS
options dialog.

HTH,
Nicole
 
Hi

Good idea - I never knew I could do that - but then I had never needed
to know before now.

I am just pleased I now understand the problem and I know the solution.

Thanks again.

Stuart
 
Back
Top