I use Git Bash (CLI) for all Git related tasks. Git can of course only recognize changes in files if Visual Studio saved them, which it does not automatically. I am used from IDEA that I do not have to take care of this.
I often Alt+Tab to Git Bash after having changed multiple source files and then realize I need to save first, so I go back to VS and Ctrl+Shift+S and switch to Git Bash again.
How can I make Visual Studio 2017 save all opened files continuously?
I looked through the options but did not find anything.
I also use Resharper, in case it can do this.
Related
Our group has some simple regression machines that build different C++ code bases regularly, and they all use different versions of the Visual Studio build tools. Rather than try to install a lot of different versions of Visual Studio on the build systems, the tools are copied to a standard mounted location and used from there.
Now, the team that set this system up uses a custom build system rather than MSBuild, but I am trying to use these machines with MSBuild (which is also copied to the mounted location) to build an existing VS solution file. Does anyone know how to modify a vcvars batch file enough so that these tools being in an alternate locations will work properly without having to install anything to the build node?
Not sure what point you want to describe. And as far as I know, you can just download the msbuild open source code and then basically add your custom build tool to the msbuild code.
In this way, the generated new msbuild tool is perfectly embedded with your custom tool. This is the best solution.
Simply changing the vcvars*.bat and other related files on the msbuild folder of vs2019 is not helpful. You must start at the stage of msbuild development.
And thanks for Microsoft to open up the source code of msbuild, in fact, this is to facilitate users to embed custom tools.
I wiped out an old Windows 10 and replaced it with a new Windows 10 by ISO image.
Before wiping out, I copied the folder of Microsoft Visual Studio 2017 Community Edition on old Windows to an external hard disk:
xcopy /E "C:\Program Files (x86)\Microsoft Visual Studio" D:\
Now after reinstalling Windows 10, I copied the VS 2017 folder from external the hard disk to the C:\Program Files (x86)\ folder of new operating system.
I did so to avoid having to download VS 2017 again on new OS.
The problem is other software, like Qt Creator, cannot auto-detect the VS C/C++ compilers. I guess that's because the VS 2017 isn't added to path.
The questions are:
What path should I add to system path in order to VS 2017 to be auto-detected by other software like Qt Creator?
Is there any script which I can run to automatically integrate the VS 2017 to the rest of the operating system.
To answer the questions in your issue:
Copying the content of C:\Program Files (x86)\Microsoft Visual Studio folder is not a recommended way to install VS.
(The complete installation will not only set the Environment variables but also set the related registry keys and values. A simple copy may break this process)
So we always suggest that users install the VS by vs-installer or offline installation package. (Same like what Zlatomir suggests.)
To your actual requirements:
It seems you're just trying to use VC++ compiler in QT Creator instead of developing QT projects in Visual Studio. So build tools for VS package is enough for you.
See this related issue, if we download Build Tools for VS package with corresponding C++ workload, then we can get the compiler the QT needs. There's no need to install the VS IDE for this situation.
And if we need C++ compiler from VS2017, download the Build Tools for VS2017, if we need C++ compiler from VS2015, download the Build Tools for VS2015 Update3. Link of old version about VS Tools see here.
Update:
From the the link older downloads we can see:
Choose the download button according to which version we need. We can find both VS2017 build tools package and VS2015's there.
Usually programs on Windows don't work after you just copy the installation folder.
So right now there is little you can do to fix it, even if you partially fix, you have no way to know if something else will be broken in the future.
So the recommended solution is to download the installer again and create an offline installer for the next time this happens, you can do that by running the online installer with the following parameters: vs_community.exe --layout c:\vslayout --lang en-US (replace vs_community.exe with the actual name of the online installer file, or rename it), for more options, that might require a smaller download (example if you only need native and don't need .net) check the documentation here for the full set of options you have.
I've recently been busy working on making proper build scripts for a code library I've been designing, and have been stuck on getting MSBuild to properly compile for my Windows builds. What I'm trying to do is call MSBuild from a batch script without it opening the Visual Studio IDE, which it appears to constantly do if I'm not executing it from the Developer Command Prompt for Visual Studio. My script is simple enough, just calling
start C:\Program Files (x86)\...\MSBuild\15.0\Bin\MSBuild.exe <Project>.sln
Besides a few other specifiers tagged onto the end of it, that's what I'm trying to use to run my Windows builds. The issue here is that whenever this code is called outside of the VS Dev Prompt, Visual Studio itself opens, not building the code at all. I couldn't find anyone else struggling with this same issue either, as it seems to be new to the integration of MSBuild and Visual Studio. Testing with older versions of MSBuild went to show that I could build projects as I wanted to outside of the Dev Prompt. Could I be missing some environment variable supplied in the Dev Prompt that changes the executable behavior? I couldn't seem to find any executable specifiers that would change this, either.
Maybe I'm taking a completely wrong approach to this problem? My end goal is to provide consumers with a collection of build scripts, one for each platform they're targeting, so I am definitely open to other solutions.
The canonical answer:
You can use the devenv command with the /build command line option and the name of your project file.
Alternatively, you can run one of the vcvars*.bat scripts to set up the necessary environment and then use msbuild.
For more info, see https://learn.microsoft.com/en-gb/cpp/build/building-on-the-command-line.
Update: Contrary to the official advice above, this is what works on my laptop with VS2017 community edition.
Setup the environment by running the bat file that is targeted by the "developer command prompt for VS2017". (Right-click on that in the start menu, then select "Open file location" then right-click on the shortcut and select "properties". For me that is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat".
You should call this file from your build script.
cd to your project directory and then use msbuild like this:
msbuild My-project.vcxproj /p:Configuration=Release
For some really strange reason I can use the devenv method if I open the official developer command prompt but launching devenv from another command prompt even with the environment variables set does nothing. (And I even compared the set of environment variables in both command prompts and they are equal.)
How to Run MSBuild Outside of the MSVS Dev Prompt?
If the necessary environment not be set correct, then the build command becomes " mysolution.sln". And executing it indeed starts VS. So you should run the vcvars*.bat scripts to set up the necessary environment and then use msbuild. Following is my a batch script, it has been working for some time, you can check it:
#echo OFF
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
echo "Starting Build for all Projects with proposed changes"
MSBuild.exe "C:\Users\Admin\Source\repos\MyTestProject\MyTestProject.sln"
pause
echo "All builds completed."
Here is the test sample result:
See How to create a Simple Build Script for Visual Studio from the Command Line? for more details.
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.
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.