When I installed the latest WDK it added a new option for Spectre Mitigation which cause linking to fail. Instead of changing hundreds of projects, where I can simple change the default to disabled instead of enabled?
TIA!!
Remove the Spectre Reference in the various:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\($Platform)\ImportBefore\Default\Microsoft.Cpp.WDK.props
files.
Related
Whenever I start a new C++ project on Visual Studio and compile, I am faced with this error. I then have to go to settings and disable spectre mitigation.
Error MSB8040 Spectre-mitigated libraries are required for this
project. Install them from the Visual Studio installer (Individual
components tab) for any toolsets and architectures being used. Learn
more: https://aka.ms/Ofhn4c2_Beginner-IntermediateC++
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft
VC\v160\Microsoft.CppBuild.targets 428
Is there a way to have this option disabled automatically by default?
Why is this option enabled for me by default? I think I may have messed up an installation somewhere along the way as I don't see many posts about this online.
What I have to do every time to fix it
Note: I remember trying to install the libraries it's suggesting but there was around a dozen of them and they didn't seem to be making a difference. It was a long time ago though and I may have made a mistake. I will try again.
Ok thanks to #dxiv I managed to solve this issue, i.e. now my new C++ projects on Visual Studio have Spectre Mitigations OFF by default and I don't have to manually disable it every time I create a new project.
First I uninstalled WDK, it did not solve the issue.
Then on Visual Studio Installer > Modify > under Individual Components > Untick box that says WDK (3MB) > Modify. This will remove that WDK component. And now the spectre mitigation is off by default.
The solution could be due to both of the steps I mentioned but probably it was enough to just remove that component from Visual Studio Installer.
Azure dev ops -- Set Visual Studio 2017 (VS2017) as default for cloning project?
I have multiple versions of Visual Studio installed, and for policy reasons, I need to keep them, at least for a while.
How do I set up Azure dev ops so that when it clones a project via "Visual Studio" (from the dropdown) it will automatically select VS2017 as opposed to an earlier version such as VS2015?
I think this is determined by what version selector is targeted by the 'vsweb' protocol handler, i.e. it's a setting on your machine.
It seems like when VS2017 installs it doesn't always set the version selector to the 2017 version (which defaults to opening VS2017), rather than an old version.
This is set in the registry at HKLM\SOFTWARE\Classes\vsweb\Shell\Open\Command. The value will most likely be set to an older version, for example:
"C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv\VSWebLauncher.exe" /openuri "%1"
Update it to be:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VSWebLauncher.exe" /openuri "%1"
Obviously check the paths are correct before changing them, those are the ones from my machine.
It's always worth keeping a copy of the old value so you can put it back in if something goes wrong.
Hell'o
I've just installed Visual Studio 2017 (enterprise).I opened my project whom I created in Visual Studio 2015. My project uses windows.h library but VS2017 cannot find this library. How to repair this?
My solution was :
Open the project properties
Into General --> SDK Version
I just picked the 10.0.15063.0 version instead of 8.1
And it worked.
I solved this issue by re-running the Visual Studio Installer and selecting the "Modify" button. Once presented with the Workloads screen I clicked on the "Individual Components" tab and selected all of the latest "Windows 10 SDK" Checkboxes(version 10.0.15063.0). My guess is that the entry for "Desktop C++ x86 and x64" is the one the actually fixes it but it is only speculation because none of those options were checked when I ran the installer and as you can see I checked all of them.
This happens when you have customized include/library paths in legacy projects. If you added your own additional paths in project properties, VisualStudio 2017 can't automatically figure out base paths when switching between platforms/toolsets - normally it automatically puts correct paths there, but if you added customizations, VS won't touch them.
This is legitimate problem which I ran into myself recently when migrating old project targeted for Windows XP into VS2017. None of the answers or comments listed/linked here so far are helpful. I have all legacy SDKs in VisualStudio 2017 installer, and none of that fixed VS not finding essential includes such as <windows.h>. In my case the project was using v120 toolset from VS2013, which is superseded by v140_xp in newer VS.
After setting correct platform and toolset understood by VS2017, I did the following to resolve the problem:
Open project properties, go to VC++ Directories, for 'Include Directories' and for 'Library Directories', choose <Inherit from parent or project defaults>. This will remove your additional paths.
Click 'Apply'. This will reset include path to something like $(VC_IncludePath_x86);$(WindowsSdk_71A_IncludePath_x86) (will vary for SDKs).
Re-add your extra paths here, or better yet - under C/C++/General -> Additional Include Directories and Linker/General -> Additional Library Directories.
I got it fixed when I simply changed "General => Windows SDK version" to a different version, submitted the changes and then changed it back.
The problem occurs when you migrate your C++ project from a more updated visual studio version to a lesser one.
To solve the issue simply go to your :
Project's properties-->General-->SDK Version [and here unroll to show installed SDK versions so you downgrade to an available version {Since the required one seems unavailable hence the error}].
Once one of the Available SDKs selected, Apply, and go back to your code, and everything gonna get fixed.
If the installation was ok it should be here:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\Windows.h
So be sure it is on the include path of the project properties.
Or if you prefer by manual edit in the .vcxproj file at the IncludePath Tag line:
<IncludePath>$(VC_IncludePath);$(WindowsSDK_IncludePath);C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um;C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\shared;</IncludePath>
TL;DR: make sure the checkbox, marked below, is checked.
In the Include Directories Dlgbox, there's an option at the bottom "Inherit from..." that needs to be checked. Somehow it got unchecked after moving a project to a different solution.
So, in my case, resetting to defaults and adding custom paths again wasn't even needed.
You have to go in Visual Studio 2017 Installer, choose Individual Components, and manually select and install Windows 8.1 SDK.
This step work for me.
1. Open visual studio installer
2. at menu "Visual studio comunity 2017" --> click modify
3. at desktop development with c++ --> enable windows10 SDK for desktop and windows 8.1 SDK
4. click modify
I've also installed Visual Studio 2017 (community) first with the default composition settings.I opened my project whom I created in Visual Studio 2015. My project uses windows.h library but VS2017 cannot find this library and other problems. At first I install the missing (SDK 10 ... etc.) components. Part of problems is gone, but windows.h still not found. The problem was solved by completely uninstalling VS2017 and then installing with all the options at once.
My solution was checking paths.
Include Directories:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared;
%(AdditionalIncludeDirectories)
Library Directories:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x64
and then right click Solution Explorer: Solution 'xxxxx' (1 project) line click "Retarget solution"
Remember to set Debug setting for Symbols fetch - Windows 10 must use Microsoft symbol server!
Up to Visual Studio 2013 all you needed was msvcr[version].dll and msvcp[version].dll.
Now they changed the DLLs with 2015.
What do I need to include in order to avoid a redist installer?
EDIT:
It seems to be impossible now:
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
"App-local deployment of the Universal CRT is not supported."
UPDATE:
The content of the link above was updated on 11 Sep 2015. Now it's possible to make app-local deployment.
This worked for me (x86 app).
Shipping all dlls from these locations with your app:
C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT
Myself, I needed an additional file to make this happen. Here are the directories, with one in a more generic format:
Copy all the files from "C:\Program Files\Windows Kits\10\Redist\ucrt\DLLs\x86" or "C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86" (or copy them from the x64 directory if it's a 64-bit app).
Copy msvcp140.dll and vcruntime140.dll from:
<Visual Studio 2015 Install Directory>\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT (or copy them from the x64 directory if it's a 64-bit app).
If you're using Qt, copy these files into the directory made by windeployqt.
In general, I found that you can just do step #1, and attempt to run your app. It will tell you the first of the files it is missing, and once you have put it in your app's directory, it will tell you the next one you need. In my case, it was two. Copying similar files from my <Windows>\System32 folder, e.g., was not successful. I have found using Dependency Walker and trying to satisfy the dependencies it indicates to be unsuccessful.
This allows you to make a portable app that will run on M$ OS's as old as XP; or install for users without vcredist_x86 or vcredist_x64, who don't have admin privileges.
BTW: Step #1 is pretty official. Here it is at the MSDN blog: Introducing the Universal CRT They say to copy them all for an app to run on all M$ OS's.
In general, you can use dependency walker to find the list of dependent dlls.
Regarding the visual studio runtime dlls, what you are mostly concerned about are the dlls with Visual studio specific versions in them.
As mentioned at point 6) of this article now it's possible to make local deployment of the Universal CRT. To do that you should install Windows 10 SDK and copy all the binaries from C:\Program Files (x86)\Windows Kits\10\Redist\ucrt.
As the question states, what is the default path to the MIDL Compiler in Visual Studio 2013 (or previous versions) for those who want to manually run it from the command line to build IDL files?
It depends on the Platform Toolset you have selected for a project. The default one (v120) takes you to c:\program files (x86)\windows kits\8.1\bin\x86\midl.exe. If you target XP (v120_xp) then you get c:\program files (x86)\microsoft sdks\windows\v7.1a\bin\midl.exe
You normally don't care and use the Visual Studio Command Prompt.
Our sources seem to expect it in Program\ Files/Microsoft SDKs/Windows/v7.0/bin/MIDL.exe so in the SDK rather than in VS. I suspect it may have been removed from the win8 sdk though when they removed the compiler. We have not yet ported to that SDK.