Colin Bowern

... more of the usual bool

  Home  |   Contact  |   Syndication    |   Login
  23 Posts | 0 Stories | 16 Comments | 24 Trackbacks

News

Archives

Post Categories

Saturday, January 21, 2006 #

Development machines here use a delayed signing for building binaries. Only during the build process on the build server does a public/private key pair get used for signing assemblies. When using the unit testing features of Visual Studio 2005 we are prompted to provide a key for re-signing an assembly after instrumentation has been applied. If we provide the public key it will fail. If we provide the public/private key pair it will work. 

Has anyone else managed to get this working?  Here's what I'm trying to do:

1. Create a public/private key pair and extract the public key:
sn -k Private.snk
sn -p Private.snk Public.snk
2. Create a class library project and specify it should delay sign using Public.snk
3. Create a test project and enable Code Coverage.
4. Check the "instrument assemblies in place" option and provide a path to the Public.snk
5. Attempt a test run.

-or-

From the command prompt:

sn -R bin\Debug\MyAssembly.dll Public.snk

In turn you'll get the following when using IDE for code coverage:

Instrumentation warning: Cannot extract the public key from the key file 'C:\Projects\Common\Common\Public.snk': Bad Version of provider. (Exception from HRESULT: 0x80090007)
Check that the key file is not password protected. Password protected key files are not supported. (It's not password protected!)
Code coverage instrumentation warning while processing file Common.dll:
Warning VSP2001 : C:\Projects\MyAssembly\MyAssembly\bin\Debug\MyAssembly.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.


When using command prompt:

Failed to extract public key from key pair -- Bad Version of provider.

Ah well.  Filed as a bug and will hopefully be fixed.  So much for the joys of delay signing.

MSDN Product Feedback Center: Bug Details


I really liked the original exception management block put out by Microsoft.  The reason is because it included all the information relating to an exception - not just the Message property.  It made production debugging a breeze.  Now with ASP.NET 2.0 and Health Monitoring something similar has been created but it doesn't quite cover all the details.  I first ran into this in an application where I had created a custom exception, ArgumentFormatException, and passed along two additional properties.  After puttering through the underpinnings of the Health Monitoring feature I noticed that the exception information is captured using the Message property of the Exception by the EventLogWebProvider class.  In order to beef up the data returned by my exception I put in a Message property which overrides the base version:

  127         public override string Message

  128         {

  129             get

  130             {

  131                 StringBuilder messageText = new StringBuilder(base.Message);

  132 

  133                 if ((this.m_ExpectedFormat != null) && (this.m_ExpectedFormat.Length != 0))

  134                 {

  135                     messageText.Append(Environment.NewLine);

  136                     messageText.AppendFormat(CultureInfo.CurrentCulture, StringResources.ParameterExpectedFormat, m_ExpectedFormat);

  137                 }

  138 

  139                 if ((this.m_ActualValue != null) && (this.m_ActualValue.Length != 0))

  140                 {

  141                     messageText.Append(Environment.NewLine);

  142                     messageText.AppendFormat(CultureInfo.CurrentCulture, StringResources.ParameterActualValue, m_ActualValue);

  143                 }

  144 

  145                 return messageText.ToString();

  146             }

  147         }

After re-running the tests voila I now have more detailed exceptions.

Exception information:

Exception type: ArgumentFormatException

Exception message: The variable does not match the expected format.

Parameter name: emailAddress

Expected Format: ^([a-zA-Z0-9_\-\.']+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$

Actual Value: xxxx