This got out of control as I was writing it. If you just want to laugh at how angry I am, read “Summary” to understand the problem and “The right approach” to hear me picking on entry-level developers and making fun of myself.

Summary

In Visual Studio.NET 2005, web projects no longer have a “project file”. Web project settings which used to be stored in the project file (e.g. “Is file in the project folder actually part of the project?”, “What projects’ output assemblies do I reference?”, “Which assemblies on the file system do I reference?”, “Should I copy this referenced assembly to my \bin folder each time I build?”) are now either

• stored in the solution file in a section specific to each web project; or
• not stored anywhere because the feature they support has been yanked.

So, some important features have been yanked, and “web sites” (not “web projects” any more) are treated as the weird red-headed-stepbrother of all the other code-based project types.

The stated motivation for this big change is to avoid having confusing “extra” files (e.g. “.webinfo”) hanging around a web project, but right now it seems like the cure is worse than the disease; the yanked features they supported were useful, and the info relocation is annoying, confusing, and decreases consistency between project types in VS.NET.

Consequences and associated changes

File references

Web projects’ “File references” – i.e. references to a specific assembly on the file system – now must be manually maintained by developers. A file reference is now no more and no less than a copy of the target assembly in the web project’s /bin folder. If the targeted assembly is changed, the web project’s copy remains blissfully obsolete until the developer either re-adds the reference or manually copies the targeted assembly into the /bin folder. Every update to the targeted assembly must be manually propagated to each dependent project by the developer. Just imagine what happens when you forget to update one copy of the assembly when you have a 20 minute build process.

If you reference third party assemblies, this will cause you pain – every web app which refers to the assembly must be individually updated. If your application is split into multiple solutions and involves web projects that reference assemblies from other solutions, this will cause you pain – same again. I believe that MS thinks this pain is acceptable because it forces developers to really manage their dependencies on non-local-solution assemblies. Well, that’s fine, but we were managing our dependencies perfectly well in the previous VS 2003 model, where we had the tools and techniques available to manage them in a sensible way. Taking those tools away at this stage of the platform’s lifecycle (that is, adolescence) is extremely destabilizing for development teams who’ve adopted a working model with no issues.

One fix for this issue would be to set up a Pre-Build event in the web project to copy the required assemblies into the bin folder before the build begins. Unfortunately, Whidbey doesn’t make pre-build events available for web projects. I believe this is probably because the notion of a rigid build process for web sites has been abandoned to support the more flexible compilation models; would pre- and post-build events be fired when an ASPX file is modified, causing a recompilation in ASP.NET, for example?

MS suggests a workaround that allows web project WP to have an automatically maintained file reference to assembly A. (i.e. WP --> A). The approach is to introduce an intermediary class library project CP with a file reference (which works in the old VS 2003 way) to assembly A, and have WP reference CP. (i.e. WP --> Otherwise-completely-unnecessary-Class Library Project-there-only-to-irritate-ASP.NET-developers --> A). If I was a J2EE developer, I’d laugh at that approach.

I don’t think this change is a necessary consequence of the change to remove “web project” files – intra-solution references to other projects’ outputs are still allowed, and the information about these references is stored in the solution file (which is a hack; see below). As I say above, I believe it’s more likely to be a way to discourage non-project-style-references in the interests of avoiding dll-hell situations for developers. I think they’ve adopted exactly the right solution for a world where everyone’s code is recompiled at the same time, as part of a single project, and shipped and deployed exactly once. That’s why I think they’ve adopted exactly the wrong solution.

The solution file is even more ugly than it used to be

I never understood why MS chose a non-XML format for the VS.NET solution file, given that they chose XML for the project file formats. Leaving that aside, now that the web project-level information (much of which still must be stored to support the web project features MS hasn’t pulled) has been relocated into the solution file, it’s even more cruft-filled and difficult-to-comprehend when something goes wrong. We’ve gone from a situation where reference information was stored in a comprehensible, self-documenting format inside a fairly logically-structured XML file located with the code it relates to, to a non-standard, line-oriented, order-sensitive text document whose structure is pretty tough to decipher and whose location will often bear absolutely no relation to the web site whose code it describes.

Complexity

As a result of this change, web projects are now even more different from every other project type in Visual Studio.NET. As an illustration, witness that they’re no longer even called “projects” – you work with “web sites”, not “projects”. As a result there is more - not less - for a .NET developer to understand when they come to work on web projects; this is exactly the opposite of the stated goal of the change: to keep web development as simple as possible. It’s weird that MS would be emphasising the differences between project types rather than moving to unify – eg. File | Add New Project can no longer be used to create a web project because there is no such thing.

The right approach

Make it as simple as possible, but no simpler. Retain the web project file; any developer who could not understand its purpose or presence is going to struggle to work the public transport system to arrive at work in the mornings. If you’re concerned about extraneous files appearing in the actual web folder hosted by IIS or Cassini, then fine, introduce an intermediate folder containing project inputs (project files, source code files, resxs, etc.) and support producing your project outputs in a completely separate folder. The “output” folder then only contains the files required to deploy the web project; no confusion at deployment-time.

Most importantly: don’t pander to the whims and misconceptions of entry-level developers if you want to allow enterprise-level development using your tools; pander to my whims and misconceptions instead.

Quotes/References

"Thank you for submitting this issue. In VS05, web applications (aka web projects) no longer have a project file. This was based on feedback that web developers wanted to minimize the "special" files required by VS03. A side effect of this is we do not have a way to store solution-to-solution assembly references (i.e. inter-solution) like you describe. We will reconsider this design in our next release. In the meantime, we suggest you use intra-solution assembly references (i.e. references within the same solution)." – Some guy from MS

“That’s hilarious!” – Andrew Chalmers

More on the workaround: “As noted, VS05 supports project to project references in a solution, but not sol1/project to sol2/project (inter-solution) references. As a workaround, you could setup a client project as an intermediary to reference the other solution's project, i.e. sol1/webproject references sol1/clientproject which in turn references sol2/clientproject. Its cumbersome, but will work.” – Mike from MS

“Are you fscking serious?” – Andrew Chalmers

More on the workaround: “To summarize, VS03 allowed assembly references to work between two solutions if you set the CopyLocal flag. VS05 allows assembly references between two projects in a solution, but not between two solutions. To work around, you will need to manually copy the assembly the web app depends on into the web app's bin folder.” – MS people who analyse the many bugs submitted by people who dislike the new approach.

Some guy complaining last week Some MSDN Bug summaries relating to the issue: 1 2 3 4