I have MFC Dialogue based applications written in VC++6.0. Due to my work environment requirements I need to upgrade to Visual Studio 2010. I don't need to add any new feature, just compile with the upgraded visual studio.
Can any guide me on this?
What are all the primary requirements and how to start it?
Just open the project/solution in VS-2010. Convert it and compile.
You might get some compiler warnings/errors depending on your code, because the new compiler is more precise.
But most conversions lead just to a view warnings, like security stuff and others and should work directly.
From the VC++ team blog and Visual Studio 2010 C++ Project Upgrade Guide:
With Visual Studio 2010, C++ build system moved from the VCBuild based system to the MSBuild based build system.
The C++ project system is also built on top of the MSBuild build system.
There are some limitations, known issues or by design changes that you may run into during the upgrade process.
VS2010 supports upgrading from VC6, VS2002, VS2003, VS2005 and VS2008.
As in previous versions of Visual Studio, upgrade can be done either through IDE conversion wizards or from the command line (Devenv.exe /upgrade).
Here are the recommendations for upgrading your applications:
1) Set up the upgrade environment the same as your build environment
The upgrade process will try to load files and evaluate values during upgrade. If your projects use values that are not defined by the project files themselves, for example, values defined by environment variables, it is required that these environment variables are set up before doing the upgrade. Without these environment variables properly set up, you may get conversion warnings or errors caused by unevaluated values.
2) Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the corresponding platform installed under
'%vctargetspath%\platforms\Itanium'. Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
3) Use native Multi-Targeting to build against VS2008 toolset first if possible
In VS 2010, Native multi-targeting have been added which allows you to build against the Visual Studio 2008 toolset from within the VS2010 IDE using the new MSBuild-based project system. I recommend you to take advantage of this feature by using VS2010 to build against VS2008 toolset first when upgrading. This can help isolate any project system/build system related issues from the tools issues that you may run into after upgrade. This will make the move to the VS2010 toolset much smoother.
Upon upgrade, the property sheet files (.vsprops) are converted to their new format (.props). Likewise, project files (.vcproj) are converted to their new format (.vcxproj). Note, the new project files are generated alongside the old project files. A new file type (.filter.vcxproj) is also generated during conversion. The filter files contain the information that is used to display folders in the solution explorer. This filter information was originally part of the project file. This change was necessary because MSBuild requests a rebuild whenever the project files changes. By storing filter information in a separate file, the filter can be changed without triggering a rebuild of the entire project.
Note: Upgrade process will not convert the .user file. As a result, your debugging and deployment settings will not be preserved after conversion.
In VS2010, a new command line upgrade tool, VCUpgrade.exe is introduced. This command line tool is suitable for upgrading applications with only one project as it cannot take in solution file as input and parse solution information into project files. VCUpgrade.exe is located at: $(VSInstallDir)\common7\Tools directory. This tool will also be shipped in the next release of WinSDK so that the users can do command line upgrade of the project files shipped in WinSDK without Visual Studio IDE.
Related
I'd like our developers to use one version of Visual Studio for all of our projects (where possible) - to that end, I've asked them to use VS2019 for some projects that were originally created in VS2010 and then migrated to VS2013.
A runtime behavior change occurred when running one of these old webforms applications in VS2019. I'm not sure why it's different since the dlls being used are the same and the compiled IL is the same for the method in question, but at the moment I don't really care about "fixing" it since it would require making code changes and regression testing the entire application; a path I'd like to avoid for the moment.
What I'd like to do is make sure VS2019 builds with the indicated tools so that we retain the old behavior. The project file is referencing tools version 12 (VS2013 is not installed), but when Visual Studio builds I see the following in the MSBuild output:
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
I installed MSBuild Tools 2013, but that didn't correct the issue before or after a restart. I also tried with tools version 15 and got the same error (VS2017 is installed).
MSBuild from the VS2019 dev command prompt worked, but I had to copy the 14.0 webapplication targets to a new folder named "16.0". I'm not sure why there is a 14.0 folder but no 12.0 or 15.0 folder without doing more searching online.
Is this a fool's errand, or am I missing something simple?
MSBuild from the VS2019 dev command prompt worked, but I had to copy
the 14.0 webapplication targets to a new folder named "16.0". I'm not
sure why there is a 14.0 folder but no 12.0 or 15.0 folder without
doing more searching online.
Update 1
This is just a prompt warning to ensure that you'd better use the related MSBuild version to build the project. It is designed as a reminder message.
But in fact, MSBuild does add backward compatibility feature.
The message is just a warning rather than an error and will not break the build process. And if it breaks the build process, it can prove that backward compatibility is not supported.
You can test it: use VS2019 to build a VS2017 or VS2015 projects and I am sure that it can built them successfully.
==============================================
Each version of VS creates a project that is built for the corresponding MSBuild version.
For example, in the project created in VS2010, its ToolsVersion="4.0", so when you use MSBuild from VS2010(msbuild v4.0), it will built without that warning.
VS2013-->ToolsVersion=12.0 , VS2015-->ToolsVersion=14.0 , VS2017-->ToolsVersion=15.0, VS2019--> ToolsVersion=Current
So when you build the project, you should try the related msbuild version to build them.
Although MSBuild supports backwards compatibility, the problem is always in the form of a warning, which has been troubling us during the project migration.
Solution
To solve it, you should use the related MSBuild to build the project with the corresponding ToolsVersion.
If you want to build them in VS2017, you should change ToolsVersion to 15.0 in every project's xxx.xxproj file.
If you want to build them in VS2019, you should change ToolsVersion to Current in every project's xxx.xxproj file.
More info, you can refer to my answer in this similar issue.
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
I was given some files that were built in Visual Studio 2005 version.
When I tried to convert the .sln file to use in VS 2010 Express C++, however, I run into problems.
The error gives out the path and says that the file was not found even though the file is there. I know there shouldn't be any compatibility issues between the two unless I am missing something. Has anyone run into this type of problems?
The exact error message is:
"Conversion Report - GeoM\GeoM.vcproj: Converting project file
'C:\Users...\GeoM\GeoM.vcproj'. File 'C:\Users...\GeoM\GeoM.vcproj' was not found. \
Project upgrade failed.
The most likely explanation is that your C++ project has been configured to support compilation for a platform other than x86 (such as x64 or IA-64).
This is explained on the Visual C++ blog, in the Visual Studio 2010 C++ Project Upgrade Guide:
Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the
corresponding platform installed under '%vctargetspath%\platforms\Itanium'.
Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
Since the Express version does not support compiling C++ applications for either of these platforms, the upgrade wizard is failing to convert your project and returning the described error message.
The only way this upgrade is going to succeed is if you use a full version of Visual Studio (with the appropriate platform compiler tools installed), or if you edit the solution/project files that you have to remove any mention of a non-x86 configuration. You should be able to do this with a simple text editor like Notepad, but as always, back up first in case you destroy something irreplaceable.
I want to start the develop of a custom project type for Visual Studio that builds a BPR project with Visual Studio.
I need some hints to beginning with this project. Where can I find a template for this type of projects?
My target is to remove the Borland C++Builder's ugly and unstable interface from the development process and work enterely from Visual Studio.
Edit: Oops, I didn't really see that you're about to create a new project type for C++ Builder files. In that case, you have to build a language package. The Visual Studio Extensibility site should get you started. Also have a look at this more specific link.
I'll leave my old answer here for reference, because it might help people who just want to build C++Builder projects without creating a whole new project type :)
You didn't specify the version of Visual Studio, but I'll assume a recent one. In Visual Studio 8 and 9, most project files (all popular ones except Visual C++) are actually MSBuild files and can therefore be built by MSBuild. You can add a simple command line task (Exec) to build your bpr on the command line, or you can create a custom task for this (if you don't find one already available - the search terms should be MSBuild and custom task). This way, both Visual Studio and MSBuild can build anything you like. If you don't have an MSBuild file to start with or want to dive into developing a task, the MSBuild project template for Visual Studio will help you.
Oh, and other than that, if you don't actually need C++Builder things, you might as well export the BPR as a solution (or create a new solution and add the files).
Integrating C++Builder projects into a build process should be a lot easier with C++Builder 2007 or 2009 as both use MSBuild as build system. But then, I think that upgrading to a recent version of C++Builder solves your problem the other way :)