As you all know the VS 2010 RC is out for MSDN subcribers.
Unfortunately I guess I have the same problem as some of you, in that the company I work for wants to continue keeping our projects on VS 2008.
I would like to know if its possible for me to work with VS 21010, then later convert my projects back to VS2008?
I intend to use v3 of the framework for this particular project.
Thanks in advance..
I've just created a little batch file that will convert between VS2008 and VS2010 (and vice versa) at will.
It rewrites the strings found at http://blogs.msdn.com/rextang/archive/2009/07/06/9819189.aspx between both versions in an automated fashion.
It depends on a kind of project you use. It's absolutely impossible to convert VC++ back from 2010 since they have completely different format and no tools to rollback. However, C# and VB.NET still use the same msbuild project format as in VS2008, which will be changed in the next VS version (Dev11) and so all you need to manage C# or VB.NET project version is the ToolsVersion attribute of the Project element.
VS 2008 C# project version:
<Project DefaultTargets="Build" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
VS 2010 C# project version:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
One of the approaches is to use both project systems simultaneously as our team does. Another one is to use targeting for different .NET frameworks in VS2010 projects. V2010 supports all previous .NET frameworks as targets farmeworks till .NET 2.0
Finally, don't be upset by using VS2008 as it's much faster and reliable.
I think it would be easier to keep the work projects in VS 2k8 and just convert up to VS 2k10 on your end. Of course this means you would have to manually edit back in any changes you make to the solution or project files but you would have to do that either way you go.
Perhaps it would be best if your company invested in utilities (such as SCons or CMake) that are able to generate solution/project files for as many IDE's as you need given a set of metadata so that the companies engineers can use whatever environment they are most comfortable with.
While I think there is an argument to be made for having everyone work in whatever IDE suite they are most comfortable with ultimately productivity will be the deciding factor. If engineer's are spending too much time converting project files back and forth between IDE's, well then having a standardized suite of software is probably the wise choice.
to convert visual studio 2010 solution file (.sln) to visual studio 2008 solution file (.sln) simply follow these steps:
in .sln file replace "Format Version 11.00" to "Format Version 10.00"
in .sln file replace "# Visual Studio 2010" to "# Visual Studio 2008"
in .csproj replace "ToolsVersion=''4.0''" to "ToolsVersion=''3.5''"
in .csproj replace "v10.0" to "v9.0"
Related
I have a Visual Studio 2013 solution, and I would like to make it work with Visual Studio 2005. How can I downgrade the solution file?
I noted this line in the .sln file:
MinimumVisualStudioVersion = 10.0.40219.1
However, changing this line to 8.x.xxxxx.x, lower than my Visual Studio version number, still failed with the same error.
Open the .sln and project files with a text editor, Notepad will do fine. The .sln file is the easier nut to crack, it has not changed much over the years. You'll see something like this at the top of the file:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.21005.1
MinimumVisualStudioVersion = 10.0.40219.1
Followed by a list of the projects and the configurations. The "Format Version" is the most important value, if it is a mismatch with the VS version then it will quickly fail to load the solution. Values are 8.00 = VS2005, 9.00 = VS2008, 10.00 = VS2010, 11.00 = VS2012, 12.00 = VS2013
The lines that mention the VS versions were late additions, first added in VS2012 to support the feature where VS can open old projects without having to upgrade them. Just delete these lines.
Then you'll have to tackle the project files, they are certainly the harder nut to crack. You did not mention the language you are using, it does matter rather a lot.
First off, if this is a C, C++ or C++/CLI project (high likelihood given the request) then stop right now. Versions of Visual Studio prior to VS2010 used a non-standard build system for those languages, driven by the VCBuild.exe build tool. The .vcproj file format was very different and does not resemble the later .vcxproj file format at all. Only re-creating the .vcproj file from scratch is a sane approach.
If it is a .csproj or .vbproj file then you'll have a shot at it. The best way to go about it is to start a new project in VS2005 so the core entries in the file (Project, Import and PropertyGroup items) have a reasonable value. Then copy/paste the ItemGroups from the VS2013 project file. You'll get the correct reference assemblies and source files that way.
As Visual studio doesnt support for downgrade, you can't do it directly or by changing any file, I suggest better way to do is create another project in visual studio 2005 and import all files in it.
You can do this only if you didn't used any higher version libraries in your project than VS2005
Simple answer is that you can't (as far as I am aware). Fastest option would be to create a bank VS2005 solution and project to mimic your existing 2013 version. Then cut / paste the file listing between the two projects until it opens and builds in 2005. You also won't be able to use any functionality greater than .NET 2.0 and/or NuGet, which wasn't around / supported at that time.
VS2013 would have to convert a VS2005 solution / project just to open it, so there isn't really any hope of it going backwards (i.e. VS2005 being happy with a VS2013 solution/project file)
Visual studio project converter does the work for you. We are using it with success for VS2012 => VS2008 downgrades.
But if you have time, I would recommend you to inspect the code of this project and make a custom script in order to do the transformation. This way you can add it with no friction to your continous integration environment.
Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
When I converted a VS 2005 project to VS 2010, with all projects still pointing to compile for the .NET 2.0 Framework, the dlls generated are a totally different file size. Is this normal or something to be concerned about?
The difference in file size is probably due to changes in the compiler shipped with the new version of Visual Studio. In theory, it should be more efficient. It should not be anything to worry about, but that doesn't mean you should forgo testing.
Microsoft does publish information on "Breaking Changes" with the new version of Visual Studio, e.g., http://msdn.microsoft.com/en-us/library/cc714070.aspx for VB, http://msdn.microsoft.com/en-us/library/bb531344.aspx for C++, and http://msdn.microsoft.com/en-us/library/ee855831.aspx for C#.
Some of the old projects in our company are left to be built with VS2005 in autobuild system (making them build correctly in 2010 cost time). Is it any addins for VS2010 that will allow to open VS2005 project and edit it's files without converting project file itself to VS2010 format (converting will kill autobuild)? Of course i can create a separate project named "xxx_vs2010.vcproj" for each of such products, but that will be a mess :(.
No.
An alternative to consider is to target the VS2005 C++ toolchain from within VS2010. See Native Multi-Targeting and the Project Upgrade Guide. That way, no need to modify source code to appease the VS2010 C++ compiler.
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 :)