UPDATE 3/1/2006: The hotfix is officialy out for the Visual Basic background compiler crash. Thanks to Lisa, Margaret, and the VB Team.
UPDATE 2/12/2006: All I can say for now is that we have seen great progress with the bugs we reported to MSDN Feedback (Ladybug). I feel remorse because after the honor of having Scott answer to this post, most of the bugs I was able to detail were not related with ASP.NET (by far the piece of technology I use and abuse more nowadays). Anyway, we have reported a few other bugs that were not in the original annoyances list and while sometimes the answer is "we cannot repro, please attach a sample", when we have done that the response has been very satisfactory. Special thanks to Lisa and all the VB Team.
UPDATE (a few days later): I finally begun detailing these bugs on the product feedback site. I have been busy trying to finish some critical use cases at work.
The background compiler bug is here: FDBK42191
I admit beforehand that we deal with MSBuild and Visual Studio 2005 project files as black boxes. The less we get involved with them, the better, as we already have other complexities to deal with. However, I have spent sometime comparing different versions of project files for troubleshooting.
We are only a couple of developers working on an ASP.NET application making use of 11-12 separate components. Here is a short list of some problems we have experienced. Many of them are not related to MSBuild, I think, but in the end, the aggregate result leads us to rebuild our references from time to time:
- Many times a day the Visual Basic background compiler crashes on our project. Once it has crashed once, it will crashing every two seconds. So, we need to quickly kill the devenv.exe process to get rid of the never stopping Watson window.
- After one of those crashes, most times Visual Studio will refuse to reload our solution. Instead it will kill itself and vanish of the desktop, not even bothering to summon Watson. We have learned a couple of tricks for that. First trick it is to create a new VB Windows Forms project and then restart the IDE (DonÂt ask me why, but this is sometimes enough). When the first trick fails, we usually go and delete the .SUO file. After that we usually get Visual Studio to load the solution without a glitch.
- For simplicity we have chosen to use a single solution file both for development/debugging and for integration. Within the solution, we organize our projects using solution folders and we use project level references among the different assemblies. But in order to get a streamlined development environment, we usually hide and unload project groups selectively (solution folders are very handy for that). Then, when we need to reload and modify a project, we sometimes get in trouble. It seems that the in-process build system in Visual Studio gets something wrong with dependencies or whatever, and we end up receiving very bizarre errors messages (like missing members in standard System.Web classes or in our own classes). So, the usual workaround is to clean the solution and make a complete rebuild. Of course this takes time and make us wonder why do we need a sophisticated build system in the first place.
- We have been lately looking for ways to improve the time of our build process. We found that each build was writing around 150 files to disk, so we started by sending all external assemblies to the GAC and turning Âcopy to localÂ off on every project. The front end project is a Web Site, so this is the only project that needs every assembly in its ÂbinÂ folder. These measures improved things.
- Maybe because of the crashes, because of us deleting the .SUO file or because of a bad interaction with our Version Manager (we use PVCS VM and Tracker add-in, which I figure is not ideal), sometimes things go really bad. Some times we loose information in our solutions, like which projects are meant to be built or some project level references. Other times we get error messages while the IDE loads the solution, saying that it cannot load the version manager add-in.
- When things go too bad, what we do is start from a new solution file from scratch, and then is when we have to rebuild our dependencies. I think this happens approximately once every two weeks. I know we could save a working copy for this. But due to the few things that change (added and removed projects) and with all our configuration management practices in place (but failing to deliver), we usually think like: "I don't remember what changed, lets rebuild the whole thing".
- Web site projects have proven more troublesome that regular projects. For instance, we have found that we cannot have a Web site two folder levels down the solution file. For instance if we have the solution file in a folder called Â\SystemÂ that contains a Web site located in a folder called ÂSystem\UI\WebÂ we cannot get this to work correctly. Eventually (we still need to catch it in the act), the web site is copied to ÂSystem\Web\Â. Conversely, when we tried to fix this by deleting the site located in ÂSystem\WebÂ and trying to re-add the site located in ÂSystem\UI\WebÂ we usually get a message saying that Âthe site located at ÂSystem\UI\WebÂ has been deleted or moved. It says that, but it is clearly trying to find it at ÂSystem\WebÂ.
- Also, with Web Sites, there seem to be some ambiguity that confuses us a lot regarding what is a reference and what is just an assembly copied in the ÂbinÂ folder. For instance, when we try to add a project level reference to a web site (one that is not showing in the reference list) it will say it cannot add a reference if the assembly has already been copied by other means.
All this said, we still got to do significant work with Visual Studio in a few months. We like a lot how our ASP.NET 2.0 application runs, and we are not looking back. If we get those annoyances solved soon, Visual Studio 2005 will be, without a doubt the most productive environment I have ever used.
I intend to search and submit every one of these problems to MSDN Feedback when I have enough time.