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.