Strong Naming using AssemblyDelaySign(true) and VSS

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

Nicole
Mon Jun 27 09:15:14 CDT 2005

"Shiro" <stuart.wells@focus-solutions.co.uk> wrote in message
news:1119625552.599615.322230@g49g2000cwa.googlegroups.com...
<snip>
> 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.

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.

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?


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

Shiro
Mon Jun 27 09:36:15 CDT 2005

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

Nicole
Mon Jun 27 10:00:04 CDT 2005

"Shiro" <stuart.wells@focus-solutions.co.uk> wrote in message
news:1119882975.832413.218640@f14g2000cwb.googlegroups.com...
> 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"

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.

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.

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

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.

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.


> 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
Mon Jun 27 10:37:51 CDT 2005

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

Nicole
Mon Jun 27 11:30:51 CDT 2005

"Shiro" <stuart.wells@focus-solutions.co.uk> wrote in message
news:1119886671.031752.276780@z14g2000cwz.googlegroups.com...
<snip>
> 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.

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.

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?

Shiro
Tue Jun 28 09:58:24 CDT 2005

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

Nicole
Wed Jun 29 10:55:58 CDT 2005

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


"Shiro" <stuart.wells@focus-solutions.co.uk> wrote in message
news:1119970703.985183.308390@g44g2000cwa.googlegroups.com...
> 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
>

Shiro
Thu Jun 30 02:40:57 CDT 2005

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