I am trying to convert one rather huge VS2005 solution with many C++ projects to VS2010. After automatic conversion I can see that some of the dependencies between the projects were lost and thus my VS2010 builds fail unless I manually re-add the dependencies.
Has anybody seen this behaviour?
Is there a fix for this?
Can I avoid having the dependencies dropped during the conversion by changing/fixing the VS2005 solutions/projects?
EDIT: And another conversion artefact is that like three header files in a single project are suddenly considered C++ source files (instead of just header files) and their compilation is attempted. The compilation subsequently fails because they do not include stdafx.h.
VS2010 project conversion is fraught. And if you haven't applied VS2010 Service Pack 1 you will almost certainly be wasting your time.
Regarding project dependencies (you might not like this): MSBuild 4.0 (the VS2010 build agent) no longer looks in the solution file for project dependencies. Even if you managed to get your solution to build okay in the IDE, if you ever plan to build your solution from command-line build scripts, or a TFS build server, then all your project inter-dependencies must be applied in each project. Otherwise your projects will almost certainly build out of order, especially on multi-core machines where, by default, MSBuild 4.0 uses as many cores as it can find.
My team had to bite the bullet and manually recreate project dependencies in each project so the VS2010 solutions would build correctly in both Visual Studio and our TFS build servers.
I had a similar problem and here's what I did: first convert from 2005 to 2008 then from 2008 to 2010. This helped me.
Related
I have moved one of our solutions to a new system for remote development and upon opening the solution I noticed all of the projects in that solution, have different target file extension. they all have become .pyd regardless of the project type that is libs, DLLs, EXEs they all now have .pyd target extension.
I checked the solution on two other workstations and they were fine, nothing out of ordinary! but on this system I'm facing this. I have used the updated Visual Studio to no avail, so I switched back to a previous version, the same version used on the machines that had no issues. This didn't work either, I completely uninstalled Visual Studio and tried again to no avail. The problem still persists and I have no idea what is causing it or what I should be doing to rectify this.
Here is a snapshot of one of the projects, the extension looks as if it's the default:
Please note that the projects all build just fine, and there seems to be no issues regarding that.
I wonder if anybody has experience converting VS 2008 C++ solution to VS 2017/19 without switching to newer SDK and toolset. The solution is quite old, very large, uses 3-rd party libraries, so full conversion is out of the question. The goal is only to switch to better user interface.
Theoretically it is probably possible, although I successfully converted only very basic C++ MFC project.
Project settings in VS 2017 show only latest toolset. To make other toolsets to appear, I had to install VS 2010, and also add SDK 8.1 from VS installer (without VS 2010, this option is not available). Then select toolset v.90 and SDK 8.1 for each project in solution.
At this point, simple converted project works fine. A large legacy solution has a lots of issues. I resolved generic ones, but it looks like uphill battle. For example, C++ directories are physically different and some of the files are missing. It may be possible to eventually assign original VS 2008 directories to each project and/or copy missing files, but I have the impression of doing something illegal.
The question is, is it a valid procedure and still possible after latest updates.
Thanks==
I have a legacy system, with C++ dlls, libs, and exes.
We build against either 2008 or 2012.
Obviously if a 2008 dll gets accidentally added to a 2012 build via TeamCity. That will be bad. Crashy. And vice versa.
So does anyone know of a way to get TeamCity to stop that being able to happen. I feel it must be possible as TeamCity runs the builds and as such 'knows' how each artifact was created. Surely there is some way to create a rule or such like that says 'Only 2008 artifacts for this build, otherwise error'?
Can I setup TeamCity to stop accidental 2008 and 2012 build mixes happening? (without using magic).
Ta!
Example:
My2008TeamCity build (Product built using 2008)
Requires artifacts a2008, b2008, c2008
My2012TeamCity build (Product built using 2012)
Requires artifacts a2012, b2012, c2012
The artifacts are DLL's and loaded at run time only.
Recently we ran the My2008TeamCity build.
A few of the artifacts had mistakenly been setup, through TeamCity to come from 2012 builds.
i.e. a2012 was added to a 2008 build as an artifact.
As the DLL is only loaded run at runtime, we didn't notice the problem until the code was manually run, and that part of the code hit.
Now imagine a huge system, with loads of artifacts, many developers working on subprojects constantly... and something that can guard against this happening suddenly feels required.
Ideally I would like TeamCity to say 'No this artifact was build against 2012, and you are running a 2008 build' and fail the build. So we can fix it.
X
I not clearly sure, are you using all of this in one solution? You can use separate folders of VCS(Build Configuration Settings\Version Control Settings\Edit checkout rules) and for configuration "2012" take only this folder from VCS.
Me and my partner are both sharing a c++ solution via subversion.
He is using Visual Studio 11 and I am using Visual Studio 2010.
After the first time he commited and i updated, i get the following error:
Error 31 error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
also, in header files i get the following error on #include <stdio.h>:
error: cannot open source file "stdio.h"
I am guessing this is a compatibility issue. How can we resolve this?
In Visual Studio 11 there is a property option that allows you to specify the platform toolset.
Platform Toolset v110 is used by default if you create a new project starting from Visual Studio 11, but if can change it to v100 that is the one used by Visual Studio 2010.
.sln and .vcxproj files saved in Visual Studio 11 are not backward-compatible with VS2010. Even if they were compatible, eventually you'd step across a code which is compilable in VS11 but not in VS10.
The best (and probably the only) way is to agree on using exactly the same development environment.
A bit late in the discussion, but since you're using source control, you can remove the project and solution files from the repository and just share source code. Obviously, if you add new modules and such to a project, you'll have to manually add them in the other solution, but at least you wouldn't have to worry about this incompatibility. If you wanted to get down to it, the application can be built from the command line using just the compiler and linker switches, which tend to be far more compatible between revisions. Finally, you could use another build tool (besides MSBuild), that remains compatible across studio versions.
If you decide to remove the solution and project files, one thing to consider is saving a copy of the original YourApp.sln as YourApp.sln.2010. Then you'll have something to seed future solutions from, but updates to projects and solutions will all need done from VS 2010 and the file then copied to their .2010 version and maintained manually.
If SVN has support for patches, or if you're willing to run quilt externally (or if you switch to mercurial, you can use the MQ extensions), you can create the patch files to convert from 2010 to 2011 and remove the upgrade patche(s) before synch.
Drake's solution didn't work for me as the properties for all projects in the solution were already correctly set to v100. However, the fix that did work was to clean the builds and remove all other files that weren't source files or project files. I think it was probably removing the files projname.vcxproj.user that fixed it, as perhaps the toolchain preference was somehow overriden in the user preferences.
I have a huge Visual Studio 2010 solution. I work with Visual Studio 2005, so I want to convert the solution to the desired version. Basically, it's a portable C++ code so it should compile on Visual Studio 2005 too. Changing the version in the *.sln file doesn't help because the *.vcxproj format is completely different from the old *.vcproj format.
Recreating the solution by hand is not an option because of its size. Also there may be some non-default compiler flags, dependencies, etc. that I don't know of (and I can't look through ALL this XML junk that I don't understand).
There is already a related question on How Do I Downgrade a C++ Visual Studio 2008 Project to 2005. However, the utility suggested there supports at most Visual Studio 2008.
Any suggestions?
It really totally sucks, that every proprietary IDE today thinks it needs to create its own project file format.
"Dear IDE developers, just use Makefiles and create a nice GUI for it so that also people without Makefile knowledge can use it!" In VS6 it was at least possible to import/export Makefiles, but not today anymore. And it was possible to use nmake for automated builds. No IDE needed to be installed, just the toolchain which could be grabbed by a simple checkout without installation.
I use CMake now. It's free, it's cross-platform, it is well supported in free IDEs like KDevelop, QtCreator, etc. It can generate Makefiles and Visual Studio projects.
So you maintain only one project source, the CMakeLists.txt file and can work with any IDE. No pain with different versions of Visual Studio or with other proprietary project file formats.
This way you can generate or VS projects for developing and you can generate Makefiles for commandline builds using nmake like in the good old days.
BTW, it's much easier to change settings in a CMakeLists.txt than clicking through various GUI dialogs. But this is a matter of personal preferences.
In my work made a utility which utilized the EnvDTE.dll and scanned a vcproj-file and optionally all vcproj-files within a sln-file. It compared all settings with a "template" and would issue a warning or optionally update the setting to correct values. We used this utility so that settings would be verified to be correct and consistent throughout all projects. I haven't updated the utility to 2010 yet due to other priorities.
EnvDTE hasn't changed much from Visual Studio 2008 to Visual Studio 2010. Perhaps it is possible to create a simple utility which opens the vcxproj-file using DTE100 and saves it using DTE90, or earlier.
Easiest way is probably to create a new project in VS 2005, and use the add existing item dialog to add the code to the project. I'd suggest using 'Empty Project' as the project type, so you don't have a lot of rubbish autogenerated for you that you'll just delete anyway.
I haven't tried it, but this looks promising:
http://www.emmet-gray.com/Articles/ProjectConverter.htm
edit: Nope, not promising, sorry :-(