I've got an MFC Application project under Visual Studio 2008 on XP (though I think it was started under an earlier version). When I asked to open it on a machine with VS 2012 on Windows 8.1 it translated the .vcproj to a .vcxproj and updated the .sln file but when I try to open it I just get a message "this project is incompatible with the current edition of Visual Studio". I can't find any kind of log file with any more info. The "new project" wizard only offers Windows Store apps and DLLs.
OK, it turns out that by just following the most obvious "download" link on the Microsoft site I'd got an "express" version that doesn't support MFC (see https://msdn.microsoft.com/en-gb/library/hs24szh9%28v=vs.140%29.aspx).
They really should give an error message that gives some clue as to what the problem is, though.
Related
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'm a student in Videogame Development, and just starting out looking at Unreal.
And no, none of my teachers know anything about this.
I have installed Unreal Engine 4.13 and Visual Studio Community 2013 now 2015.
I'm trying to make a C++ project using Unreal Engine (using blueprints is out of question so this didn't help)
Now, when I make a basic C++ project, Visual Studio shows the following error message:
Unsupported
This version of Visual Studio is unable to open the following projects. The project types may not be installed or this version of Visual Studio may not support them.
For more information on enabling these project types or otherwise migrating your assets, please see the details in the "Migration Report" displayed after clicking OK.
- UE4, "C:\Users\Gebruiker\MEGA\Unreal\Disposable\Intermediate\ProjectFiles\UE4.vcxproj"
- Disposable, "C:\Users\Gebruiker\MEGA\Unreal\Disposable\Intermediate\ProjectFiles\Disposable.vcxproj"
No changes required
These projects can be opened in Visual Studio 2015, Visual Studio 2013, Visual Studio 2012, and Visual Studio 2010 SP1 without changing them.
- Engine, "Engine"
- Games, "Games"
- Disposable, "C:\Users\Gebruiker\MEGA\Unreal\Disposable\Disposable.sln"
Then my browser opens showing a Migration Report telling me that VS had an error with Project.vcxproj and UE4.vcxproj, although it copes with Engine, Games and Project.sln.
After this VS does show up without any further action, and it does automatically open *.h and *.cpp files for newly added classes in UE4.
Though it does edit and save these, it claims that all UE's code is wrong (with squiggles), and for compiling UE4 gives errors on pieces of code that apparently don't give errors on other's machines.
It would be much appreciated to be helped out, and I'm sure it would help others too who would have the same problem.
EDIT
A screenshot of the problem and configuration
EDIT 2
A screenshot of the Help -> About Visual Studio page, VS 2015 C++ highlighted
Starting with both the Unreal Engine Editor and Visual Studio closed, right click your .uproject file and select Generate Visual Studio project files, and then launch visual studio from the .sln file.
Once Visual Studio is open check your Solution Configuration is set to Development Editor. Then go to Debug > Start without Debugging (or Ctrl-F5). If everything compiles and the Editor opens again then you're good to go.
I uninstalled VS2013, installed VS2015 with all additional options checked, made a blank, new project with Unreal with just VS2015 on my pc, and now everything works fine.
Perhaps my VS2013 installation was broken, deprecated or switching version wasn't a good idea, but I can work with VS in any case now.
Also thanks to jeevcat for mentioning it!
Install newer version of the Visual Studio. VS2013 is not the latest one, VS2015 is. People report that even updating VS2013 from Update 2 to Update 4 helps resolving similar issues.
I try to ran a previous written MFC c++ code on my visual studio 2015 MFC with multitype MFC library installed.
However, I still have 12 errors here regarding missing function:
IntelliSense: cannot open source file "afxwin.h"
C1083 Cannot open include file: 'afxwin.h': No such file or directory
cannot open source file "afxext.h"/"afxdisp.h"/"afxdtctl.h"/"afxcmn.h"/afxdisp.h etc....
Where can I get these head files?
Again, my set up is:
VIsual studio 2015 ultimate MFC
Multibyte MFC library installed
Windows 8 - 64 bit machine
Thanks!
I just fixed a similar problem. Here's how you can resolve this.
Go to your control panel
Navigate to uninstall/change a program.
Scroll down until you see your visual studio installation
Click change
Once the window pops up, click "Modify"
Under Programming Languages -> Visual C++
Make sure "Microsoft Foundation Classes for C++" is checked. If it isn't select it and click update.
For VS2019 the above solutions didn't worked for me.
I had to go to "Installer -> Individual Components -> "
and install the following to solve the issue:
"MSVC v141 – VS 2017 C++ x64/x86 build tools (v14.16)"
"C++ MFC for v141 build tools (x86 & x64)"
"C++ ATL for v141 build tools (x86 & x64)"
For what it's worth. I was getting similar errors after a fresh installation of VS2017. I installed the C++ features from the main installer and created a new project with MFC checked. I assumed "Microsoft Foundation Classes for C++" was installed by this point, but I kept getting these errors. Furthermore, after saving and closing the solution for the first time, VS wouldn't load the project if I opened the solution from the recently used list because dependencies were missing.
What worked for me
I opened the solution file directly using VS2017. Finally, VS informed me that "Microsoft Foundation Classes for C++" was not installed and gave me the option to install it. I had previously looked through the installer features and could not find this option.
EDIT
Per Vladimir's comment below...
In 2017 Visual Studio Installer it ["Microsoft Foundation Classes for C++"] is under Modify / Individual Components / SDKs... / MFC and ATL support (x86 and x64)
This is most annoying and incomprehensible. I tried to open an older project, that was none the less last worked with in Visual Studio Express 2013 on Windows 7. Now I had to get a new computer, and have Windows 8. On opening the .sln or .vcxproj files, Visual Studio just tells me in the solution explorer that
"this project is not compatible with the current edition"
If I open the older .vcproj project file, Visual Studio terminates the migration, showing a dialog box stating that
"the system can not find the file specified"
Although, it doesn't give any information whatsoever about what file it is actually talking about.
Did anybody else ever have a similar problem? Currently I don't know what to do, except for recreating the whole project structure from scratch, but this really shouldn't be necessary...