Previously on my Visual Studio 2017, I had the file vcvarsall.bat located at this location - "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
But later my office installed Visual Studio 2019 and I dont see vcvarsall.bat file anywhere.
Can anyone advise how to get the file, I did read some forums but could not find any solution.
Please advise.
Thanks.
You can find the vcvarsall.bat file for VS2019 at:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Your VS Edition\VC\Auxiliary\Build\vcvarsall.bat
And one point we should know, this file is under VC folder. So it's part of C++ workload. If you can't find the file in the location above, please make sure you've installed the C++ related workload. (In VS, go Tools menu=>Get Tools and Features=>Install the Desktop Development With C++ workload)
In addition: The path you mentioned above refers to the vcvarsall.bat for VS2015. The vcvarsall.bat for VS2017 should be under C:\Program Files (x86)\Microsoft Visual Studio\2017\... directory. VS2015=>vs version 14.0 while VS2017=>15.0.
Got this error:
Error: Program "ndk-build" not found in PATH
PATH=[C:\Android\AndroidNDK\android-ndk-r9-windows-x86-legacy-toolchains\android-ndk-r9;C:\Program Files\Common Files\Microsoft Shared\Windows Live;...]
I have tried to set path to download the "bigger" package, but my eclipse can't recognize that. Any one know how to help me out? I have updated eclipse and the SDK for Android Tools
ndk-build should be in the root of the NDK, from your path above Add C:\Android\AndroidNDK and it should find it.
Try using ndk-build.cmd instead of just ndk-build.
I'm writing a game in TypeScript and just upgraded to TS 0.8.2 and now VS 2012 web express complains with an error like this:
The system cannot find the path specified.
game -> C:\Users\me\pr\game.dll
I can confirm that this file exists on the file system
The most likely file it cannot find is actually...
c:\Program Files\Microsoft SDKs\TypeScript\0.8.1.1\tsc
Which is probably now found under
c:\Program Files\Microsoft SDKs\TypeScript\tsc
As they removed the version folder in 0.8.2.0 to save us from constantly updating this path in the project file!
The error message may be misleading - so check this path instead.
If you are using a 64 bit version of Windows, look in Program Files (x86) instead of the plain Program Files.
I have migrated a project from Visual studio 2008 to Visual Studio 2012. After migration, I am not able to run the application because it is throwing
C:\Program Files\Common Files\microsoft shared\OFFICE14\MSOXMLMF.DLL. Cannot find or open the PDB file. message on the output window and my application is getting aborted.
Can anyone help me out on this?
Run your application with WinDbg
issue the ".reload" command as:
.reload /f SRV*D:\MySymbols*http://msdl.microsoft.com/download/symbols
The part between the ** is a path on your system. The command will download the matching symbol files for all loaded modules.
I've uninstalled VS11 using the the windows installer, and deleted just about every registry key I could find relating to it, but it still pops up with this when I try to reinstall it:
And I can't click the "..." or edit the path. Right-clicking does nothing either.
What do I have to destroy to change the install directory?
Still happening in official release:
I had the same problem though instead of forcing me to install into "c:\program Files" it forced me to install to the directory which I used for the Visual Studio RC. After using Process Monitor and the setup's logfile I was able to find a registry key that needed to be deleted.
The key was located at
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-776561741-789336058-725345543-318838\Components\31F687BD8A467D54C830E018D99F7F3B
The SID will most likely be different for other systems yet you might be able to find the last string (31F687BD8A467D54C830E018D99F7F3B)
In order to find the key I did the following:
Downloaded ProcessMonitor from Sysinternals
Started Processmonitor with filter
Image Path ends with vs_premium.exe
Started vs_premium.exe
Closed the setup
Waited until Processmonitor didn't fetch anymore events
Opened the newest dd_vs_premium_.log file from %TEMP%
Searched for something and found
Condition 'VS_Install_path_KeyExists' evaluated to false. (i guess it will evaluate to true on affected systems. I tried this on a clean windows installation)
One line above it said
Registry key not found. Key =
'SOFTWARE\Microsoft\VisualStudio\SxS\VS7'
Searched for
Microsoft\VisualStudio\SxS\VS7
in Processmonitor
A few lines down ProcessMonitor shows me the key I had to delete
A simpler approach worked for me:
1 - Run the installer from the command line, with /uninstall /force switches, as in:
c:\vs_professional_ENU.exe /uninstall /force
2 - Re-run the installer normally.
I did this with VS2015 under Windows 10. Reference link.
The only solution I've found is on Windows 7 to create a hard Junction link to the directory your wanting Visual Studio installed to.
For Example, My SSD drive is not my boot drive and has a drive letter of B:.
I run the following command line
mklink /J "C:\Program Files (x86)\Microsoft Visual Studio 11.0" "B:\Program Files (x86)\Microsoft Visual Studio 11.0"
To the installer and Windows it thinks it installed it to the Program Files x86 directory on C: drive when it really installed it to the Program Files x86 folder on B: drive.
Here's a link to page about creating Junction links in Windows Vista and 7. http://www.howtogeek.com/howto/windows-vista/using-symlinks-in-windows-vista/
I dont have the rep to comment on the post above. Although he is correct in the syntax of those command switches, the program is bugged, it doesnt work with selecting the CustomInstallPath. In fact, for me, it just decides to open about 50+ iterations of vs_ultimate.exe in the process list...
I will try the Hard Junction as mentioned above as I am sure that will work.
As a sidenote, if anyone is interested, you can use the switch that allows you to acquire the installation ahead of time by running vs_ultimate.exe /Layout X:\somefolder\
I did that last night and hopefully my installation will go quickly since i havea ll the info, however I think in order to force it to use the offline version, you have to run vs_ultimate.exe /noweb.
This page refers to all the switches: http://msdn.microsoft.com/en-us/library/e2h7fzkw(v=vs.110).aspx
The above pages notes that: /p CustomInstallPath "Installs all re-targetable packages in the directory that you specify." Thay may mean that silently, whatever it is able to install off of your root drive, it will, but its hard to be certain and I have limited space on my SSD.
Before I try the hard junction, I may also try the above and see what heppens, then uninstall it if need be. Will post results
Try launching the installer with the following option:
/p CustomInstallPath="[your_path]"
For example:
vs_ultimate.exe /p CustomInstallPath="C:\MyDirectory"
To see all options use the switch /?
For me the final visual studio 2012 wanted to install into the same path as the (uninstalled) beta. I deleted most of the stuff in HKLM that had an exact match for the setup directory (ending with a \ e.g. C:\VS11Beta\) and then the setup let me choose again.
Probably not a solution for the OP(M:\Program Files sounds too generic to delete), but perhaps for others with this problem.
I had previously installed the VS 2012 Test Controller. Uninstalling it allowed me to change the install path.
How to change Visual Studio 2012 install directory?
What do I have to destroy to change the install directory?
Answer: You can change the physical directory without the need to "destroy or change" the install directory. This is an alternative "think smarter not harder" solution proposal.
Here are the specific material details you need to continue to use your logical M:\Program Files directory and solve the physical where the files are stored problem.
It also serves the rest of the community well for cleaner more reproducible installs, less effort and risk when using Beta builds. Its less risk because it encapsulates every file in the beta install. Want to go from beta to RC, no problem, just don't mount the beta drives, use an off the shell registry cleaner and reinstall clean to fresh drives every time.
The process uses PGP disks which can be logged in and logged out of / backed up as needed.
Initially, it seemed as though it would be possible to create just two drives. not so.
- Drive #1 mounted as F:\ for f:\Program Files (x86)\Microsoft Visual Studio 11.0
This is where I told Visual Studio setup to install files to. And it does function as a mountable container for 2.7 Gigs of files.
Drive #2 mounted as a folder on "C:\Program Files (x86)\" "Microsoft Visual Studio 11.0"
The intended purpose of the mounted folder was to collect up the remainder of 5.5 Gigs of files.
The actual list of 33 created folders I had to move to additional PGP folders.
Here is the inclusive list of folders you can create before setup deploys files to them.
C:\Program Files\Microsoft SQL Server
C:\Program Files\Microsoft SQL Server Compact Edition
C:\Program Files\Application Verifier
C:\Program Files\MSBuild
C:\Program Files\Microsoft
C:\Program Files\IIS Express
C:\Program Files\IIS
C:\Program Files\Microsoft Visual Studio 11.0
C:\Program Files (x86)\IIS
C:\Program Files (x86)\IIS Express
C:\Program Files (x86)\Microsoft ASP.NET
C:\Program Files (x86)\Microsoft Help Viewer
C:\Program Files (x86)\Microsoft SDKs
C:\Program Files (x86)\Microsoft SQL Server
C:\Program Files (x86)\Microsoft SQL Server Compact Edition
C:\Program Files (x86)\Microsoft WCF Data Services
C:\Program Files (x86)\Microsoft Web Tools
C:\Program Files (x86)\MSBuild
C:\Program Files (x86)\NuGet
C:\Program Files (x86)\Windows Kits
C:\Program Files (x86)\Common Files\Merge Modules
C:\Program Files (x86)\Common Files\Microsoft
C:\Program Files (x86)\Common Files\microsoft shared\DevServer
C:\Program Files (x86)\Common Files\microsoft shared\MSDesigners8
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv
C:\Program Files (x86)\Common Files\microsoft shared\MSI Tools
C:\Program Files (x86)\Common Files\microsoft shared\SQL Debugging
C:\Program Files (x86)\Common Files\microsoft shared\SQL Server Developer Tools
C:\Program Files (x86)\Common Files\microsoft shared\TextTemplating
C:\Program Files (x86)\Common Files\microsoft shared\Visual Database Tools
C:\Program Files (x86)\Common Files\microsoft shared\VS7Debug
C:\Program Files (x86)\Common Files\microsoft shared\WF
C:\Program Files (x86)\Common Files\microsoft shared\Windows Simulator
This is perfect to prevent;
- Patch managers and patch management systems which inadvertently & unsupervised unmonitored, unaudited in willful ignorant bliss violate the premise of good promotion to production change control best practices
Developers who's code mostly works by random chance and really have no idea whats in the final product.
Hacker exploitation of the build environment.
Could have used True Crypt or PGP desktop. Just not whole disk encryption, have to be able to mount and unmount the resources.
I appreciate the hard junction approach, but unless you Safely ejecting & power off drives, it offers little process compliance and is neither safe or reliable as compared to safe PGP un-mounting/mounting. Developers will just power on the drives and make changes.
Regarding level of efforts to backup and restore, Backing up PGP drives as compared to hard junctioned drives is a wash about the same level of effort. But the value in not having to remember which folders are junctioned, which might need restored to restore a dev environment favors the fewer number of .PGD drives which contain all the needed folders ( ie do the remembering for you as a part of their function)
Consider this as an environment for when requirements are for mandatory non discretionary absolute auditable surety for a reproducible secure build. To meet that core objective, it has to be available only when its actually "needed" and has to be secured when its not needed.
Look into your installed programs and see if an instance of Visual Studio is already installed if so delete it and re-run the set up.
For this who still looking for a solution, What I tried and learned from this issue is that while "normal" (from control Panel) uninstall not every signatures of VS is not getting removed. So we have force uninstall from command line to remove all VS footprints. I have found the following answer in stack overflow very useful for me.
Run installer in command line (Admin) with argument:
vs_community_ENU.exe /uninstall /force
Then:
run vs_community_ENU.exe (or professional/enterprise).
How to install Visual Studio 2015 on a different drive