# Tuesday, December 09, 2003

I'm making a web request to a site that uses certificate authentication, and it's the first time I've done that with .NET, so bear with me.  I'm doing something like the following...

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("https://mysite.com");

X509Certificate x509 = X509Certificate.CreateFromCertFile(@"c:\temp\mycert.cer");


That works fine, but it seems like there should be an easier way.  The certificate already exists in my local certificate store, or I'm pretty sure this wouldn't work at all, so why do I have to export the cert to a .cer file in order to use it?  Shouldn't I be able to get a reference to it directly from the certificate store?  Or would that involve too much unmanaged yuckiness?  It just seems like an extra step, and administrative hassle, but maybe that's just the way it is. 

Any suggestions or feedback welcome.


Got it. 

Tuesday, December 09, 2003 8:58:54 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

I've upgraded to the newly released dasBlog 1.5 (it went smoothly as usual).  Kudos to Omar for the new DasBlog theme.  I use firebird, and his new theme looks fabulous. 

If only FreeTextBox worked under firebird, I could die fulfilled. 

Tuesday, December 09, 2003 8:13:09 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, November 19, 2003

The code was all working just fine in test (heh, heh), but in production, suddenly we were getting

exception: System.IO.FileNotFoundException:
File or assembly name ox0vcwlz.dll, or one of its dependencies, was not found.  File name: "ox0vcwlz.dll"
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark) 

Very sad.  Even more interesting was that on each run, the assembly name was different.  OK, probably the XmlSerializer then.  But why did it work in test, and not under other conditions. 

It all became clear when we logged the full exception...  Fusion says:

=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\WINNT\TEMP\ox0vcwlz.dll
LOG: Appbase = D:\Program Files\XXX
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/WINNT/TEMP/ox0vcwlz.dll.

Ah ha!  Turns out the user context we were running under didn't have permissions to the c:\winnt\temp directory.  Ouch.  An easy fix, but not one that was intuitively obvious, at least to me.  I knew that the XmlSerializer created dynamic assemblies, but I didn't know they had to be persisted to disk. 

Something to think about.

Work | XML
Wednesday, November 19, 2003 1:50:00 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [3]  |