Jelle Druyts

I've been using the Release Candidate of Visual Studio 2005 lately, and I'm very pleased with the overall look and feel of the application. There are still some issues left to work out (I get the occasional crash and burn), so I hope they'll all be gone by the time they RTM in the week of November 7th...

One of the things I really wished they would have fixed, though, is the way references are handled in ASP.NET 2.0 websites or WebService projects. This is what I had to say about references in June 2004, and it still holds true:

Although certainly not always possible, the ultimate solution to problems with references has always been using Project References. So that's what I'm doing now, but in ASP.NET they tend to switch from project references to fixed binary references that don't get updated anymore. And you wonder why you get runtime errors... So you need to check those references regularly and reset them to project references. Joy! What's even funnier is that an ASP.NET site doesn't have a project file anymore, which would be fine if there was nothing to remember for an ASP.NET project. But what about these references? I'm sorry to have noticed that, but they're stored in the solution file. Bad, bad, bad... If you have multiple solutions with the same ASP.NET project in them, it would depend on the solution file which kind of references the project would use. If you really need project-settings, revive the project file guys and recall the "no project file needed"-hype. What's one file extra going to do anyway?

Apart from the project references randomly becoming binary references (I've seen it happen again in the RC!) I still think it's an even bigger problem that project properties are put into the solution file. If you want proof, this is a part of a solution file that contains a WebService project:

Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = http://localhost/TestWebService/,
          "http://localhost/TestWebService", "{F7389224-931A-4652-A0E2-3A932D1B40C6}"
 ProjectSection(WebsiteProperties) = preProject
  ProjectReferences = "{BC53180F-394F-4F31-A61E-BFBC4DBF9B32}|BusinessLayer.dll;"
  Debug.AspNetCompiler.VirtualPath = "/TestWebService"
  Debug.AspNetCompiler.PhysicalPath = "..\..\..\..\POC\TestWebService\"
  Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\TestWebService\"
  Debug.AspNetCompiler.Updateable = "true"
  Debug.AspNetCompiler.ForceOverwrite = "true"
  Debug.AspNetCompiler.FixedNames = "false"
  Debug.AspNetCompiler.Debug = "True"
  Release.AspNetCompiler.VirtualPath = "/TestWebService"
  Release.AspNetCompiler.PhysicalPath = "..\..\..\..\POC\TestWebService\"
  Release.AspNetCompiler.TargetPath = "PrecompiledWeb\TestWebService\"
  Release.AspNetCompiler.Updateable = "true"
  Release.AspNetCompiler.ForceOverwrite = "true"
  Release.AspNetCompiler.FixedNames = "false"
  Release.AspNetCompiler.Debug = "False"
  SlnRelativePath = "..\..\..\..\POC\TestWebService\"
 EndProjectSection
EndProject

The rest of the settings are also project-specific (hence the ProjectSection) so I think it's all unacceptable. But I guess it's too late to change any of this...?

Update: I did some thinking and some of this might actually make sense... As the line in the solution file above actually states, it's a Project Reference. Since project references refer to other projects within the same solution file by definition, this is actually quite logical. I tried to do the same thing with a non-project reference (i.e. a binary reference) and it's not stored in the solution file. But before you start cheering, be aware that the reference isn't stored anywhere at all. The assembly is just copied over to the website and you'll have to update it manually if the reference changed. Not too brilliant either... The fact that project references tend to switch to binary references might have something to do with adding the website to a new solution which doesn't contain the referenced project, but I'm not so sure the reason is that simple.