Saturday, November 12, 2005

Visual Studio 2005: Our list of annoyances

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

Sumedh, of the MSBuild Team, asks me why should I bother to rebuild project dependencies every other week. The answer is, in a very positive tone, that we do it because of too many bugs.

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.

6 comments:

Anonymous said...

Hi Diego,

Can you send me an email (scottgu@microsoft.com) with details about the problems you are seeing? I will then follow-up with the appropriate folks here at Microsoft to investigate these issues further and debug them with you.

Thanks,

Scott

Anonymous said...

Diego, What would be really helpful is if you can grab the watson bucket number from a crash (after uploading a watson dump, go to the application event log, find the most recent error event, and there should be a number in the event like 12345678 which is the bucket number). You can get that number to us along with repro steps and details of your environment (information that obviously isn't uploaded), by opening an issue at http://lab.msdn.microsoft.com/productfeedback/default.aspx. That would be really helpful.

Diego said...

To both Scott and Sumedh (I think the second comment is yours, am I right?): No need to say I was delighted to see your answers. I am 100% in for helping you debug this. I am right now talking with my coworkers about the details. You will hear from me soon.

Anonymous said...

Diego, the anonymous comment isn't mine, but thanks for providing all this feedback. Looks like Scott is going to follow-up. Cheers!

Diego said...

Apologizes to all, I have been sick, and before that busy for a day in Microsoft’s Launch event here in Santo Domingo. I will be writing that detailed bug report as soon as I can.

Diego said...

Guys, 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: http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=4e1b5f09-df05-4bc7-a751-52a316f64aad

Moving to MSDN

I haven't decided yet, but it is very likely that I will stop blogging here for some time. For some background, I have moved to the sate...