I have a Visual Studio C++ console application that I created with Visual Studio 2015 and now I can't compile it (with Visual Studio 2017) because it is targeting the Windows 8.1 SDK, which is not installed. The problem is that I can't retarget the project to the Windows 10 SDK.
What happens is that when I open the project properties page and go to General - Target Platform I see the Windows 10 SDK in the dropdown, and I am able to select it... but as soon as I press Apply, it reverts back to 8.1 by itself. No error message is provided.
Visual Studio installer says that, indeed, the listed SDK version is installed:
So what's going on here? Is there a way to retarget my project without having to install the Windows 8.1 SDK?
Not sure if that matters but: this project is actually just a "wrapper" around an existing bare project consisting of just a bunch of .cpp and .h files, which was developed by another person. I'm really not familiar with C++ development.
After hours of struggling with this problem, I coincidentally discovered that selecting Project Properties/General, changing "Platform Toolset" to v141_xp (instead of v141) forcibly drops the Windows SDK Version to 8.1 or 7.0. I'm not sure how Visual Studio chooses which SDK to use.
EDIT: You must edit .vcxproj and change both:
<TargetPlatformVersion>10.0.17134.0</TargetPlatformVersion>
<WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
I have a VS 2015 C++ project on a remote directory that I want to share between 2 computers. On one computer it loads fine (it has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework Version 4.6.01055) on the other computer it fails to load (it also has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework
Version 4.6.01055). When it fails to load I get the (not very informative message)
TargetImager.vcxproj: The application which this project type is based on
was not found. Please try this link for further information
[The link is completely useless!]
I opened the project file in the solution (can't remember how I managed to do this) and it presents a number of warnings eg.
Severity Code Description Project File Line Suppression State
Warning The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'PlatformToolSet' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Property, VisualStudioVersion, MinimumVisualStudioVersion, AdditionalFileItemNames, AllowUnsafeBlocks, AppConfigForCompiler, ApplicationIcon, ApplicationRevision, ApplicationVersion, AppDesignerFolder, AspNetConfiguration, AssemblyKeyContainerName, AssemblyKeyProviderName, AssemblyName, AssemblyOriginatorKeyFile, AssemblyOriginatorKeyFileType, AssemblyOriginatorKeyMode, AssemblyType, AutoGenerateBindingRedirects, AutorunEnabled, BaseAddress, BootstrapperComponentsLocation, BootstrapperComponentsUrl, BootstrapperEnabled, CharacterSet, CheckForOverflowUnderflow, CLRSupport, UseDebugLibraries, CodePage, Configuration, ConfigurationName, ConfigurationOverrideFile, CreateDesktopShortcut, CreateWebPageOnPublish, CurrentSolutionConfigurationContents, DebugSecurityZoneURL, DebugSymbols, DebugType, DefaultClientScript, DefaultHTMLPageLayout, DefaultTargetSchema, DefineConstants, DefineDebug, DefineTrace, DelaySign, DisableLangXtns, DisallowUrlActivation, CodeAnalysisAdditionalOptions, CodeAnalysisApplyLogFileXsl, .... Miscellaneous Files H:\CodeProjects\QTProjects\TargetImager\TargetImager.vcxproj 20
Here is the section of the project file XML
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<PlatformToolSet>v140</PlatformToolSet>
It doesn't like this PlatformToolSet setting for instance. I don't get it because it is a setting in the property pages on VS2015 that can be selected. I anyway changed this property clicked apply then changed it back clicked apply. It is still there in the project file as before with same error message, I also changed the setting to v140_xp just to verify that it was seeing the new property which it was.
The story is that I was working on one computer with VS 2015, then I wanted to run something on another remote computer, however by then VS 2015 was replaced with VS 2017 and I installed VS 2017 on the remote. I built the project on VS2017 but then went back to the local PC with VS2015 to do some QT stuff (QT plugin is not yet available on VS2017). This was OK but then it refused to load on the remote VS2017 PC. So I uninstalled VS2017 and replaced it with VS2015, the project still doesn't load on the remote PC with VS2015.
Maybe somehow I have a VS 2017 project that for some reason loads on one computer with VS2015 and not the other, hence the settings that VS 2015 doesn't like.
So I try to create a new QT GUI project (I installed QtVsTools extension) on the remote machine that has problems with my project file. And now I get an error (the same error also occurs with a new win32 console application)
.../TarImager.vcxproj cannot be opened because its project type (.vcxproj) is not
supported by this version of the application.
To open it please use a version of the project that supports it.
As far as I know .vcxproj has been supported since MS VS 2010
Any idea how I can debug this?
The visual studio install had become corrupted, I repaired the installation then was able to create projects again. If you get weird project loading errors, then maybe your VS install is messed up.
I have a problem where Visual Studio will not create a new C++ Console Application project. I can input the project name and location, but when I hit the create button it simply closes the project creator window and reopens it without creating anything. It will do this with both types of the standard C++ Win32 project templates. Everything else works and will load without this error, but for whatever reason Visual Studio will not create Win32 C++ project types. I have previously been able to create such projects in the past; the problem I am encountering is recent.
My version of Windows 10 has recently been updated to the most recent version, but I do not think this will have effected the program. I have tried to run the repair tool included with Visual Studio and running it as an administrator, but nothing has helped. Can you please tell me why Visual Studio might be refusing to create Win32 Projects and how to fix it?
Fixed it. I completely uninstalled Visual Studio and it worked fine after that. Rebooting didn't help; the reinstall did the trick.
I have visual studio 2015 community Update 2.
I've installed Visual C++ for windows and also for mobile platforms as you can see in this picture:
The problem is that when I try to create a C++ Win32 app and click on these two templates
nothing happens and I get stuck at that screen.
As Cheers and hth Alf said, I had to reinstall the whole Visual Studio 2015 to get it working again.
I'm trying to make a game using SFML. I did a part of it on Visual Studio 2012 and Windows 7. I tried to run the game on another PC that uses Windows XP, but I got an error "MSVCP110D.dll was not found". I saw another topic in this forum that says to compile the code in Release mode, but when I choose the "Release" option before compiling, Visual Studio underlines everything that is releted with SFML. It can't find the library that I have included "SFML/Graphics.hpp". In "Debug" mode everything is OK. Do you have any idea how I can run my game on different PC (Windows XP or Windows 7)?
I changed the properties of the project to compile for Windows XP. Without this option when I try to run the game on XP, in error occurs "Not a valid 32 bit application".
Everything is working now. I changed all setting for release mode. On my Win XP PC I installed C++ Redistribution 2012. But what if I send the game to person who don't have C++ Redistribution 2012?
As the discussion in the comments have shown, you should always build in Release mode for deployment. Further more when you link the runtime dynamically you need to either provide the DLLs with your application (copy them from the Visual Studio directory next to your executable) or ship/link the matching redistribution.
Another option would be to link statically as Schepurin pointed out, but keep in mind that this can cause other issues if not done right and consistently.