“I have virus protection software X with Y features enabled and I’m trying to get Visual Studio to do Z but I see error messages instead.  What can I do?”

 

I see this question a LOT about Visual Studio .NET 2002 and 2003.  This post is an effort to consolidate the answers to these general issues into one location. 

 

Why do these problems exist?

Two reasons:

  1. During the 2002/2003 we never had much focused testing that included virus protection software outside of what is installed on the desktops here at Microsoft.   For the Whidbey release we are going to push testing with several other virus protection suites enabled as well.
  2. Some anti-virus software is overzealous in how they go about their business.  This is sometimes good for security, but usability generally finished a distant second in these cases.

 

What are the common problems and what can I do about them?

 

Don’t run script blocking software during the install of Visual Studio.  If you did, ignored warning messages during the install, and you’ve had problems with VS from the first launch there isn’t much you can do but re-install VS.   Covered in this KB article. For Whidbey we’ll be moving the install away from its reliance on scripting thus avoiding this issue. 

 

Other Script Blocking Issues: If you got past the install of VS, but have re-enabled most of the popular script blockers you may encounter problems that you will need to turn off script blocking to solve. These problems may not even give you warnings and may just manifest themselves by just shutting down VS when a user attempts the following. 

  • Creating a project: The project creation wizards rely on scripts that access the file system object to create your project on disc.  I’m told in Whidbey we’ll again be changing our scripting model to avoid these problems.
  • Adding classes or items to a project. (If you see a trend it’s pretty much anything that uses a wizard is most likely using scripting behind the scenes.)
  • Accessing the Start Page features: The start page uses the file system and registry to get MRU information in 2002. In 2003 we moved the MRU to be a normal win32 component for performance reasons. This also had the effect of removing the script warning whenever you start up VS.  You may still see script warnings though accessing the “Community Features” of VS 2003 since that relies on the 2002 start page code that uses scripts.  In Whidbey we’ve replaced/moved most of the start page functionality so it won’t be an issue.

The problem with turning off script blocking completely is that there are useful reasons to enable script blocking.  If your AV software allows you to be selective you should try to allow the devenv.exe process to run unfettered and ignore warnings from “VS://” URLs. 

 

Real Time Scan Issues: Virus Scanning software enabled for “Real-Time” scanning can dramatically effect performance and sometimes cause apparent hangs during the following operations listed below. The only solution is to disable the real time scan. Some real time scanners will let you tell them to ignore files in certain locations which might be a more secure option.

  • Compiling/Building larger projects. See KB 250670 or KB 236399.
  • Accessing Projects over source control or network shares.
  • Debugging a project
  • Visual Studio Startup and Shutdown
  • Opening help or help windows
  • Installation
  • Deployment of apps

Other Random Issues:

  • Exceptions when debugging ASP.NET apps? Check out this KB Article.
  • There is some (less frequently used) anti-virus software that actually modifies the name of the running process and or the executable names. If you try to start VS and get a warning that it is unable to find a certain file ensure that the running process is “devenv.exe” and not that name with random characters inserted in front of the process name.  We don’t run very well if someone changes the name of our running process. J
  • Real time scans can cause files to appear as changed just after project creation/opening.  The solution is to disable the real time scans from touching Visual Studio associated files.
  • VS and Kaspersky Antivirus are apparently not compatible. See this thread.
  • Some firewall/Proxy server combinations will disable Start Page features and result in the message “You must be connected to the internet to use this feature”.  This is because the Start Page relies on the MSXML component for content downloads and there is an issue with this component that will cause it not to retrieve information that you could see with a normal http request to the source. 

If I find more issues I’ll post them here as well.  If you have run into other similar issues feel free to send them my way. 

Thanks,

            josh