Re: Verifying Signed Files Downloaded via HTTP
From: Nicole Calinoiu (calinoiu)
Date: 06/27/05
- Next message: catweezle2010: "Re: asp.net client idenification"
- Previous message: Nicole Calinoiu: "Re: asp.net client idenification"
- In reply to: DaveW: "Verifying Signed Files Downloaded via HTTP"
- Next in thread: DaveW: "Re: Verifying Signed Files Downloaded via HTTP"
- Reply: DaveW: "Re: Verifying Signed Files Downloaded via HTTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 27 Jun 2005 08:39:18 -0400
"DaveW" <david_wender@yahoo.com> wrote in message
news:1119638456.924177.55680@g47g2000cwa.googlegroups.com...
>I have created a Launcher Application to automatically update files for
> my main application before the main application starts. The launcher
> checks a XML file on a server to see a list of files/versions that are
> associated with the main application and will automatically download
> new versions.
> All DLLs and EXEs are strong named and signed with a Authenticode Code
> signing certificate.
> It seems that some clients are now encountering Strong Name exceptions
> after downloading new versions.
What is the exact exception type and message? (The full output of the
exception's ToString method would be best, if you can provide it.)
> I am trying to figure out whether they are getting these exceptions
> because the downloaded file was somehow corrupted during the file
> transfer. If so, is there any way to verify that a file has a valid
> signature after it is downloaded so that I can attempt to re-download
> if there are problems?
Attempt to load the assembly using Assembly.Load, Assembly.LoadFrom, or
Assembly.LoadFile. If the file is corrupt, simply loading the assembly in
this way will cause an exception to be thrown even before any attempt is
made to call code within the assembly.
> Another thing to note is that I renewed my Digital Certificate on
> 6/6/05 but I have not rebuilt the SNK with new new certificate.
There's no need. The two signing mechanisms are completely independent of
one another.
> I don't
> know much about how these certificates work, but I'm wondering if there
> is some sort of random verification going on that is failing because
> the old certificate may be expired.
It would be rather surprising to see exceptions related to the strong name
being thrown because of any problem with the authenticode signature. A
couple of more likely causes might be the following:
1. The assemblies are delay-signed rather than fully signed.
2. An unexpected/incorrect version of a dependant assembly is being used by
the client.
>
> Any help would be greatly appreciated.
>
> Thanks.
>
- Next message: catweezle2010: "Re: asp.net client idenification"
- Previous message: Nicole Calinoiu: "Re: asp.net client idenification"
- In reply to: DaveW: "Verifying Signed Files Downloaded via HTTP"
- Next in thread: DaveW: "Re: Verifying Signed Files Downloaded via HTTP"
- Reply: DaveW: "Re: Verifying Signed Files Downloaded via HTTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|