At the time of this writing there are three Visual Studio versions out there (VS 2005, 2008 and 2010) that support .NET Framework 2.0 and with an extensibility model that allows you to create a single binary add-in dll to target all of them (see HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET). So I wouldn’t support Visual Studio .NET 2003 in a new add-in created today, but my old MZ-Tools 6.0 add-in still supports Visual Studio .NET 2003. On the other hand, the current OS today is Windows 7 64-bit, and, alas, VS.NET 2003 is not supported by Microsoft in that Windows version. Not being supported doesn’t mean that it doesn’t work, specially if you want it only to test an add-in, not for actual development of projects, so I have it installed on Windows 7 64-bit despite all compatibility issues warnings during installation.
Yesterday I wanted to install SP1 of VS.NET 2003, that I noticed that I hadn’t installed, so executed the VS7.1sp1-KB918007-X86.exe setup just by double-clicking it. I got a warning about a security of files from Internet but I authorized its execution. At some point of the installation, I got this error:
“Error 1606: Could not access network location VS Developers (could not create group)”
This problem is caused if you have the User Account Control (UAC) feature of Windows Vista or Windows 7 activated. It happens that this setup was created before Windows Vista and therefore it is not UAC-compliant (it lacks a manifest). So, how does Windows Vista / 7 know if this executable requires admin rights? Windows Vista / 7 knows that most executables that are setups require admin rights, so when the UAC manisfest is missing, it applies some heuristic rules to guess if an executable is a setup or installer. In this case all rules failed, including the most usual one (the name includes the “setup” word) and UAC determined that VS7.1sp1-KB918007-X86.exe was not a setup and didn’t require admin rights, which caused the error above at some point.
Of course the solution is to install VS7.1sp1-KB918007-X86.exe by right-clicking it and selecting the “Run as administrator” menu entry.
Another solution is to rename the setup file name to include the “setup” word, for example VS7.1sp1-KB918007-X86Setup.exe, so that UAC guesses that it is a setup and it prompts for admin consent or admin credentials to elevate privileges.
I could have never found such an exact resolution for my specific problem. It is fixed nicely. Thank you