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.

Visual Studio and SQL Server 2005 launch day

Was Visual Studio 2005 ready to ship, or was it rushed out the door? Many very informed bloggers have already posted their opinions. Having used the products for months, I feel obliged too.

This is a comment I wrote today in Mini-Microsoft's blog:

I think it is good that Microsoft shipped Visual Studio 2005, even in this state. At least RTM means that it has support, while CTP does not. I have been working intensively with the IDE for months and I know it is still buggy, but most problems have workarounds, and Microsoft can afford this situation better than the no-ship situation.

I don't need a service pack in six months. I prefer the 20% of the bugs that make for 80% of the annoyances are fixed much earlier. For me, that 20% means the "Visual Basic background compiler crash", and the "IDE vanishes while opening solution" bugs.

By the way, Microsoft right now has no means of estimating the actual number of occurrences of these crashes, because most developers click on "don't send" button when the Watson tool surfaces. You can read details here.

UPDATE: I must add to this that when the IDE simply vanishes, there is no Watson submission. Also, talking about workarounds: For the first, the best is usually to restart Visual Studio, clean the solution and rebuild. Besides, if you unload projects you are not updating, Visual Studio will be faster and more stable. For the second bug, my workaround is to create a blank Windows Forms VB project and exit the IDE. Next time you start it, your solution will probably load.

So, in the end, I agree with those that say VS 2005 had to be shipped. I love .NET 2.0 and I am happy my company took the risk some months ago to adopt it.

However, I think we are witnessing that Visual Studio code base and/or Microsoft's software process failed to scale to the level of complexity that the products required.

Of course, I am just guessing based on what I have read.

I have read about expert developers needing months to get familiar with Visual Studio code in order to fix bugs. I also read about developers not being able to fix bugs without triggering regressions. I have heard of Rascal, the lightweight IDE many developers choose internally over Visual Studio.

To some extent, this is all normal. But if things are getting worse at an exponential rate, as happened with Vista, then maybe it is time for a "reset".

This reset would hopefully imply both code base and process refactoring.

Is it time for Microsoft to go shared source with Orcas? Whatever helps streamlining the process and the code is good. Sometimes the sole process of preparing the code for being scrutinized and extended by an external community is worth the ticket. However, I expect 90% of future development would be by Microsoft personnel anyway.

I just hope they will think about this possibility.

But my most urgent need is that they fix VS 2005 steadily, and I need them to start right now.

They do that, or I will loose all my nails and hair!

UPDATE: Thinking more about it, I have the idea that the software development process have improved a lot at Microsoft over the last several months and few years. That is not to say that the process is good enough, but it is improving.

Then maybe the main problem is the code base, or perhaps the goals are simply set too high.

Regarding SQL Server 2005, I think it is a much more solid release, but I haven't really used it that heavily.

How much is your blog worth? (boring sunday stuff)

While I was trying to find out why Microsoft's "Desarrollador Cinco Estrellas 2005" site is broken, I found this:

My blog is worth $4,516.32.
How much is your blog worth?

I haven't blogged for a while, but yes, I am following the Live thing

I am a feeling far from this blogging thing lately, as I have been very busy at work, and tired at home. Anyway, I must say I have been following the new Live theme Microsoft has announced.

I am really surprised that some see this as a desperate move. I think the opposite, that Microsoft is proving to be the big company that could. The one that can find a solution for the scalability problem that delivering a new version of Windows is, and at the same time is agile enough to own Start.com and Live.com (by the way, I like this domain very much, I hope the will keep it).

Only time will tell.

On the specific details, I hope the Favorites feature will someday sport some of the features I described in this old post: My favorites: A killer application for WinFS?

By the way, I noticed in my referrals that the other day someone from Microsoft Research was reading that article. Whoever it was, I hope he/she found it somewhat interesting. Specially if it was Susan Dumais.

PS: And Susan, thanks for your email regarding Stuff I have Seen availability.

MSDN Product Feedback is Really Working!

Have you ever get your bugs or suggestions fully addressed by Microsoft? I think I can count the times with the fingers of my knee... But that is until today. Take a look at this:

Opened by Diego on 2005-10-07 at 08:45:27

Recurrent crashes discourage developers of sending crash information every time. Also under certain configurations, the "watson" tool cannot contact Microsoft servers. This way, Microsoft is not getting actual metrics of crash occurrence.

Proposed Solution:

Make it possible to send a lighter crash report. Maybe try to identify if a recurrent problem so if the second time does not provide additional information, only send the "light" version. Also, solve the circumstance in which sending crash data does not work through a firewall (I have not isolated the reason, but in my office some computers can send the reports and some say they cannot reach Microsoft servers).

Edited by Microsoft on 2005-10-07 at 13:34:16

Hi Diego - I have opened a bug against the Watson team for them to consider your feedback.Thanks!Aaron BrethorstVS Platform

Edited by Microsoft on 2005-10-13 at 13:42:16

Hi Diego - I just received resolution on this issue from the Windows team that owns this. Here's what they said:In [Windows Vista] Beta 2 the crash reporting experience for VS will be improved. We will send the most lightweight report possible which does check for recurrent problems. Additionally we queue reports for later if connectivity cannot be established at the time of the report. Additionally users will have the option during install whether to automatically send or not.

Edited by Diego on 2005-11-04 at 19:46:32

Great, I think this covers everything I asked for! Was this really my idea or what?

I swear… I find the sensation very strange...