I am working on some very old software that uses Visual Studio 6, Visual Studio .net and Visual Studio 2010. So I ended up having to install various versions of studio from 6 all the way to 2017. At some point something got messed up and I ended up uninstalling and reinstalling a whole bunch of things. Everything else works now, but Visual Studio 2015 is toast. I uninstalled anything related to 2015, then reinstalled it. Same problem. Uninstalled it again, hoping the uninstaller would correctly remove stuff, reinstall, again no go.
So, when I open VS, the log in button on the top right does nothing. If I try to create a test C++ project, it just closes the screen where you enter the project details and then reopens it, no joy there. If I open a solution with C++ projects in it is says it does not know how to load the project file of that type.
If I build the project in VS 2017 and leave the projects as VS 2015, I get a linker error "LINK : fatal error LNK1104: cannot open file 'mfc140d.lib'", so something mostly likely did not install properly.
After clicking on the log in button, the other menu's will highlight when you click on then, but no menu's.
The ActivityLog.xml contains stuff like this:
<entry>
<record>366</record>
<time>2017/08/08 14:18:48.820</time>
<type>Error</type>
<source>Extension Manager</source>
<description>Error loading extension: This VSIX does not apply to any product installed on this machine. The problem could be that the VSIX manifest's format is not recognized, or that the manifest has been corrupted. Data at the root level is invalid. Line 1, position 1. </description>
<path>C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\EXTENSIONS\MICROSOFT\VSGRAPHICS\</path>
</entry>
<entry>
<record>367</record>
<time>2017/08/08 14:18:49.123</time>
<type>Error</type>
<source>Extension Manager</source>
<description>Extension will not be loaded because an extension with the same ID 'Microsoft.Windows.DevelopmentKit.Desktop' is already loaded at C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGER\EXTENSIONS\MICROSOFT\WINDOWS KITS\10\DESKTOP SDK\...</description>
<path>C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGER\EXTENSIONS\MICROSOFT\WINDOWS KITS\8.1\DESKTOP SDK\</path>
</entry>
<entry>
<record>368</record>
<time>2017/08/08 14:18:49.123</time>
<type>Error</type>
<source>Extension Manager</source>
<description>Extension will not be loaded because an extension with the same ID 'Microsoft.Windows.DevelopmentKit.WindowsStore' is already loaded at C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGER\EXTENSIONS\MICROSOFT\WINDOWS KITS\10\WINDOWS STORE SDK\...</description>
<path>C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGER\EXTENSIONS\MICROSOFT\WINDOWS KITS\8.1\WINDOWS STORE SDK\</path>
</entry>
I am guessing I might have to uninstall VS 2015 and then manually clean up any remnants? Any suggestions? I really don't want to rebuild this machine.
Thanks.
I know it isn't a helpful answer, but the error messages suggest your registry etc. is beyond repair. The fastest and safest way to clean up is formatting the disks and reinstalling Windows from scratch.
For your next attempt to use Visual Studio I strongly recommend virtual machines, one for each VS version.
Related
I guess, this happened after recent update to Visual Studio 15.8.0 yesterday. Although I'm not 100% sure that this update caused it. When I try to load resource or open already created .rc file this happens:
Error message
ActivityLog.xml says this:
<entry>
<record>533</record>
<time>2018/08/15 18:01:53.704</time>
<type>Error</type>
<source>VisualStudio</source>
<description>No InprocServer32 registered for package [Visual C++ Resource Editor Package]</description>
<guid>{74AAD8B2-3294-49CB-BB5D-E9BAB132BFD5}</guid>
<hr>8007007f</hr>
<errorinfo></errorinfo>
<path>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\vcpackages\resedit.dll</path>
</entry>
What I tried to do to fix this:
All fixes from this question
Repairing Visual Studio from VS Installer
Removing and reinstalling VS from scratch
Nothing works. What could it be and how to fix this? It's not critical, because I still can open resource.rc, resource.h and manually add resources - it compiles fine. But still rather inconvenient.
This issue with resedit.dll is fixed in MSVS2017 15.8.2.
Release notes: https://learn.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#15.8.2
Bug report: https://developercommunity.visualstudio.com/content/problem/311385/visual-c-resource-editor-package-load-failed.html).
We had the same Problem in our Company. The update works on Windows10 but Windows 7 Systems aren't able to open the resource editor.
Our "dirty" solution was to copy the resedit.dll from an older Visual Studio Version onto the new one.
Hopfully Microsoft brings a bugfixed version soon
Wanted to add this question to the pool in case someone has the same problem
I was unable to update Visual Studio 2017 on Windows 7 and got the following error:
Unable to install the files to target location. Error: The folder
'c:\Program Files (x86)\Microsoft Visual Studio\Installer' or a file
within it is locked by another program. Close any applications that
might be using it and try again.
The initial solution I found was to reinstall Visual Studio but felt that it might be unnecessary. The solution I found was to close down visual studio, go to "c:\Program Files (x86)\Microsoft Visual Studio\Installer", rename the folder "Installer" to something else then run vs_installer.exe from the renamed folder.
Hope that help someone.
I just recently encountered the same error while trying to update the Visual Studio 2017 installer on Windows 10. In my case, the c:\Program Files (x86)\Microsoft Visual Studio\Installer directory was locked because of virus/malware scanning software running in the background. After stopping that, the installation of the VS 2017 installer had no more problems.
What initially misled me about the source of the problem was that the process which had a lock on the files in that directory was the special System process in Process Explorer, so I was initially going down the wrong rabbit hole.
If you have malwarebytes then you can add to the allow list C:\Program Files(x86)\Microsoft Visual Studio and it will work.
I got it working by downloading the installer separately, rebooting, and running the installer directly.
VS Installer Downloads
I encountered this when trying to update VS2019. I could not rename the Installer folder. Rebooting didn't help. I tried uninstalling everything related to Visual Studio via Control Panel, but the uninstall failed. It removed everything except a subfolder containing VSIXAutoUpdate.exe and some dlls. The installer still would not run.
This final step allowed me to delete the Installer folder and do a fresh install of Visual Studio.
Open Task Manager > Processes Tab
End Process "VSIXAutoUpdate"
Delete folder "C:\Program Files (x86)\Microsoft Visual Studio\Installer"
TL;DR
Stop the Task Scheduler service and ensure no open handles for the C:\Program Files (x86)\Microsoft Visual Studio\Installer dir
Details
I just had the same problem, and even rebooting didn't help. So, I dug in!
Process Hacker revealed there was a lock on the following file by the System process:
C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\VSIXConfigurationUpdater.exe.
If I used Process Hacker to close the handle, it just immediately reopened again :/
I thought to check Task Scheduler (since it runs as SYSTEM in svchost), and sure enough there were tasks in there that run VSIXConfigurationUpdater.exe, even though they weren't actually running at that time.
So I stopped the Task Scheduler service, then used Process Hacker to close the handle on VSIXConfigurationUpdater.exe - and this time it didn't return! After ensuring there were no open handles on anything inC:\Program Files (x86)\Microsoft Visual Studio\Installer, the Visual Studio installer was able to update.
I found the culprit for me was Malwarebytes disabled this and all worked well. Hope this helps somebody.
I tried to run through the steps #Janspeed specified, but there were a couple of language folders in the resources directory that were corrupted/locked, so just renaming wouldn't work. I managed to copy most of the file/dir structure (minus the corrupted ones) to a new directory but had to run a chkdsk /f on a restart before I could get those folders freed up and deleted. Once I had this worked out, #Janspeed's steps worked fine, including just deleting the new directory that I had copied everything into.
I ran into this issue today, turns out it was MalwareBytes Endpoint Protection that was blocking the update which is rather annoying.
Luckily I'm the admin and developer so I was able to drop my laptop from the antivirus to enable the update and then re-add it but in a larger corporate environment with red tape this isn't great at all.
I had faced the same issue while updating Visual Studio 2017 and 2019. I tried to open the Visual Studio Installer directly as admin and then it worked as expecred.
Update kept failing when using the "Check for Updates" menu item in the VS2019 IDE. When I ran the Visual Studio Installer from the Windows Start bar it immediately prompted to download the latest version of the installer. Once that was done it then offered to update VS2019.
I am swapping machines (between two Windows 8.1 laptops) and have just loaded the project I'm working on from TFS. On one machine it compiles, on the other it does not and gives the first error
error C1083: Cannot open include file: 'atlbase.h': No such file or directory
On both laptops I am running Visual Studio Ultimate 2013. On the first laptop I've checked to see where it is picking up atlbase.h and it is from C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\include i.e. from the Visual Studio 2012 installation directory. On the new machine I do not have Visual Studio 2012 installed so the directory C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\include does not exist.
Other people have similar problems (e.g. Ramilol's question) because they are using Visual Studio Express. I am using Ultimate.
It could be an environment variables problem (as suggested by raj raj) but my include directory paths under VC++ Directories are $(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSDK_IncludePath) as required.
My general question is "how do I fix this?" but I'd also be interested to know how I check and set the value of $(VCInstallDir) since C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include does have atlbase.h in (so I am flummoxed as to why it is not picked up).
========== EDIT 1: Rewording ==========
Let me have another go at wording this question.
I have loaded a Visual Studio 2013 project onto a new build laptop from TFS. It will not build and gives errors like error C1083: Cannot open include file: 'atlbase.h': No such file or directory. The file atlbase.h is present on the new machine, in the directory C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include.
In my project's properties my include directory paths under VC++ Directories are $(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSDK_IncludePath)
How do I check what those macros are set to, and if they are not where atlbase.h is (i.e. C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include) how do I fix that?
========== EDIT 2: Microsoft Visual C++ Redistributables installed ==========
Responding to jp2code's answer the machine that works and the one that does not have a similar array of Microsoft Visual C++ Redistributables installed as the following screenshot shows (the working machine's on the left):
========== EDIT 3: Environment variables ==========
In his answer, pje explains how to look up the environment variables. %VCInstallDir% is correctly set to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\ But if I right click on the line #include <atlbase.h> I get this error which suggests that despite %VCInstallDir% being correct, that is not where VS is looking:
========== EDIT 4: Platform toolkit setting ==========
Another possibility is the Configuration Properties | General | Platform Toolset project setting, suggested by manuell in the comments and Michael Burr in his answer. For the project it is set to set to Visual Studio 2012 (v110) but the only other option listed in the drop-down is v110_wp80, which, when selected, becomes Windows Phone 8.0 (v110). If I hand edit the .vcxproj file in notepad and reopening the project in Visual Studio Ultimate 2013 the property page now lists the Platform Toolset as Visual Studio 2013 (v120) (not installed).
If I start a new C++ Windows Store project I can set Platform Toolset to Visual Studio 2013 (v120) without issue, in fact it is the only option listed in the drop-down. (N.B. The new project has Target Platform Version set to 'Windows 8.1', and it is greyed out, so I cannot change it, while the failing project has it set to Windows 8.)
========== EDIT 5: Entire project settings file ==========
In the comments Michael suggests that "maybe posting the .vcxproj somewhere (like as a gist on github) might be helpful". I have posted it here.
========== EDIT 6: Uninstalling and reinstalling Visual Studio 2013 Ultimate ==========
Has no effect, the same error recurs.
On the new machine I do not have Visual Studio 2012 installed
Well, look no further, that's your problem. Your project targets the VS2012 toolset to build a Store project that runs on Windows 8.0. You can still open it in VS2013 but it can only be built if you have VS2012 installed as well. In other words, you must have the v110 toolset available on the machine. You don't.
Short from installing VS2012, you will have to re-target to 8.1 to get it to build with the VS2013 toolset (v120). Right-click the Solution node in the Solution Explorer window and select "Retarget Windows Store projects to Windows 8.1".
Do fret a bit about that laptop, it remembers too much about VS2012. Sounds like it had it once installed but it wasn't uninstalled properly.
If you want to see the value of $(VCInstallDir) or any other Visual Studio macro, then open the Developer Command Prompt for VS2013 (this should have installed with your VS 2013 install). In the prompt type: echo %VCInstallDir%. This will print the current value of the $(VCInstallDir) macro. If you want to change this to a different directory, then type set VCInstallDir=<directory path>, where <directory path> is the path to your desired directory (presumably C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include in your case).
Hope this helps, cheers!
------edit-------
As a side note, it is possible that these macros were imported with the 2012 project that you were trying to load and compile with 2013. If it turns out that it was your $(VCInstallDir) macro that was wrong, then that would explain why.
Check that the "Configuration Properties | General | Platform Toolset" project setting is:
Visual Studio 2013 (v12)
and not something like "Visual Studio 2012 (v110)
Possible solution
Get Process Monitor
Filter for atlbase.h
this way you will know exactly where Visual Studio is looking for atlbase.h. Process monitor will show you the failed file-open attempts.
At this point you will be able to solve the problem by
make symbolic links (messy)
fix the include directory paths (better)
Update
Here is how you filter for file operations:
Don't forget to click Add after setting the filter parameters.
Check to see that both machines have the same versions of C++ Redistributable installed.
It is worth a shot, and will be easy to check.
The question pretty much tells it all.
Continoustests comes as a windows installer (http://continuoustests.com/download.html), so the trick described here doesn't work.
I tried the following:
Install Mighty Moose
copy the C:\Program Files (x86)\ContinuousTests\AutoTest.VS.2012.Addin to C:\Program Files (x86)\ContinuousTests\AutoTest.VS.2013.Addin
Edit the 2013 file and update the version numbers from 11.0 to 12.0
Alternatively: drop the following file: AutoTest.VS.2013.Addin in your MightyMoose installation folder.
In Visual Studio open the Tools - Options - Environment - Add-in Security page and add C:\Program Files (x86)\ContinuousTests to the list of trusted add-in paths.
Restart Visual Studio
This seems to do the trick for me. Not sure if there are any issues with this, as I haven't played around with it too much. I had Visual Studio 2010, 2012 and 2013 installed side-by-side, so I didn't have to trick the installer into believing that there is a suitable version of Visual Studio anywhere.
Then
Follow the steps in the next answer below :)
#jessehouwing's answer is on the mark! But, there's one problem left unresolved: the code coverage margin of Mighty Moose still won't appear. So, in addition to following #jessehouwing's suggestion above, you must also do the following in order for the code coverage margin and the various test call graph overlays to work.
Go to the Visual Studio 2013 installation folder. By default, this is %ProgramFilesx86%\Microsoft Visual Studio 12.0.
Within that folder, navigate to \Common7\IDE\Extensions.
Create a new folder called Continuous Tests (yes, it does have a space in its name).
Choose one of two paths below:
If you have a previous version of Visual Studio installed:
Navigate to %ProgramFilesx86\Microsoft Visual Studio x.0\Common7\IDE\Extensions\Continuous Tests, where x.0 is the previous version of Visual Studio, e.g. 2008 - 2012.
Copy the extension.vsixmanifest file from the current directory to the directory created in step 3 above.
If you don't have a previous version of Visual Studio installed:
Go to the installation directory for Mighty Moose, by default %ProgramFilesx86%\ContinuousTests, and copy the extension.vsixmanifest file to the directory created in step 3 above.
Start notepad as an administrator.
Open the copied extension.vsixmanifest file.
Add the text indicate below into the extension.vsixmanifest file after the included text shown (you don't need to add the comment), and save the file:
<SupportedProducts>
<VisualStudio Version="11.0">
<Edition>Ultimate</Edition>
<Edition>Premium</Edition>
<Edition>Pro</Edition>
</VisualStudio>
<!-- ADD THE TEXT BELOW TO ENABLE VISUAL STUDIO 2013 SUPPORT -->
<VisualStudio Version="12.0">
<Edition>Ultimate</Edition>
<Edition>Premium</Edition>
<Edition>Pro</Edition>
</VisualStudio>
</SupportedProducts>
If you copied the extension.vsixmanifest file from the Extensions directory of a previous version of Visual Studio, you are finished. Otherwise, continue on to step 9.
Find the following text within the extension.vsixmanifest file:
<Content>
<MefComponent>|%CurrentProject%|</MefComponent>
</Content>
Change |%CurrentProject%| to the following:
%Mighty_Moose_Install_Path%\AutoTest.VS.RiskClassifier.dll
where %Mighty_Moose_Install_Path%, by default, is %ProgramFilesx86%\ContinuousTests. (Use the actual path, not the expansion macro!)
Save the file.
If you have Visual Studio 2013 open, restart Visual Studio for the changes to take effect. If you want to verify that the extension is installed, go to Tools|Extension and Updates... and search for Mighty Moose in the list of extensions.
Hope that helps save someone a few hours worth of time trying to figure this out.
If you are installing on a fresh machine with no previous versions of visual studio installed there are a few extra steps to get it working. Here are the full steps:
Follow the answer from #jessehouwing
Put msbuild in the 2012 location by copying the file Microsoft.Build.Tasks.v12.0.dll from C:\Program Files (x86)\MSBuild\12.0\Bin to C:\Windows\Microsoft.NET\Framework\v4.0.30319
Follow the answer from #fourpastmidnight
Reboot
Install another visual studio extension of your choice from "Extensions and Updates" inside visual studio 2013 (I tested with Code Maid but I suspect any extension will provide the required kick)
Restart Visual Studio. Mighty Moose wakes up and the code coverage icons appear.
It is now safe to uninstall the extension you added in step 5 if you don't want it.
I'm trying to compile a visual studio C++ project and I can't get anywhere because of the compiler reporting "Cannot open include file: 'excpt.h': No such file or directory". The problem has been reported numerous times on the Internet but I can't find any help regarding my particular situation. The problem is not that the include path of the project are not correctly setup, the problem is that this include file (and probably a bunch of other files) are just missing from my computer. There is no such file on my hard drive. So I tried installing Windows SDK 7.1. The file is not inside the installed SDK (although it should be). I tried repairing the install, uninstall it, reinstall it... all numerous time. I also try to install, repair, uninstall, reinstall Visual Studio 2010 professional numerous time, with and without the Windows SDK installed. I even tried uninstalling the professional version to install the express VC++... nothing seems to work, no 'excpt.h' never get installed on my computer. I am clueless... someone has a hint of a solution? I'm on Windows 7.
As supplementary information, note that 'excpt.h' is included in by "windows.h". Also, the "excpt.h" file is normally installed with the Windows SDK under a path like "c:\program files (x86)\microsoft sdks\windows\v7.1\include\" and with Visual Studio under a path like "C:\Program Files\Microsoft Visual Studio 10.0\VC\include\".
EDIT: If it might help, I might add that the folder C:\Program Files\Microsoft Visual Studio 10.0\VC\include related my Visual Studio install has only two files... which is certainly not normal!!! However, I can't find any ways to get the installer to install all the .h files that should appear in this repertory.
See if you have it at C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\excpt.h Check to be sure that the system include-paths are correct in Visual Studio. If all else fails, uninstall everything, all SDK's, etc., and re-install Visual C++.
Third party search programs do a better job than the Windows one for finding things. Try Agent Ransack. It's free.
For those who have the same problem, here is the solution I found after about 10h of install/uninstall/cleaning cycles... I've uninstalled completely visual studio using this. After that, using the control panel, I've uninstalled the Windows SDK and everything that can be associated with it or with visual studio (e.g. .NET framework). Then, I've removed all the left overs by manually deleting the visual studio and the Windows SDK folders located in C:/Program files. Finally, I deleted all the entries related to the Windows SDK or to Visual Studio in the registry (they are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft). Then, I reinstalled Visual Studio... and it was finally working correctly. I should add that I restarted and cleaned the registry using CCleaner after any install or uninstall step.
I had this problem with a project that had been updated to VS2017 from VS2015.
This was a header included via windows.h. I knew this header should have no problems as I had other projects created directly in VS2017 that used windows.h.
Another symptom was that the intellisense was highlighting includes of standard headers (e.g string, vector etc), although these were not generating compile errors.
The fix for me was similar to VS 2010 Cannot open source file “string”.
Initially, I retargeted the project, hoping this would help (right-click the project, select retarget projects), but this did not in itself cure the problem.
I then took a working project and copied the include directories from project properties->Configuration Properties->VC++ Directories and used these to replace the same property for my broken project. This fixed the problem.
Initially, the value for this property was
$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSDK_IncludePath);
The replacement value was
$(VC_IncludePath);$(WindowsSDK_IncludePath);
I had the same problem, and tried the answer given by OP, but it did not work. However, copying the contents of C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC (specifically bin, lib, and include) from a machine that did work to this machine worked.
It seems the Visual Studio 2012 installer is buggy when it comes to installing into a different drive letter than C:. I have installed the VS2012 into the D: drive and got the same error. I found that for some unknown reason the installer put some of the files into the correct location at:
D:\Program Files (x86)\Microsoft Visual Studio 11.0
but the remaining files were at
C:\Program Files (x86)\Microsoft Visual Studio 11.0
so I have moved the files from the C: into the D: location and it fixed the problem.
Some situation cause such problem. If you have uninstalled vs2010. you lost platform C++ binaries for .net framework 4 forever. You have to delete all of VS 2010 2012 2013, clean system up and its accompany components and reinstall them from scratch.
Or you can download this package. Include them in your project that may solve your problem properly.
one simeple way,just copy vc directory(C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC) from other computer
Fixing your Visual Studio installation is a good idea, but you don't necessarily need to re-install the same old version of VS. I uninstalled VS 2015, then modified my VS 2017 installation to add the VC++ v140 build tools, and now my project builds.