Is it possible to build a Debugging Visualizer that can be used in multiple versions of Visual Studio?
A Debugging Visualizer has to reference Microsoft.VisualStudio.DebuggerVisualizers.dll and there is a separate version of the assembly for every version of Visual Studio. It seems that these versions are not compatible. For example, if I built a visualizer that references Microsoft.VisualStudio.DebuggerVisualizers v9.0, it can be used in Visual Studio 2008, but not in Visual Studio 2010.
I am looking for a way to target at least Visual studio 2008 and Visual Studio 2010 while maintaining only one project for the visualizer. Duplicating the project and changing only references to Microsoft.VisualStudio.DebuggerVisualizers will work, but it creates a maintenance horror.
If your code base is exactly the same for both referenced assemblies then I would suggest the same approach as I've suggested in this question: Visual Studio Installer -- Change application resource
The idea is to have 1 project where you will have a MSBuild property which VS to target and depending on this property you may reference either VS 2008 or VS 2010 DebuggerVisualizers assembly.
The only other solution I see is the one you've mentioned - having 2 separate project files to target different VS version. I do not think it will be that difficult to maintain two versions if you will not duplicate code. And you can avoid duplicating code by including code files as links into your projects.
Related
Is there any way that I can use the latest IDE (VS2015) to work with my old solution project but i don't wish to upgrade my project?
Unfortunately, you cannot do this. The format of project and solution files was changed in VS 2010, so the furthest back you could possibly go with VS 2015 would be to VS 2010.* And that wouldn't help you any for cross-compatibility, since VS 2008 can't open VS 2010 project files.
You have no real choice but to allow the IDE to convert your solution and project files to the latest version. However, this will not delete your old VS 2008 project/solution files. They will still be in the solution directory, and will still work for opening the solution in VS 2008. The new project/solution files will open the solution in VS 2015.
This was a very common strategy employed by open-source projects before recent versions of Visual Studio implemented cross-compatibility. They would just have multiple versions of project and solution files for each supported version of Visual Studio.
The only disadvantage with this is that changes you make to one version of a project or solution file don't propagate to the others automatically. But this isn't really that big of a deal, since once a project is reasonably mature, the project and solution files don't change very often.
* In fact, VS 2015 interoperates smoothly with project/solution files from VS 2013, VS 2012, and VS 2010 SP1. It can create and modify project files for any of these versions. See MSDN: Porting, Migrating, and Upgrading Visual Studio Projects (for Visual Studio 2015)
Now that Visual Studio 2015 RC is out, has anyone installed it and opened Visual Studio 2013 projects/solutions?
Does it ask the files to be changed?
If yes, are the changes it makes backward compatible?
Take a look at the Porting, Migrating, and Upgrading Visual Studio Projects article for Visual Studio 2015. All of the various caveats are described there.
Not all types of project are supported. I tried the following 4 project types:
Vb.net Class project, OK.
Vb.net Web Services project, OK.
Cordova JS project, not OK, need to migrate manually, by moving the sources from root directory to the www directory and install all API again.
C#.net winform project, OK.
Yes, though you sometimes will have to change the version (single number) in .sln file, no other differences found yet.
We resolved this by typically excluding this file from check in and only check it in when there really was a change (added project, ...) - and then to fix the version before checking in. (Different developer machines with different versions of VS.)
See question Visual Studio 2015 solutions backwards compatibility with Visual Studio 2013 and answer https://stackoverflow.com/a/31540590/586754.
(Assuming you are having basic projects that are supported by both versions, like C# and .net framework that is supported by lower version VS.)
Background
I am open sourcing a few old Visual Studio applications I created a while back. I have created new solutions using my new VS2012 environment for them and have gotten the projects set up as git repositories. I got everything working fine in Visual Studio 2012 with no changes to the source code, all I needed to do was make sure I was linking the proper libraries in the new project configurations.
I would like to configure these projects as to have maximum compatibility for others downloading the project from Github. On this machine I have VS2010 installed alongside the latest VS2012 version. After I got everything working right for both of the projects in VS2012, I tried to open them up in VS2010.
When I tried to build I got a single error:
Specified platform toolset (v110) is not installed or invalid.
Please make sure that a supported PlatformToolset value is selected.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets 518
What I Tried
So I opened up the properties for the project, went to Configuration Options --> General and the Platform Toolset was indeed set to Visual Studio 2012 (v110). This input is a drop down box and the v110 value is not listed, instead I get two choices:
v100
v90
These correspond to VS2010 and VS2008 respectively. If I change the value to v100 and rebuild I get no errors and my program runs just fine in my Visual Studio 2010 environment.
When I open the project back up in Visual Studio 2012, if tells me that I have an old project file and asks if I want to upgrade, I say yes and it upgrades. I rebuild and run to make sure everything is still working. When I open the configuration options in VS2012 the Platform Toolset is set back to `Visual Studio 2012 (v110) but clicking the drop down input there are several more choices listed:
Visual Studio 2012 (v110)
v110_wp80
Visual Studio 2012 - Windows XP (v110_xp)
Visual Studio 2010 (v100)
Visual Studio 2008 (v90)
‹inherit from parent or project defaults›
My Questions
This has led me to several questions. I am going to pose them all. It would be nice to get as much information as I can, but a good answer to just one of them would probably solve my problem.
If I'm not using features specific to newer versions of Visual Studio, is it possible to set up a solution which can be opened and run without modification in as many versions as possible (ie. 2008, 2010, or 2012)? If so, how?
If I set the Platform Toolset to v90 (VS2008) from within Visual Studio 2012, and it's able to build and run, does this mean that it will build and run for users with VS2012, VS2010, and VS2008?
What exactly does the <inherit for parent or project defaults> option do? What would the project defaults be set up as? Can this be used to tell Visual Studio to try to using whichever installed Platform Toolset will work.
Are there any other options besides Platform Toolset in Visual Studio that I can set to increase compatibility with others' development environments?
This is a somewhat tricky situation. One of the underlying problems here is that VS2010 and VS2012 use MSBuild to build C++ projects, but VS2008 farmed it out to VCBuild instead. You can see this by comparing the project files. VS2010/VS2012 use .vcxproj, while VS2008 uses .vcproj.
If I'm not using features specific to newer versions of Visual Studio,
is it possible to set up a solution which can be opened and run
without modification in as many versions as possible (ie. 2008, 2010,
or 2012)? If so, how?
For maximum compatibility, you want to target the lowest common denominator (i.e. vc90 in this case). Note that when you do the upgrade, the solution file and project files get upgraded to the latest version, which may break compatibility with older versions of Visual Studio.
If I set the Platform Toolset to v90 (VS2008) from within Visual
Studio 2012, and it's able to build and run, does this mean that it
will build and run for users with VS2012, VS2010, and VS2008?
Not really, due to the .vcxproj / .vcproj conflict stated above.
For example, I currently have a set of .vcxproj files and a solution designed for VS2010. I use VS2012 as my IDE, so when I open the VS2010 solution in VS2012, I choose to NOT upgrade it and simply open it as is. VS2012 and beyond should be backwards compatible back to VS2010 as far as project files go.
For maximum compatibility in development environments, my recommendation would be use VS2010's solution as the baseline, targeting v100. Developers can use any version newer than that and it should all work together gracefully.
We currently use TFS 2010 and have numerous build definitions for our various version of our software. We want to use VS2012 for our next version(still using TFS 2010) so is it possible to have both versions of VS on a build controller and will the build process know which version of VS to use or will we need one build controller for VS2010 and one for VS2012? Also I have custom build templates will that present any issues? Then what happens when we upgrade to TFS 2012? will we be able to run automated builds using both VS2010 and VS2012??
In general - yes. Actually Visual Studio doesn't build anything. It's the underlying MSBuild engine that handles the build tasks.
Furthermore, you can setup a build machine without Visual Studio at all, provided that your project don't hold direct references to Visual Studio references paths (e.g. C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies). If there are such references you can copy them to your 3rd party\lib directory in the source control and have the projects refer to that directory as file references.
Other notes:
But Visual Studio will hardly be your biggest hindrance. It's
multi-targeting .NET that will require some extra caffeine :)
The build templates will work as long as you satisfy their custom
references (GAC can used for that matter)
A build controller can be registered with one server at a time
Use a build server for each target framework\VS version
This is easily one of the most annoying "features" of Visual Studio in its history and I don't understand why it exists -- ever.
Why would a CodePlex project need to care what version of Visual Studio I am using?
Off the top of my head, the only thing I can think of is that some versions of Visual Studio might introspect assemblies searching for attributes to determine what to display in "Visual Designers" and "Property Editors". But why would that cause Visual Studio to not be able to open the project and allow me to browse its contents and compile?
It seems to me like Open Source in .NET is somewhat limited by the stupid dependency management exhibited by Visual Studio. In other words, if I am using Visual Studio 2008 and you are using Visual Studio 2010, then we have different solution files.
http://blogs.msdn.com/b/visualstudio/archive/2010/03/15/why-does-visual-studio-2010-convert-my-projects.aspx
Here's an example from the site as to why Visual Studio converts your projects to 2010 format.
For instance, Visual Studio runs
custom tools such as single file
generators for designers in order to
output code representing the changes
made to the designer. Many of these
custom tools are upgraded or
completely replaced in the newer IDE.
During conversion, the IDE knows which
custom tools to replace or upgrade. In
order to make round-tripping work, VS
would need old and new custom tools to
understand each other so as to ensure
that old and new designers can work
side by side. Other than designers,
the following files would also be
affected: resource editors, wizards,
code snippets, item and project
templates, diagramming and modeling
tools, and many more.tools, and many more.
Since 2010 knows about what tools 2008 has, it can convert forward to be compatible with the custom tools 2010 uses. 2008 has no idea about what 2010 is using, how could it? Therefore, it is impossible to convert backwards since it doesn't know what it needs to convert, nor how to.
I believe the purpose of this touches on what you stated in your comments. If you are using 2008 and I 2010 and I compile it, how could you possibly run it again? 2010 is backwards compatible but 2008 has no way to make itself forward compatible.
Thus, by recompiling the project in 2010 I ensure that no 2008 user may mistakenly think they can compile it.