Rant follows…

1) Adding a new web site. If you start a new solution with a new web site, and choose the default project location listed in the project options, VS creates 2 top-level directories…

‘WebSite1’
‘WebSite1 (2)’

‘WebSite1’ has the project files, and ‘WebSite1 (2)’ has the solution file. Everything should go under one parent directory like other projects. If you add a web site to an existing solution, the web site is put in a subdirectory under the solutions directory by default. There does not seem to be a way around this behavior.

2) No matter what I do, I can not add existing images or other files to a resource file and get a successful build. In multiple projects on two machines, I get…

The "GenerateResource" task failed unexpectedly.
System.Runtime.InteropServices.COMException (0x80004005): Projectitem unavailable.
   at Microsoft.Build.Shared.ExceptionHandling.RethrowUnlessFileIO(Exception e)
   at Microsoft.Build.Tasks.GenerateResource.NeedSeparateAppDomain()
   at Microsoft.Build.Tasks.GenerateResource.Execute()
   at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound) 

The files exists. Am I missing something?

[UPDATE] This happens if the file is already in the project but not in the Resources folder. The GenerateResource task looks in the Resources folder for the files. If the file is already in the project, VS adds it to the resource explorer without warning the user it will not be able to find it unless it is moved to the Resources folder. Files not a part of the project will be copied to the Resources folder when they are added.

3) Files are excluded from a project by adding a .exclude extension to the files. Excuse me? Why are my files being renamed? I have a large amount of media files (high res images and video) that I do not want in my project. I do not want them added to source control. Some are not final files. They need to be in the site hierarchy because they are used in the site. Adding a .exclude extension breaks every link in the site pointing to them.

If you are going to do site management, then do site management.  This eleventh hour hack crap does not cut it.

Since the web “project” references now have the (eleventh hour hack) .refresh files for each external assembly that should be refreshed during a build and all the excluded files get a .exclude extension, I was thinking. Why not move the info for each .refresh file into a single file. A listing of all the files that should be excluded could also be added to that file. You could associate one per project. It could be called, oh I don’t know, just something off the top of my head, a PROJECT FILE.

4) Having to use a beta project add-in just to get a sane web project deployment, and not having my dll’s ready to go just by clicking build. Who uses VS to deploy web projects anyway? If you do, read Jeff's post before you loose your data.

5) No support for more than thirty syntax highlighting entries. If you use ReSharper in 2003, you know how much easier it is to read the code with the additional highlighting. All of those additional entries are stored in the registry. In 2003 there seemed to be no limit to the number that could be added. In 2005, adding more than the thirty or so existing ones causes the additional ones to actually get random colors from the other entries.

If you have used the ReSharper EAP for 2005 you have probably seen it. It is not just a ReSharper issue. Manually adding additional entries in the registry causes the syntax highlighting to start randomizing.

Any plug-in that offers additional syntax highlighting through this means probably will not work correctly in 2005.

6) Refactoring.  Useless as soon as you add a web "project". Ok, that may not be the norm. I did however just discover another refactoring annoyance while trying to reproduce this one. Checking 'Search in comments' when renaming is very indescriminant about what it renames in comments. I would expect it to rename xml cref references to the member you are renaming. Nope. Don't rename a parameter called 'name' and check search in comments. Every comment instance of the word 'name' in the project and referenced projects will be renamed. Including name=""> in every documented method. userName=""> is not a valid xml comment tag :). I tried re-refactoring userName back to name. Now all my comments with documented userName parameters say name.

ReSharper does a good job of updating the documentation references to the renamed member. I feel like I am more productive using 2003 + ReSharper than I am in 2005.