relax! it’s just 0s and 1s

working with .NET 3.5, ADO.NET Entity Framework and VS 2008, there are a couple of bizarre (also annoying) actions, you can see.

1. an App.config/Web.config file is automatically closed by the VS 2008, when you Save the file.
2. if multiple config files are open, only the first one is closed.

this doesn’t happen to all XML files. only parent application configuration files. it does not seem to affect the child config files. (linked files which have their own section, which do not have a root <configuration> section)

so initially I thought, the closing action seems to be related to a configuration file which has this:

<?xml version=”1.0″ encoding=”utf-8″?>

<configuration> — blah — </configuration>

but that is also not totally true, because the App.config if renamed, does not close on Save.

so it has got something to do with the file name too.

it seems many of the developers have hit this annoying issue, and the problem seems to be the ADO.NET Entity Framework.

in order to verify this, I performed the following steps:

1. I checked the ADO.NET entity tools installed on my box, and found the following:
   • ADO.NET Entity Framework 1.0 (Pre-release Version Beta 3)
   • ADO.NET Entity Framework Tools Preview ( #1.a is a pre-requisite for this)
2. I uninstalled ADO.NET Entity Framework Tools Preview, and checked the app.config/web.config behavior. spot on.. the file did not close. this is the culprit.
3. to verify further, I uninstalled ADO.NET Entity Framework 1.0 and checked. the file did not close on SAVE.
4. then I installed ADO.NET Entity Framework 1.0, and tried saving the config file. it did not close.
5. I installed ADO.NET Entity Framework Tools Preview, and tried saving the config file. it closed.

ADO.NET Entity Framework Tools Preview, is the one, messing up with the configuration file save action.

Notes:

1. During its installation, ADO.NET Entity Framework Tools Preview, prompts for VS 2008 to be closed, if it is open. goes on to show that, it installs some related packages/plug-ins which have the side effect.
2. to resolve this issue, I renamed my app.config file, to <Assembly>.EXE.Config and worked with it.
3. for applications where renaming did not make sense, I just use an external editor. I got tired of editing a small value, saving it (close) in VS 2008 IDE, and finding it and opening it again.
4. ADO.NET Entity Framework 1.0 (Pre-release Version Beta 3) can be downloaded here.
5. ADO.NET Entity Framework Tools Preview can be downloaded here.
6. this bug has been logged with the ADO.NET Entity Framework team.

there’s a solution to every problem; given enough time and money..

as part of some WSE implementation, I had a small utility to read the details of a X509 Certificate. especially the SKID (Subject Key Identifier), of the certificate. actually, WSE comes with a certificate reader tool, which reads the SKID of the certificate.

however, i had 2 issues, using this tool:

• i needed to read the properties from a file, which was the  X509 certificate, instead of reading it from the certificate stores.
• i also needed a string representation of the certificate to be stored in the database. (i like the idea of a database oriented certificate management)

In order to read the X509Certificate properties, there are 2 namespaces available.

using Microsoft.Web.Services2.Security.X509;
using System.Security.Cryptography.X509Certificates;

 however, of the 2 namespaces,  the Microsoft.Web.Services2.Security.X509 seems to give the Subject Key Identifier of the certificate. it makes all the more sense to use this namespace, when you are working with WSE enabled web services.

the code snippet to read the certificate properties: (certificate is assumed to be in a file location)

using (FileStream stream = new FileStream(certificateFilePath, FileMode.Open))
{
    byte[] blob = new byte[(int)stream.Length];
    stream.Read(blob, 0, (int)stream.Length);
 
    using (X509Certificate cert = new X509Certificate(blob))
    {
        this.textBoxBlob.Text = Convert.ToBase64String(blob);
        this.textBoxSubject.Text = cert.Subject;
        this.textBoxTokenIssuer.Text = cert.Issuer;
        this.textBoxSKID.Text = Convert.ToBase64String(cert.GetKeyIdentifier());
        this.textBoxExpiry.Text = cert.GetExpirationDateString();
    }
}

Notes:

• You can get the WSE DLL from here.
• the X509Certificate belongs to the Microsoft.Web.Services2.Security.X509 namespace.
• Convert.ToBase64String(blob) is very useful if you want to store the certificate in a database field. it is one of the ways to eliminate certificate management, for your application.
• The Subject Key Identifier is what uniquely identifies your certificate. when WSE is used in a declarative manner, typically the SKID, Subject and Token Issuer are used in the configuration files.

 there’s a solution to every problem; given enough time and money..