I have been using NuGet for quite some time on a particular PC. Now, I created a new project in VS2010 (it's an MVC 4 Beta project using the Single Page App template if that matters). When I select
Tools / Library Package Manager / Package Manager Console
The console window opens but displays the error:
File C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.7.30402.9028\Modules\NuGet\profile.ps1 cannot be loaded
because the execution of scripts is disabled on this system. Please
see "get-help about_signing" for more details.
However, other projects can still open and use Package Manager Console.
In each case, VS2010 is running as the same user.
If I open a command prompt (using the same account under which VS2010 is running), start PowerShell, and enter the command
Get-ExecutionPolicy
PowerShell returns
Restricted
My understanding based on a Scott Hanselman blog is that scripts should not run at all if the ExecutionPolicy is restricted.
Why are existing projects able to use the Package Manager Console while a new one is not?
Update: Changing the ExecutionPolicy to AllSigned and restarting VS2010 solves the immediate problem, but my main question is why the other projects were able to bypass the established ExecutionPolicy. VS2010 is not running as an administrator.
I experienced the same problem and solved it by:
Opening Powershell as an Administrator
Entering the following command "Set-ExecutionPolicy RemoteSigned"
Restart Visual Studio and the Package Manager Console worked as expected
It is important to note however that Powershell will give you a warning
"The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution policy?"
And should be careful of enabling this feature and should read more information in the help topics about the security risks.
In addition to Murries' answer, I found jellonek's post (on another thread) helpful. You might have to change the permissions on a different version of PowerShell (32-bit and 64-bit versions require separate permissions).
From How to Tell if PowerShell is 32-bit or 64-bit:
64-bit PowerShell Path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
32-bit PowerShell Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
Also, BOTH of these should work:
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Unrestricted
Another way to fix this is by merging a Regedit file with the following content:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
(Create a text file called NuGetPowerShellFix.txt, copy paste the above into it, rename to NuGetPowerShellFix.reg, then run.)
After merging the above file, restart Visual Studio.
If you're using NuGet in Visual Studio 2013 and get this annoying error, go to Tools | NuGet Package Manager | Package Manager Settings and click "Clear Package Cache." Restart Visual Studio. I know there are multiple solutions to this, so this is yet another to try.
I have had this problem intermittently as well. I just came across it again and ran across this thread. In my latest case, I realized I had VS 2013 open twice (which normally is not an issue, I do it all the time). Since the only common theme of others that seemed to fix it was circumstantially related to requiring administrator privileges I gave it a shot and closed both instances of VS and reopened my solution in a new instance. Ran the nuget install and it worked without a hitch.
Based on this, I am thinking that it is a file permission issue causing this spurious error. Sort of like when windows has a lock on a file in the bin directory after a debug session and will not let you compile the solution.
You may be able to resolve this by not running Visual Studio as Administrator.
Different cause, same error message; might be helpful for someone who runs into this one.
Since we needed to create a project on a share on a remote server in our network and ran into similar problems here's what worked:
map the share as a network drive, say R: (but I guess it would also work without this mapping)
open Internet options > Security > Local intranet > Sites > Advanced (via IE or control panel)
add either "R:" or "file://server.domain.xy" (the former will automatically turn into the latter once you reopen the dialog)
run the x86 PowerShell executable and do "Set-ExecutionPolicy RemoteSigned"
Once I did all that Visual Studio didn't complain that the project was in an untrusted location upon opening the solution again, and it successfully ran all the PowerShell scripts for the packages that get auto-installed when creating a new MVC application.
I'm having this issue now, i think what worked for me easy was that i just had to restart visual studio 2013 and run it as administrator...worked fast for me.
Related
I have installed Visual Studio on Windows server 2012 and now I'm trying to debug an existing project. This gives me 'Error while trying to run project - access denied'
I have now problems running the project without debugging.
I have restarted Studio and no files are read-only
Found the solution enable 'use managed compatibility mode' in the debugging>general section of VS2017 options. found here:https://developercommunity.visualstudio.com/content/problem/49763/access-denied-when-attempting-to-run-under-the-deb.html
Access Denied errors can occur if a file has an unresolved lock on it. This can happen whether or not your file, typically the executable that you just compiled, is read-only or not.
The easiest way to clear a lock like that is to reboot your system. Or if you're unwilling to reboot or you just want to make one file available again, you could use a tool such as Process Explorer to find the process that is using the file, and either close the program or kill that process.
What fixed it for me (Running VS2019 + Win10) was adding my source folder to the exclusion from Windows Defender Threat Protection.
Found the solution was to DISABLE 'use managed compatibility mode' in the debugging>general section of VS2019 options.
Windows Registry Editor
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001
This will solve the problem
visual studio 2017 community.exe won't run after extracting to the temp.
OS: windows 10 x64bit
Setup : community version
in the temp folder bootstrapper log says,
Beginning of the log. Start Time: 3/26/2017 1:14:54 AM
VisualStudio Bootstrapper:3/26/2017 1:14:54 AM: Current Optin root path does not exists
VisualStudio Bootstrapper:3/26/2017 1:14:55 AM: Commandline arguments =
and the dd_vs_community_decompression_log says
[3/26/2017, 11:17:47] === Logging started: 2017/03/26 11:17:47 ===
[3/26/2017, 11:17:47] Executable: C:\Users\Sameera\Downloads\Programs\vs_community.exe v15.0.26228.0
[3/26/2017, 11:17:47] --- logging level: standard ---
[3/26/2017, 11:17:47] Directory 'C:\Users\Sameera\AppData\Local\Temp\4ceac4b7b9cd9fdf2489526c66\' has been selected for file extraction
[3/26/2017, 11:17:48] Extracting files to: C:\Users\Sameera\AppData\Local\Temp\4ceac4b7b9cd9fdf2489526c66\
[3/26/2017, 11:17:48] Extraction took 360 milliseconds
[3/26/2017, 11:17:48] Executing extracted package: 'vs_bootstrapper_d15\vs_setup_bootstrapper.exe ' with commandline ' '
[3/26/2017, 11:18:10] The entire Box execution exiting with result code: 0x0
[3/26/2017, 11:18:10] Launched extracted application exiting with result code: 0xc000000d
[3/26/2017, 11:18:10] === Logging stopped: 2017/03/26 11:18:10 ===
can't find proper solution..
I had this problem too. SHClark's answer didn't work for me. I figured out myself what was causing the problem on my computer: Mirekusoft Install Monitor. I disabled both its services and that solved the problem. (I guess that's not an extremely likely program for someone to have running, but it could be a problem common to install monitors in general?)
I also heard from someone on the Visual Studio Community forum that RivaTunerStatistics (used for gaming) can cause this problem too.
One of my co-workers encountered the same problem. We spent 4 hours searching for solutions, uninstalling VS and other software that we thought might be the culprit.
In the end, THIS LINK helped us figure it out. The problem is somehow explained there and is linked to NODE_OPTIONS variable. If you have that variable set, remove it then restart your computer. This solved his problem.
Configuration:
Widows 10, Visual Studio 2017 Enterprise.
I hope this helps you
I was able to resolve my problem after 4 days of troubleshooting with Microsoft support. I'm developing on a Dell laptop and the support technician believes one of the Dell services was causing issues with the winmgmt service.
Below is a command that failed to run. Then after making sure we had an OS restore point saved, we issued the /resetRepository command. After that, the VS 2017 Pro installer was able to execute without error.
EDIT: Adding the exact steps and code sample below:
Step 1: Create a Windows system restore point.
Step 2: From the command prompt with administrative rights or elevated privileges, execute the following command: net stop winmgmt
Step 3: Open a Windows Explorer and locate the path to C:\windows\system32\WBEM\ folder and rename the Repository folder to something else like RepositoryOLD (right click and choose 'Rename Folder').
Step 4: restart the computer
Step 5: From the command prompt with administrative rights or elevated privileges, execute the following command: net stop winmgmt
C:\>net stop winmgmt
The Windows Management Instrumentation service is stopping.
The Windows Management Instrumentation service could not be stopped.
Step 6: From the command prompt with administrative rights or elevated privileges, execute the following command: winmgmt /resetRepository
C:\>winmgmt /resetRepository
WMI repository has been reset
Step 7: restart the computer.
Hope this helps anyone with a similar Visual Studio 2017 installer issue.
Copy vs_community.exe to a USB and run. It will work.
I had the same (or similar) problem. I couldn't update VS2017, either from within the program or by trying to run the installer.
The web page at https://learn.microsoft.com/en-us/visualstudio/install/troubleshooting-installation-issues had instructions that resolved the problem. For me, deleting the 'Installer' directory and then retrying the installation resolved the problem.
Try deleting this folder C:\Program Files (x86)\Microsoft Visual Studio\.
Restart the install.
Note for others with installer problems for Visual Studio 2017/2019/vNext
Before messing with your system FIRST TRY CLOSING EVERY OTHER PROGRAM.
Sounds silly, i know! But I almost missed inhahe's answer mentioning that RivaTuner could cause problems. Closing that caused it to start working instantly.
TL;DR: Close all other programs like you always ignore in installation instructions :)
Try to stop MSI AfterBurner. Worked for me.
It's the same answer as in question visual studio 2017 install break : it not get start just in case you don't observe the other question.
I had the same Problem on two different Pc's (both win10) and the only thing that worked for me, was reinstalling Windows's and rerun the visual studio installer. I know, that's not a good, fast or easy solution, but it works.
I have been having this issue all day and MS support were not able to help. To solve my issue, I updated my video driver to the latest version (I was intentionally using an old driver as the new versions don't support my monitor resolution). The visual studio installer must use a GUI tech not supported by my older card and just fails before the installer GUI loads. The same issue happened with the older, offline installers for older versions such as VS2013.
I had the same issue, the fix is: go to reigonal settings from control panel, then on the administrative tab select (or if selected reselect) current language for non-unicode programs. than try again.
I had the same problem. Here is my solution:
right click vs installer, extract with winrar.
go to extracted folder.
run: vs_setup_bootstrapper.exe
This worked for me :)
I had the same problem and the problem was my user name containing both space and a non ascii character (Olcay Ertaş). I have moved the installer to my root folder and it worked. This is probably the reason why #oğuzhan-türk's solution is also working.
I had the same problem also (with a Dell labtop) and SHClark's didn't work for me.
Here is what I did:
I used the command line to create a local cache of the files you need to complete an offline install
[ctrl] [shift] [enter] for the cmd prompt to run as admin
1) typed
d:\vs_community.exe --layout h:\vs2017layout --add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended --lang en-US
once it was done downloading to h:\vs2017layout,
2)
opened h:\vs2017layout\vs_setup.exe
finally got it to open after extracting but ran into this error:
The name of the file cannot be resolved by the system
so I created a link for the c:\ProgramData\Microsoft\Visual Studio folder using the following command at windows cmd promt:
mklink /D "C:\ProgramData\Microsoft\VisualStudio" "g:\ProgramData\Microsoft\VisualStudio"
It worked after that. Not sure if the second error was related to the first. Hope this helps.
If you have Win8 you needed to update your system to 8.1 ver. and restart your computer.
I had this problem. Turned out there was an old, failed installation on the drive. I had to go to Control Panel->Add/Remove Programs and remove Visual Studio Install Tool. After that the installer worked fine.
Faced the same problem with Visual Studio 2019, but I think version doesn't matter here. This thread helped me: https://developercommunity.visualstudio.com/content/problem/326811/vs-community-installer-not-running-working.html.
The reason was in somehow corrupted .NET files.
Actions applied:
deleted all apps with "Microsoft .NET" in name using https://support.microsoft.com/ru-ru/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
downloaded and installed latest version of .NET Framework Runtime (not .NET Core Runtime) from https://dotnet.microsoft.com/download, in my case it was version 4.8
restarted PC
This helped me.
Nothing worked for me here however i was able to find out that there was an error with the main.js file that he couldn't find the temp folder. so i looked up the environment variables and indeed for my current user TEMP was not set resp. empty. i copied the default temp value(%SystemRoot%\TEMP) for all users to my current user TEMP variable and afterwards everything worked
I have lost a lot of time to solve it. By me, it was an error in machine.config, which I made 2 weeks ago. I have found it only because I have tried to uninstall the JetBrains too. And there was an error too , but with a log, where I could see it.
After search during days and didn't work...
I tried uninstall all .NET frameworks and it works!
I have tried all the answers provided so far and none of them worked for me.
What I did after 2 days of searching for issues online and google-ing, as I have started Windows Event Viewer and googled the error that was logged in the Event Viewer at the time of Bootstrapper crash.
The problem was somewhat similar to #inhanes problem above. It turned out to be the Fresco Logic Driver installation that was causing the issue. I have deleted the driver (add or remove programs -> uninstall) and the damn thing worked.
By the way, this driver is written for USB3.0->HDMI converter.
Anyway, guys and girls: Event Viewer which is a built-in Windows logger can be helpful. :) Now I can just leave in peace and develop my stuff.
I am trying to run any program on visual studio 2013 update 3 and I get the following alert box:
Process with an Id of #### is not running.
Every time there is different ID number showing.
and in the error windows, I get this error message:
The program '[3148] iisexpress.exe' has exited with code -1073741816 (0xc0000008) 'An invalid handle was specified'.
Sometimes it runs and in the browser I get the following message:
The webpage is not available.
Why is this occurring and how can I resolve it?
The following steps fix the problem for me:
Close Visual Studio
Navigate to the folder where your solution files are stored and delete the hidden .vs folder.
Restart Visual Studio
Hit F5 and IIS Express should load as normal, allowing you to debug.
Note: Based on my experience and others in the comments, this problem seems to be caused by moving a project between workstations, environments, or versions of Visual Studio. There must be some environment specific information contained in the .vs folder.
Open Visual Studio as an administrator
Right-click your project and click on 'Unload Project'
Again, right-click your project and click on 'Edit PROJECT_NAME.csproj'
Find the code below and delete it:
<DevelopmentServerPort>63366</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:63366/</IISUrl>
Save and close the file .csproj
Right-click your project and reload it
First Error
For the first error:
Process with an ID #### is not running.
The following steps worked for me:
Close all instances of Visual Studio.
Rename the IISExpress folder (in my PC is in C:\Users\jmelosegui\Documents).
Add the _CSRUN_DISABLE_WORKAROUNDS Environment System variable with the value of 1.
Start Visual Studio in administrator mode. (In Windows, right click the executable file and select Run as administrator).
Second Error
The second error:
The webpage is not available
What caused this error:
I deleted IIS Express Development Certificate while playing with the SSL.
The following steps worked for me:
Go to Control Panel.
Select Add/Remove Programs.
Locate IIS 8.0 Express.
Right click on it then click Repair.
Your certificate should be back!
With respect to the first error:
Process with an ID #### is not running
This situation will sometimes occur when IIS Express fails to bind to a port. A likely reason for that is that some other process has already bound to that port. Visual Studio will launch the IISExpress.exe process (which will fail to bind to the port and exit again) and then attach to the now-terminated process, resulting in the above error.
To check, note the port number in your project settings (e.g. 12116) and then try:
netstat -ano | find "12116"
If another process has the port open, this will give its PID. You can then choose to kill the offending process or reallocate your own port number.
If you are using a 64-bit machine
Then the problem maybe due to Visual Studio use of 32-bit IIS-Express.
Solution: In Visual Studio, go to Tools menu > Options > Projects and Solutions > Web Projects > Enable the option "Use the 64 bit version of IIS Express" and click ok
I had the same problem. Just restarting Visual Studio worked for me.
My fix was simple, I was missing prerequisites. I needed to install .NET Core SDK
Kilanny's answer is correct. Most machines in 2015 are 64bit, so there's a lot of chances that you just need to enable the 64bit option under the Tools main navigation link menu. No need to configure other files or hard code ports. Besides, port assignment should be dynamic. This fix applies to 2013 With Update 3 and Visual Studio 2015 Community Edition.
Check the images below for a mini tutorial:
(I'm just improving Kilanny's answer)
It looks like there are many solutions that work and some that don't...
My issue kept surfacing after a few test iterations.
Yes restarting the PC and/or VS would resolve the issue...but temporarily.
My solution was to undo a security change I had enabled a couple days
earlier to Controlled folder access under Ransomware protection.
I undid this change by:
(right click Start)
Setting->Update & Security->Windows Security->Virus & threat protection-> Virus & threat protection settings->Manage settings
Under Controlled folder access
Click->Manage Controlled folder access
(this is also the Ransomware protection screen)
Turn Controlled folder access off.
This was 100% the issue for me as I was able to run my test without restarting VS.
Another reason this can happen is for a .NET Core Web app if you upgrade the Microsoft.AspNetCore.Components.* NuGet package to a new version but don't install the new SDK,
In my case it was upgrading Microsoft.AspNetCore.Components.WebAssembly from 6.0.0 to 6.0.1 and didn't install .NET 6.0.1 SDK
go to Properties of the start up project, increment port number of the Project Url is probably the quickest way to get around this problem which I didn't read anyone mentioned yet.
And you don't need to restart VS as it can be a pain sometimes if you needed a few other instances needed to be running.
My solution to this on a new machine and fresh install of VS 2022 was to install the 3.1 framework. So check to make sure whatever framework the project is expecting is installed on your local machine.
I had a similar problem with Chrome. It appears that VS can't attach to the Chrome process for some reason.
Solution:
Close Chrome
With Chrome closed, start the web project and allow VS to open Chrome.
For me, none of the other solutions worked.
The things I tried:
Updating and patching everything associated with Visual Studio
Reinstalling Visual Studio
Reinstalling IIS Express
Several reboots
Adding the _WORKAROUND thing to the PATH
Renaming the IIS folder under documents to regenerate the IIS config
Manually editing the csproj file and removing the whole IIS settings section
Changing the IIS executable usage to 64bit in VS settings
Changing the port of IIS in the projects settings
After checking if the problem was persistent over different projects, it turned out that the problem only occurred in one specific projects. I figured that I had to delete all the user specific files in the solutions folder (such as bin, obj, *.suo, ...)
I just deleted the whole solution folder and reverted the files in git.
TLDR:
Try deleting user specific files/folders like bin, obj, *.suo, ...
Reboot your computer before trying any of these!
Some of these may be helpful. Doing the netstat trick
netstat -ano | find
helped me as another application was using my port, but didn't completely solve my problem. IIS Express still kept crashing. It wasn't until I rebooted my win 10 PC (first time in over a week), that my problem completely cleared up.
Head to the following directory
%userprofile%\documents\IISExpress\Config directory
Delete all files within that folder. Restart visual studio and works like a charm.
I had the same problem, and what needed to be done was setup IIS Express properly.
I right clicked on my project Properties => Web (tab) and on Servers:
Project URL was already pre-populated and I clicked the button "Create Virtual Directory".
I had just reinstalled (refreshed) windows and the IIS was not setup b/c it was new.
I came across the same problem and found that somehow the file 'applicationhost.config' (in ..\Documents\IISExpress\config) had a different localhost port number (in the 'sites' section) to the one specified in project\properties\web. Changed them to the same number and the problem went away
Close VS.
Navigate to the folder of the solution and delete the hidden .vs folder.
Restart VS.
Hit F5 and IIS Express should load as normal, allowing you to debug.
If this not working, then:
right click your solution and go to properties
Click left menu Web tag
Click checkbox "Override application root Url"
and run again your project.
For me this was the solution,
Close all running Visual studio instances
Open the solution folder and remove the .vs folder (hidden folder)
Open Run Command
Type iisreset and press Ok, and you may see a command prompt and
wait for it to complete and it will close automatically
Now Open visual studio and run your project, it should run.
So, nothing worked for me and this happened to happen to me when I got a new machine. Apparently it didn't have the older versions of .Net on it. Went into VS Installer and checked the box for .Net 5 Runtime (VS 2022). Working fine now on all .Net 5 Projects.
TL;DR: if you do have the right .NET Core (or .NET I guess) runtime installed, install any patch updates or reinstall the latest version if there aren't any.
Detail:
Similar to a couple of other answers where they just didn't have the right .NET core installed. I was trying to run a .NET Core 3.1 web app which had worked fine previously for months, and this suddenly started happening.
I did have 3.1 (runtimes 3.1.21 and 3.1.22) installed. However a new one (3.1.23) had been released 12 days earlier, and installing that fixed the problem.
I have no idea if this was because it's aware that there's a new patch and I didn't have it so it wouldn't run, or if there was just something wrong with my 3.1.22 installation. Worth trying installing latest patch, or reinstalling existing installations.
I encountered this while trying to run a project I'd run many times on a machine I'd used for the project many times. Cleaning up my IIS Express directory and my .vs directory didn't work, nor did setting environment variables. I even tried re-cloning my repository to a different folder, but no success.
By trying to run via command line, I found a more useful message:
dotnet run --project [startup project path]
I saw that the project was trying to run using .NET 6.0.5, but I only had .NET 6.0.4 installed. Installing the latest .NET 6.0.5 from the Microsoft website worked.
I also had the same problem, doing the above didn't work for me. What my error turned out to be was twofold.
I had Opera as my default browser and it couldn't attach to that.
I had multiple startup projects so it wouldn't let me switch to IE until I change the default startup project back to just the MVC shell.
I set that project specifically as the startup, then I switched it back to launching IE and it started debugging again.
What I did to make this go away:
Open C:\Users\gr_mext1\Documents\IISExpress\config\applicationhost.config and remove all <site> entries in <sites> do not remove <siteDefaults>!
In your project, go to Properties, Web and click "Create Virtual Directory".
Close and re-open visual studio, load your project and run
Fixed!
None of the listed solutions worked for me. Problem was some sort of conflicting state in local applicationhost.config file. Fix is easy, just delete one in your solution. For VS2015 it should be located in <path_to_your_solution>\Solution\.vs\config\. When you launch Debug, VS will recreate that file based on settings in your project file.
Deleting the hidden .vs folder didn't work for me since the port specified in my app was being used by another app. Doing the following worked for me:
Went to properties and then click the web tab.
Changed the port number in the Start Url and the Project URL.
Clicked Create Virtual Directory.
Save and Press F5.
cmd - regedit-HKEY_LOCAL_MACHINE-SYSTEM-CurrentControlSet-Services-HTTP-START=3
Computer restarted.
worked for me!
Tried most of the things here to no avail, but finally found a fix for my machine, so thought I'd share it:
Following previous advice in another question, I had used netsh to add :: to iplisten. It turns out undoing that was my solution, by simply replacing add in their advice:
netsh http delete iplisten ipaddress=::
You can also do this manually by deleting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\ListenOnlyList from the registry and restarting the service/your PC.
I update my Visual Studio to 2019 version and has this problem, I tried all solution from this question but it doesn't help to start my ASP.NET MVC 5 project with IIS Express. After I remove IIS Express (using Control Panel), download last version from www.microsoft.com and install it. After this everything works fine.
After some weeks i got update for Visual Studio and I got this problem again. I remove IIS Express and reinstall and it works fine now.
p.s. repair didn't help me, only uninstall and install.
I came back from MIX 11, installed the new MVC Tools update, and now my Visual Studio 2010 New Project dialog looks like this. This is a serious problem that I have been unable to resolve after a full remove & reinstall of VS 2010 Ultimate. System restores have been unable to resolve this issue either.
I've also tried running devenv /installvstemplates, nothing seems to work.
Also, when opening an existing project, the Add Library Package Reference command causes error "TYPE_E_CANTLOADLIBRARY".
This is a SERIOUS PROBLEM, please help!
I've been spending almost a day trying to fix exactly this issue on VS2010, running all existing devenv switches (from Resetsettings/ResetSkipPkgs/Safemode), repairing and reinstalling VS and SP1 and I finally caught it!
In short, my problem (and I guess yours too) relies in a registry ACL on HKEY_CLASSES_ROOT\TypeLib{91A74EB0-EFA0-482B-B43C-35CFC74B275F}, that is indeed "Microsoft Development Environment Properties 8.0".
If you add everyone on FullAccess to this registry key from an interactive regedit (use psexec.exe -i -s regedit.exe to start it elevated), everything restarts working back.
VS throws when it shows the new project dialog a TYPE_E_LIBNOTREGISTERED exception from EnvDTE80.DTE2.get_Properties() just after accessing to "Environment.ProjectsAndSolution", because it cannot then access to the environment.
I don't know how those ACLs got screwed up, but I hope this can help someone to avoid spending hours on it and beeing stuck reading posts saying "your (BUILD) machine has a serious problem"...
HTH
In your %temp% folder, there should be a file called MVCVS2010Templates.log, or something similar.
It contains the result of running devenv /setup and will show whether VS decided to remove packages or encountered problems when registering project/item templates. We create this file during our install.
If a re-install of VS still has this problem, then there's probably a bigger problem with the machine.
You could try running devenv /resetskippkgs and see if that makes things better. It almost looks like VS disabled everything
Jacques
In some esoteric cases, the key {91A74EB0-EFA0-482B-B43C-35CFC74B275F} cannot be deleted by permissions issues even when running regedit with administrator permissions.
In these cases do the following:
Use the utility tool RunAsSystem
https://www.raymond.cc/blog/full-control-permission-to-delete-or-edit-restricted-windows-registry/
Delete the key {91A74EB0-EFA0-482B-B43C-35CFC74B275F}
Yes, I know... I could set up a virtual machine running XP. Unfortunately our build environment is such that we need to be running VC2003, 2005 and 2008 concurrently and it would be much more convenient if I could run 2003 natively on Windows 7 for the few projects we have that require it.
I realize some things may not be available in the IDE, but I was able to run 2003 under windows Vista and if I could get the same base level of functionality under Windows 7 I would be extremely happy.
Right now I get an error opening the *.pdb file when I compile after switching vc2003 to run as Administrator under compatibility mode for XP SP 2.
Thanks!
Give XP Mode a try if you can't get it to run natively.
http://www.microsoft.com/windows/virtual-pc/download.aspx
I wrote a blog entry about this a while back that you can check out - http://technikhil.wordpress.com/2010/01/12/visual-studio-2003-and-windows-7-can-get-along-really/
The only thing I am stuck on right now is the global search functionality of VS 2003 - it hangs the application. My workaround is to use windows 7 search :-). Other than that - so far so good...
Update: I got the search to work as well by disabling the Aero functionality - I have updated my blog post with the details...
(Much of this repeats what's already been written above.)
I need to run VS2003 as adminstrator under Win7 64-bit, to support legacy projects (e.g. those that run on the original Xbox). The old XDK requires VS2003, so upgrading is not an option. I could run WinXP but I prefer Win7.
VS2003 is not officially supported under Win7 and trying to do so creates a couple of fairly annoying problems:
Find-in-files causes VS2003 to hang.
Linking fails due to a PDB file handle leak.
The Find-in-files hang is solved by using "Disable visual themes". Navigate to the VS2003 shortcut (Start-->Microsoft Visual Studio .NET 2003), right-click to get context menu, select Compatibility tab, Settings pane, and check "Disable visual themes".
The linker failure (LNK1201) happens when you run the program through the debugger, stop it, modify a file and build. The error is that a Visual Studio hold a handle to the PDB file, while the linker tries to write to that file. You can stop and restart VS2003 to bypass the issue. Works but is annoying.
You can also use the Microsoft SysInternals "handle.exe" utility to find, then close handles held by a process on a particular file. Write a script to call handle.exe and set up the VS2003 project to run that script as a Pre-Build Event. (See this thread.) But handle.exe requires running as admin.
You could hypothetically change handle.exe to run as admin using the usual steps (e.g. as a compatibility setting) but then handle.exe (apparently) runs in a nested shell, and then the stdout text does not get to the calling script.
You can make VS2003 run as admin, in which case the Pre-Build script also runs as admin, hence does handle.exe, and that works.
The remaining trick is to get VS2003 SLN files to open properly. If you simply make VS2003 run as admin automatically then the VS version selector fails to run VS2003. I don't know why, but it is the case.
You could associate SLN files to open using VS2003 devenv.exe instead of VSLauncher.exe. That works but then all new SLN files (2005, 2008, 2010, 2012, ...) fail to open.
So the final step then is to make VSLauncher.exe run as admin. This fails as of KB2492386 as this thread indicates. Uninstalling that update was the final step in this saga, to get everything to work.
PATCH NOW AVAILABLE
After some reverse-engineering, I found the incorrectly refcounted COM object responsible for the leak (it was off by 1) and developed a stable patch and corresponding article describing the fix. This addresses problems encountered while using Windows 7 thru Windows 10. Details and download available at:
http://bytepointer.com/articles/vs7.1_2003_on_win7_pdb_handle_leak_bug_unofficial_fix.htm
If you want to perform the patch manually, those details are also included.
NOTE: The SysInternals Handle tool workaround did not work for files on a network-share. The .PDB was not completely unlocked although the Handle tool claimed it was closed. My fix eliminates the problem once and for all and avoids any side effects.
Run this install. You need to run it from the setup directory, the setup.exe on the root of the cd will not work.
D:\setup\SetUp.exe /NO_BSLN_CHECK
Solution i found on the web which helped: For your visual studio, use application compatibility = windows vista SP2, and NOT WinXP SP3
I have a really dirty and pathetic workaround for the pdb problem.
Download and run Sysinternals-ProceXP, press CTRL-F enter the name of pdb(smt like ($ProjectName).pdb) that can't be created while linking. Double click when it is found.(if it can't be found run procexp with administrator priviliges)
Then you will see that the .pdb file is highlighted in the lower pane of the main screen. Right click it and select Close Handle. When you retry building your solution it wont raise an error.
I dont know if this solution can be scripted but it is at least better than restarting visual studio.
I've been using Visual studio 2003 on win7 since the very first RC edition was released :S
why do people have issues?
I have attempted to install VS2003 on Windows 7 64-bit using the Virtual Windows XP feature. I'm reasonably certain that this will be successful. The issue I ran into is that the installer wants IIS installed, and the XP installation provided by the Virtual XP doesn't have that enabled by default.
If you go to Add/Remove components, and try to add it, it will ask for the disc, which I didn't have on hand. Once I get my hands on the disc, I'm pretty sure that it will run fine.
If you haven't tried it for other apps, the Virtual XP feature is really neat...
I am experiencing the same issue; devenv.exe is leaving pdb files open after running the project. I have made a batch file to work around it, it closes all .pdb files open by devenv.exe:
handle.exe .pdb | awk "/devenv.exe/ { split($4, fd, \":\"); system(\"handle.exe -c \" fd[1] \" -y -p \" $3)}"
You will need to have handle.exe by sysinternals and awk by gnu in your path to make it work.
Use at your own risk. Closing handles can cause application or system instability.
In windows 7, there is the compatabiliy mode in the executable properties.
open:C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\
then right click on the devenv.exe and select properties. In the compatability tab, select the "Run in compatability mode" and select "Windows XP" in the dropdown.
Try that, I am not sure if it works, but it is worth a shot.
I am having no problems with Visual Studio 2003 on Windows 7 64-bit.
Navigate to VS2003 devenv.exe (probably C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe)
Right-click and select Properties
In the Compatibility tab, check "Run this program in compatibility mode for:" and select "Windows XP (Service Pack 3)"
Check "Run this program as administrator"
I got Visual Studio .NET 2003 Working just fine on my HP EliteBook Workstation 8760W with an I7 processor and 12GB of RAM running Windows 7 Professional 64 bit by doing some advanced steps.
They go as follows:
Install FrontPage 2002 Server Extensions for IIS 7.0.
Install Visual Studio .Net 2003. Just skip when the installer command you to configure Frontpage 2002 Server Extensions.
Install .Net Framework 1.1 Service Pack 1 (download here).
Go to Control Panel > Administrative Tools > Internet Information Services (IIS) Manager. Highlight your machine, then double-click on ISAPI and CGI Restrictions. Change setting for ASP .NET v1.1.4322 to Allowed.
Then it will always show an alert with the following message
This program has compatibility issues...
just ignore that. Also, don't put it in compatibility mode in the properties of the IDE.
I did managed to install VS2003 on Windows 7 32 bit. However I had to do some IIS tricks in order to be able to run my ASP.NET project. When you install VS2003 Web Development component can't be selected. Basically you have to drop your VS2003 ASP.NET v1.1 into C:\inetpub\wwwroot\project_name and make it working on it's own as a standalone web portal first. Here is the steps I did.
Install IIS on Windows 7
Copy your VS2003 project to C:\inetpub\wwwroot\project_name. Right click on your project_name and Convert to application.
Following was my custom issue that didn't work until I enabled Windows Authentication even if I had no related settings in my web.config. Select your project_name > Authentication > enable both Anonymous and Windows Authentications.
Enable ASP.NET 1.1 in ISAPI and CGI Restrictions and make sure ASP.NET is added under ISAPI filters
Once I'm able to fire up my ASP.NET project in a browser go ahead and open project from your project location in my case is C:\inetpub\wwwroot\MHSScoreOrg\MHSScoreOrg.sln. I was able to run my project only when it was fully integrated on IIS.
I'm sorry, your build environment requires you to have VC 2003, 2005, AND 2008 running concurrently? I would really bet that your efforts would be better spent simply consolidating your build environment to just one environment.
Have you considered upgrading your solutions to vs2005, using MSBEE to target .net 1.1?