VS.NET and the Microsoft Way…

I’ve been struggling with a “best practice” around setting up larger scale projects with .NET

The Web Project wizard in Visual Studio .NET is convenient for creating quick ASP.NET applications on your local machine, but in an effort to simplify your life, it also makes many decisions for you that are difficult to change if you need more flexibility. If you don’t create the virtual directory first then the wizard will automagically create on for you, based on the root of your web server (which is normally C:InetPubwwwroot). My biggest pet peeve with Web Projects is that you cannot even open a .sln file if the virtual directory mapping in IIS is not set up correctly. This becomes a problem with you have multiple users all trying to open the projects you’ve created.

One fix is to not share solution files, but when it comes to the ASP.NET applications, you always have to have the virtual directory setup first before you can open a web project. It’s all very frustrating and I still can’t find a good middle-ground between what you can do without shooting yourself in the head and having a well structured project directory layout. Microsoft has an article where they basically tell you to setup your physical directory first, then point a virtual to it, then create the ASP.NET project. I find this is the fasted way to open up a project as well, because VS.NET isn’t churning in the background creating the virtual directories.

There are some other tricks with folder structure because you can easily create a localized breadcrumb navigation trail with ASP.NET (there are several components out there) which is based on the directory structure. With UrlRewriting, you can direct the user all over the place and not worry about moving things internally. I think this is one the big downfalls with HTML and the Web. You move a link and your entire system falls apart. Some content managment systems (like Microsoft’s own CMS) fix this by storing everything in a SQL database and referring to the files through GUID like URLs, but a) it starts to look like Lotus Notes after awhile (if you’ve ever saw those Urls, they’re god awful ugly and long) and b) it still doesn’t really protect you and moving or changing something sometimes breaks things. There’s still some work there before that problem gets solved.

I think (and correct me if I’m wrong here) it should start with a Web project. The sequence that seems to have worked for me is this:

1. Create a physical directory (I refuse to call them folders) on the hard drive to hold the project

2. Create a web subfolder in this directory. This is where your web app will live.

3. Create a virtual directory to point to the directory you created in step #2 with your app name

3. Create a new Web application in VS.NET with that name. VS.NET will automatically save all your files to the physical directory you created in step 2

4. Create new class library projects and add them to the solution (for unit testing, data access, business functions, etc.) and put them somewhere in the structure (maybe a test or src folder off the root)

One trick I picked up this week (thanks to the guys at ThoughtWorks and some cool guys at CP) is to create one class library project called Core for all your system functions. Inside this project, create a folder called DAL, DTO, Domain, etc. to hold the classes for such. This way you can import one namespace into your tests and it makes it easy to reference everything else. Of course if you have to physically split some of the pieces (like the data access layer from your domain) this might be a problem. I’ve always put my DAL and Domain into separate projects. Not sure if that will be a problem with this setup but it does make things easier in the end.

I don’t think there’s any one real solution or “right” way to do things here. A rule of thumb might be to group logical sub-sections of your application in their own directories. If you ever have more than 10-15 files in one directory, maybe it’s a sign you need to improve your directory structure.

In the end, there is also motivation to have all directory structures the same on all developer machines, as well as having the same structure mirrored on an integration server (like one running your web server or Continuous Integration one). Makes for a simple migration from one environment to the next. Don’t even get me started on the whole namespace heiarchy…