Visual Studio 2005 and web projects : no good

12 Comments

• While I haven't played a lot with the projectless approach, I'm pretty sure it was introduced not to please PHP developers, but rather solve the issues arising around concurrency and source control. Too often the project file is a point of contention with source control. At worse, if you have your source control set up to not support concurrent checkouts, developers simply can't work...at best you have to deal with messy merges.
  
  
  
  I'm not saying it's worth a high cost, but the complete picture should be painted - ie there are advantages.
  

• Good point Karl, I should have tried to point the advantages out.
  
  However, I understand the advantage you present, but then, why not expand this approach to all kinds of projects? This situation certainly happens for all projects, and not just web projects.
  

• Karl, if source control contention is a major reason for this change, it fails completely, because intra-solution references are put into source control, so they are checked out, thus causing source control contention.
  
  
  
  For enterprise level solutions, the way references are handled now is unnacceptable, the inability to have pre/post events, and including the DLLs in source control.
  
  
  
  Getting rid of a few "special" files does not justify the pain.
  

• "Where is stored the list of references of your project?"
  
  
  
  I'd say its a bug, because there's no notion of "reference", but its rather a copy file "feature". This issue could be solved to use the web.config to store references.
  
  
  
  "How do you share code between pages? How can one page reference another?"
  
  
  
  Just like you did before? Take a look at the different build models to see how stuff gets compiled.
  
  
  
  Besides the "references issue", I must say that I don't really miss the project file at all. I am used to setting up postbuild events for copying the output files to the web application. This is mainly because I often have multiple repositories: 1 for the website itself and 1 for libraries behind them.
  
  
  
  The only reason I could think of that I would want my project file back is to be able to make use of MSBuild.
  

• I dont understand what the problem is. You can still add references to websites, they are just stored in the solution file instead. I dont see how it causes a problem with sharing code between pages either. You wont have to re-learn Visual Studio, you still right-click on a web site and click add reference.
  
  
  
  Its not just about getting rid of two files, its about shifting the entire perception of a web project. Web sites have some very fundamental differences from other projects, they are the only type of project where the majority of what is in the project (if not all of it) is deployed... most other projects compile everything into a single exe/dll. So really the old web project was flawed, this new model is fixing that flaw.
  

• James hit it on the nose. Web projects are different, and VS05 changed its model to try and account for the differences.
  
  
  
  FYI, Beta 2 had the issue of a referenced assembly being placed in source control leads to exclusive check-out issues. This has been fixed post-Beta 2 by not placing refereneced assemblies under source control. Note a newer version of the referenced assembly will always be copied to the bin folder.
  

• The issue with DLLs in the bin directory being checked into source control is a BUG in beta 2 and will be fixed post beta 2 (before release of Whidbey).
  
  
  
  So your issues are going away apart from intra solution references...Which I do not think that many people use...Inter-project "yes", but intersolution is not a big problem...If you need to you the solution suggested by Mike.
  
  
  
  I just love the simplification of the model with VS2005. I have been using ASP.NET and Visual Studio betas since July 2000, and this is just a huge step forward towards greater acceptance of .NET.
  
  
  
  Note we are not just talking about attracting "PHP" developers. If an experienced J2EE develop takes a look at .NET and find the first 2 hours too hard, they may never bother to look any further. The curve needs to be easy whoever you are and whatever experience you have.
  

• I'd have to disagree with the majority of the comments. VS2005's model stinks. Perhaps most of you work in virtual directories natively and don't have to worry about updating an application in the root, with separate applications below, but ... basically, Visual Studio no longer opens a "web site." It opens a "web server." Every project on the same server in the same physical root has to be managed in the same "project."
  
  
  
  Which is crap.
  
  
  
  Our intranet application consists of a root (news display and management) followed by a hierarchy of applications that reaches five levels deep. This system completely fails under VS2005. Under VS2003 we simply have some 30 odd projects that we manage.
  
  

• I love the new way. I've been working on a personal project in 2.0 since December and abolutely dread every time I have to back to vs2003... just the pain of setting up IIS every time is horrible...
  
  
  
  I have a full build system using msbuild which deploys that DB, compiles all depndencies, runs all nunit tests and so forth... was very easy to do and it's even easier to maintain.
  
  
  
  I think it will make life much esier in Enterprise projectes as well.
  

• Alex, you are pointing out new features I think we'll all enjoy. But this has nothing to do with removing the concept of "web project". What you praise could exist even with a project file.
  

• What really would be nice is Visual Studio 2005 giving developers the choice of whether to use the old 2003 solution-style vs the new one.
  

• Fritz, it does know with the Web Application Projects.