The Inner Workings of *.vbproj Files: <ProjectTypeGuids>

During the conversion of the S#arp Architecture template project from C# to VB.Net I inadvertently broke (at least) one thing: the ability to add ASP.Net MVC items directly to the SharpArch.Web project directly from the “Add New Items…” dialog. This led to my first question asked on StackOverflow.com (which I ended up answering myself, 38 minutes later).

Turns out Visual Studio project files can have an element called <ProjectTypeGuids> which contains one or more guids identifying what type of project the file describes. ASP.Net MVC projects have a particular guid specified: {603c0e0b-db56-11dc-be95-000d561079b0}.

So I added this guid to both my SharpArch.Web project file and my SharpArch.Controllers project file, and now I can add new MVC template items directly from the “Add New Item…” dialog. Cool!

S#arp Architecture

I’ve been poking around in the latest release of the S#arp Architecture over the last couple days. I like what I see.

Pronounced “Sharp Architecture,” this is a solid architectural foundation for rapidly building maintainable web applications leveraging the ASP.NET MVC framework with NHibernate.

This evening I took about an hour and converted the basic starter solution template from C# to VB.Net. Why? Well, for the following reasons:

  1. While I can work with C# well enough, I’m much more familiar with VB.Net, which I am required to use at my 9 to 5 job. I tend to stick with VB.Net even for my personal projects for simplicity. Anything I learn on my own I can easily apply at work.
  2. It gave me an opportunity to confirm that I understand (at least at a high level) what the S#arp Architecture is doing.

The conversion was straight forward. Pretty well every line of C# had a corresponding line in VB.Net. The only thing I had to add was an Imports tag in the markup of the Site.Master page in order to get the ActionLink and Image extension methods to resolve. I had already tried adding an imports to the code-behind with no luck. Not sure why that was necessary, but it worked.

The architecture is pretty neat. Here’s a few things I’ve noted already:

  • The Models, Views and Controllers (I.e. the M, V and C in MVC) are each in their own projects.
  • The Repository/IRepository pattern is used, with the Interfaces defined in the same project as the Models, and the Repository implementation(s) in a separate project.
  • Includes support for NUnit, Castle Windsor, (Fluent) NHibernate, and Rhino Mocks
  • The ASP.Net MVC routes are defined in the Controllers project, not in the Global.asax of the Web/Views project. Excellent separation of concerns!

I’m going to go ahead and trying putting together an actual application based on S#arp Architecture.

Securing Web Services with SSL Client Certificates

I am posting this in the hopes that other poor souls writing .Net web service proxies to consume web services that require SSL client certificate authentication won’t waste days trying to figure out why their code isn’t working like every single related article on the web says it should.

According to just about every bit of information I could find on the web about using SSL client certificates with web service proxies, the following code should work:

Dim objCertificate As X509Certificate = X509Certificate.CreateFromCertFile(“C:\MyClientCert.cer”)
proxy.ClientCertificates.Add(objCertificate)

But that didn’t work for me, at least not out-of-the-box.

A bit more Googling uncovered this blog post by Kevin Hammond. The important points in his post were:

First, the certificate with the private key must be imported into your personal store.

When you import your certificate into the certificate store, you are presented with the option to “Enable strong private key protection. … Unfortuantely, enabling this option causes the .NET Framework to silently fail when accessing the private key of your certificate.

While this did not solve my problem (I had already done both of these things), it lead me to learn a bit more about this “personal store”. Among the things I learned is that there is a utility called WinHttpCertCfg.exe that can be used to manage the permissions of the certificate stores on your computer. Since my web service proxy was being called from an ASP.Net web page, the ASPNET user had to be given access to the certificate store containing the SSL client certificate.

But my SSL client certificate authentication was still not working. It had taken me the better part of a day to get to this point. What ended up taking me nearly three days to figure out was that there are a number of was to import SSL certificates into a certificate store. But only one way would work for my web service proxy. The break-through came from Matthew.DelVecchio who wrote in this news group post:

… added the Certifcates snap-in for the MMC windows management utility, and using it to delete my certs, re-add the .PFX into the “Personal” store, then exporting it to a .CER all w/ the MMC snap-in (and not using Control Panels -> Internet Settings or IE).

Hope this information helps someone out there save some time (and a little bit of sanity)!