Cluebat-man to the rescue : Visual Studio

File a bug report and make Visual Studio a better product

vanDooren — Thu, 22 Jan 2009 06:50:00 GMT

If you find a bug in Visual Studio, report it on http://connect.microsoft.com If the bug affects the version of VS that is in development at that time, there is a significant chance it will get fixed before the next release. Just this week I got confirmation that all 3 bugs that I filed in the last months have been resolved.

The first one is a nasty one. If you add an ATL project to an existing, non-empty solution, the ATL wizards will either hang the IDE or fail to work when adding an ATL object. I found a workaround for it, but it involved hand editing the solution file.

The second one is a small bug in the TR1 regex parser. No workaround, other than to restructure the regex.

And the last one was an error in the MSDN documentation about open modes with the fopen family, which counts as a bug because it triggered runtime errors.

All 3 have been fixed. I especially appreciate the first one. I am working on ATL projects, and I develop my COM server in the same solution as a couple of related non-ATL projects. So every time I work with ATL projects, I can have a warm and fuzzy feeling that because of me, VS is now a better product. :)

Found an interesting bug in the Visual Studio IDE

vanDooren — Thu, 08 Jan 2009 07:18:00 GMT

I know, I know, ... .NET is all the rage, and DCOM is legacy technology, best not touched by up and coming programmers with good hair and sharp look, lest they appear 'uncool' or even worse: 'obsolete'.

But some of us still use DCOM for a number of good reasons. And ATL takes much of the pain out of DCOM development. Unfortunately, the Visual Studio IDE doesn't always cooperate. I made a simple MFC dialog client application, and then tried to add the ATL Server project that the client would connect to. VS was clearly concerned about my attempts to use DCOM instead of .NET, and decided to sabotage my attempts to do anything useful with this new ATL project.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391506

But luckily, I was able to figure it out and outsmart VS :)

Visual Studio 2008 on Windows 2003

vanDooren — Fri, 21 Nov 2008 20:39:00 GMT

I've had a weird problem on my development station for some time now. Every time I ended a debugging session of a C# project, visual studio froze for about 10 seconds. It also happened if I changed project settings, but I never had any problems with C++ projects.

My development station at work is a DELL Precision 670 running windows 2003 server. It has 2 dual core Xeon cpus, 4 GB of memory, an nvidia 8500 graphics board and a WD sata hard disk. It is fast, so any lags or slowness would not be hardware related.

Now, if I was Mark Russinovich, I would use my extensive debugging experience to track down the underlying problem. But I am not, and since the majority of my work is C++, and I don't start and stop debugging sessions frequently, I could not be bothered to spend a lot of time to hunt down the problem. Installing VS2008 SP1 didn't fix the problem so I suspected it had something to do with my local configuration.

Today I finally figured it out: This was caused by the windows 2003 'Enhanced Internet Security configuration'. Removing that from my system solved the problem and VS2008 was finally as snappy as I'd expect.

I don't know exactly what the problem was, but C# projects do much more with XML and html than C++ projects. I think it is probable that C# projects do something that triggers the security configuration, which then doesn't respond because there is no user to acknowledge a prompt. 10 seconds looks like a reasonable connection timeout, so it is at least plausible.

I still would like to figure out the real cause of the problem, but at least my problem is solved. If you experience anything similar on Windows 2003, it might be worth trying this.

In my case I simply removed the entire Enhanced Internet Security configuration from my system. It is not connected to the internet, so the risk is pretty much nonexistent.