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.
Related
I develop an application using Visual Studio 2015 + Qt VS Tools extension. For me it's first time I used Qt (version 5.14.1) in my project. Everything was working fine until something wrong happened.
I was asked to make release version of my application, it worked fine on Windows 10 and Windows 7 64-bit systems. Then I set the project configuration back to Debug x64 to continue my work. First strange thing I noticed - when I double-clicked on *.ui form files in my Solution Explorer, Visual Studio crashed and reloaded without any error, Qt Designer doesn't launch.
What I tried:
First I tried to open Qt Designer externally (from bin folder in Qt directory) and open my form - it worked.
I tried another project made in VS 2015 + Qt VS Tools Extension - same problem.
I tried to remove my Qt Version and re-add it. And here it comes: Error screenshot. It also occurs without using system enviroment variable $(QTDIR).
I reinstalled Qt to my PC (installed version 5.14.2 instead of 5.14.1), same error.
I reinstalled Visual Studio 2015, same error.
I tried to reset my Visual Studio settings and parameters to default, no results.
I installed Visual Studio 2019. The problem is still present.
UPD:
I cleared Visual Studio cache according to these instructions. It didn't work for me.
I removed every Visual C++ Redistributables from my PC and installed the latest version from Microsoft site. It also didn't work.
The error occurs even if no project is opened, so the problem is caused either by Visual Studio 2015, by Qt 5.14, or by Qt VS Tools extension.
P.S. Sorry if my english wasn't perfect. Waiting for any ideas on fixing this problem.
For any future readers who have this problem, start your maintenance tool or Qt installer, e.g. C:\Qt\MaintenanceTool.exe, "Add or remove components", and then make sure Qt/<version>/MSVC is installed, as shown in the image below:
.
Then you'll be able to select that Qt version instead of MinGW, since the Visual Studio extension only supports the MSVC compiler and not MinGW.
Encountered the exact same problem and the only solution I have found was reverting to an older version of the Qt Visual Studio Tools extension.
Visual Studio has been painfully persistent about updating the version even once I installed an older one, so make sure to disable automatic extension updates (Extensions → Manage Extensions → Extension Settings → Uncheck Automatically search for updates/Automatically update extensions).
Hope it helps.
To solve your problem, you need to remove the QTDIR and QMAKESPEC environment variables that remain in Windows after installing older versions of Qt.
Well, after some more procedures that didn't help, I just did clean-reinstallation for my Windows 10. Fortunately, that helped :)
I am unable to create a VC++ project in VS2015 Community. When I attempt to do so, I get two messages starting with, 'The "Visual Studio C++ Project System Package" did not load correctly.' Then this fatal message appears:
I also have VS2005 Professional installed on my machine; I need the two for different projects.
This seemed similar to not able to create VC++ project, with VS11 so I created a batch file that sets those env vars and then calls devenv.exe for VS2015. Still got the same error messages.
Visual Studio 2015 (community)- cannot create new project c++ suggests an incompatibility between two versions and to delete an old directory. But as I need both versions, that does not seem to be a good solution either (and suggestion didn't appear to help that OP).
As final data points, Intel Visual Fortran 2017 is installed and integrated with VS2015, and I note that a resulting VFPROJ file is in the pre-VS2010 format - .vcproj format with <VisualStudioProject> being an element.
At any rate, I cannot create a new project inside VS2015 for C++ and would appreciate your help towards a solution.
I chose Repair for on VS2015 under Control Panel - Programs and Features and I am now able to create a C++ project. I will continue testing by creating a nother Fortran project and if it causes the problem to recur I will repost.
At the start I'd like to note that I've spent some time researching this issue and suggested solutions for similar questions like this one didn't help me.
Problem background
I need to migrate a Firebreath plugin project (which I haven't worked on previously) from PC_1 to PC_2.
As far as I'm aware the project was started on PC_1 on Visual Studio 2010 and later moved to Visual Studio 2013 Pro. There's one solution consisting of 19 projects. I have an instruction which says that in order to get the plugin installer I should first Build project_x and after that Build project_y_WiXInstall. Both steps work without any issues on this machine.
Then there's PC_2 which had Visual Studio 2015 Community installed before I started working on it. I've removed it, installed Visual Studio 2013 Pro (version 12.0.21005.1 REL - exactly the same as on PC_1), moved all of the needed files and I'm trying to get rid of all of the compilation errors. So far I figured out I had to install Cmake 2.8, Windows Driver Toolkit 7.1 and manually override an incorrect VCTargetsPath MSBuild variable
Problem description
Currently when I try to compile the project on the new machine I get these two errors (this is an image link since I can't embed images yet on this account). I'm not sure what's going on with the first error message since it looks incomplete and the file CUSTOMBUILD doesn't exist, but I'm not bothered by it too much since the previous compilation error I fixed also had a similar "artifact" as the first error and it disappeared after fixing the second one.
The covered part of the second error message is the project path. The error origin (Microsoft.Cpp.Platform.targets file, line 64) looks like this:
<!-- Error out if toolset does not exists in Visual Studio 2010 or 2012 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_CurrentPlatformToolsetShortName);$(PlatformToolset)" Condition="'$(ToolsetTargetsFound)' != 'true'" />
What didn't help
The error description suggests using an Upgrade Solution... option, but there's no such thing when I right-click the solution
As an accepted answer for the question I've posted at the start of my post suggests, I've checked the Properties of all 19 of my projects (including the project ZERO_CHECK) but their Platform Toolset is already set to Visual Studio 2013 (v120).
I've also tried changing the Platform Toolset to inherit from parent or project defaults for all of the projects. This resulted in it switching to Visual Studio 2010 (v100) (not installed) and after that I've right-clicked on the projects and chose Upgrade VC++ compiler and libraries. After this the Platform Toolset was back to the Visual Studio 2013 (v120) but it didn't help with the compilation error.
As a NON-accepted answer for the question I've posted at the start of my post suggests, I've tried searching for all of the occurrences of 10.0 and V100 in all of my .vcxproj files to replace them but I haven't found any occurrences of them.
[EDIT]
I just got an idea to try building the project with MSBuild from the command line. There's a bit more info compared to errors inside Visual Studio, so maybe it will help with resolving the issue: https://pastebin.com/JhN3dXM3
So the thing you're missing here is that FireBreath projects are built using CMake -- the actual contents of the build directory should always be completely temporary and never stored in source control. To build the project on a new computer you need to run the prep command again from scratch.
If the previous maintainer changed the build files manually and/or migrated it to a newer version of visual studio without using cmake to do it then they did some very ugly things and all bets are off... good luck.
This is why all the firebreath documentation (I wrote most of it) strongly urges that the build directory be transient and you always do project file updates in cmake.
Hope that helps!
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.
We have a mixed Java/JRuby project that uses a C++-DLL developped in Microsoft Visual Studio. Recently, the supplier of this DLL upgraded their development environment to Visual Studio 2015 professional. This required installation of the new runtime libraries (vcredist_x86.exe) on our machines (which are running on Windows 7). After we did this, everything worked as expected.
However, we also use a server (Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2) to run regression tests. I installed the new runtime libraries, and the DLL is loaded. But when the program is run, we get an fopen error when the DLL tries to load a certain file. errno gives 2 (ENOENT according to errno.h). The file is present, the DLL tries to load it using a relative path. It is not the first file that is opened via fopen, and access to the other files seems to work.
I do not have access to the source and cannot debug on the server and the developers of the DLL cannot reproduce the problem.
Has anyone experienced a similar problem on Windows Server after updating to Visual Studio 2015? And if so, how did you solve it?
The supplier of the DLL probably used the default toolset v140 which is not compatible with Server 2003. If you use Server 2008 for tests I suspect you'll be fine. Or if they are able to use the v140_xp toolset I suspect you'll be fine. That option is here: Configuration Properties -> General -> Platform Toolset