This isn't an important question, but something that has been bothering me for awhile and my google-fu wasn't able to find an answer.
I know that Visual Studio 2013 is version 12 and Visual Studio 2012 is version 11.
Why did Microsoft make the icon for VS2013 solutions have 12 in it (their version number). And VS2012 solutions have 11 in it (again the version number)? VS2010 solutions correctly has 10 in the icon, even though the file format says its version 11.
Now this might just be on my machine(s) because I have multiple versions of VS installed (and editions), but it is just something that makes my head itch.
The numbers correspond to the internal version numbers of various editions of Visual Studio
Visual Studio 6.0 (1998)
Visual Studio .NET (2002) = version 7
Visual Studio .NET 2003 = version 7.1
Visual Studio 2005 = version 8
Visual Studio 2008 = version 9
Visual Studio 2010 = version 10
Visual Studio 2012 = version 11
Visual Studio 2013 = version 12
Visual Studio 2015 = version 14
The number on the icon indicates the version that the project or solution is compatible with.
this info is taken from :
Wikipedia_VS_Version history
Though the question is old, it is a general question on its own.
I was wandering to get a meaningful answer (because I wondered too) and get here only to find an incomplete one. Not satisfied and tried an editing trick on ".sln" file to get the answer.
At first, it is easy to find version numbering on Microsoft's own pages or wikipedia etc. Now the thing is having that number on "the sln file icon". That would be the answer to this question if I had asked it.
Open the sln file with a text editor as its content is mere text. Now the "format version" part on the first line is relevant to the content of the file, so not relevant to answer. The version number on the second line for VS version "# Visual Studio 15" is the thing what gives the file its icon. Changing the number and saving the file is immediate to change the number on the icon. Currently, 10,11,14 and 15 versions are supported it seems. By the way, if you have a line of "VisualStudioVersion", you need to delete it before saving to see the effect.
But be careful: even though you may change the icon, if the content format is not right, VS will complain about the solution. Don't forget to revert the changes back. And also this part gives a clue that you can write your own solution file in a text editor.
As to "why bother!!" of the question, an answer would be to recognize a solution version by look before opening it in the VS. You may have an older version of the file which possibly has incompatibilities in the project files inside, thus you can decide to do some adjustments by hand before opening it in your installed VS version.
PS: I once thought the "10" in the icon is "IO" for "input/output" terminology and wondered what "15" might be as I read it to be "IS". Found this Q/A, not satisfied and tried to improve. If you like, don't forget to give up vote.
Related
The title of this question probably seems a bit convoluted so let me explain it in more detail.
I work for a company that has recently requested that all their pre-VS2013 Projects and Solutions be upgraded to VS2013. During my initial upgrade tests I noted that some of the solutions prompted for an Upgrade to be functionally sound under VS2013.
These Solutions/Projects typically launched the Migration Wizard and presented the message that non-functional changes to the Project were required to run under VS2013 and as long as there were no errors present afterward, the Projects compiled and ran without any issue.
While there were other VS2012 Solutions/Projects that displayed no dialogs whatsoever and simply ran under VS2013 without issue.
My initial presumption was since the latter mentioned Projects weren't identified by VS2013 as having any components that required alteration for the upgrade; that they were simply upgraded behind the scenes, compiled without error and simply ran.
But after a short conversation with the Company Supervisor and a peek at the Solution files, it appears that those Solutions are still configured for VS2012 and not VS2013.
Below are a few lines of code from each Solution File:
VS2013 Solution File
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.30110.0
VS2012 Solution File
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
As you can see the VS2012 Solution File indicates # Visual Studio 2012 while the VS2013 Solution File shows # Visual Studio 2013 with an additional line appended to the file stating VisualStudioVersion = 12.0.30110.0
So the real question/concerns here regarding this migration effort are:
Is there any way to FORCE a VS2012 project to VS2013 as opposed to simply opening the project/solution under VS2013
Are there any potential caveats that should be taken into consideration when at some point VS2012 becomes outdated/deprecated by Microsoft? E.g. If tomorrow VS2012 were to become obsolete would there be potential areas of concern for these types of Projects running in a Production Environment?
The targeted goal is to have all our Projects and Solutions migrated to and running under VS2013 for continuity of the environment and simply do away with any Pre-VS2013 items.
Thanks
The ability to open projects created in earlier VS versions without converting them was first added to VS2012. By popular demand, moving to a new VS version could be pretty painful if not all members of a team migrated at the same time.
There is no point about fretting about this, VS2013 just doesn't have any trouble opening and saving projects like this. Nor does it have a way to force the conversion. In the olden days it could be done by running devenv.exe with the /upgrade option. Not sure if that still works, you'd have to try. I've seen SO users recommending editing the project file, I do not think that's a good idea.
It will automatically prompt you for an upgrade when you add any feature that wasn't supported in a previous release. Hard to come up with examples of that for VS2013, beyond Windows Phone 8.0 projects, VS2013 is a relatively minor increment from VS2012.
I am using Visual Studio 2013 on a solution where all c++ projects have platform toolset of Visual Studio 2012 - Windows XP. I cannot upgrade them for compatibility reasons with the rest of the developers. However, the string "(Visual Studio 2012 - Windows XP)" is added to all project names in solution explorer and generates a lot of clutter in my eyes.
Is there any way to hide it? I know that all projects are of this platform. I don't need VS to tell me :)
Yes, there is a way to do this. It involves editing some files that maybe shouldn't be edited, and it's likely unsupported and may mess up your installation, but as long as you back up the modified files you should be able to revert if anything bad happens. That's the warning.
That said, I've tried this and it worked for me without any issues (that I'm aware of) and I do believe the procedure is safe as it mainly relates to cosmetics (although it might break future upgrades).
If you installed VS2013 in the default location you should have a file called Microsoft.Cpp.Default.props in the directory C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
This file contains, among other things, information on how (some of the) the installed platform toolsets are displayed in the project property pages and what string (if any) is added to the project name in the solution explorer.
The rows with properties called something like _PlatformToolsetShortNameFor_v120_xp control the string that is shown in the solution explorer (in this case the 2013 - xp toolset), and the rows with properties called something like _PlatformToolsetFriendlyNameFor_v120_xp control what's shown in the project property page.
As the Visual Studio 2013 - Windows XP (v120_xp) toolset by default didn't show anything extra in the solution explorer I added a row for:
<_PlatformToolsetShortNameFor_v120_xp Condition="'$(_PlatformToolsetShortNameFor_v120_xp)' == ''">LOLZ I Changed This - Visual Studio 2013 - Windows XP (v120_xp)</_PlatformToolsetShortNameFor_v120_xp>
and also modified the _PlatformToolsetFriendlyNameFor_v120_xp like this:
<_PlatformToolsetFriendlyNameFor_v120_xp Condition="'$(_PlatformToolsetFriendlyNameFor_v120_xp)' == ''">OH MY - Visual Studio 2013 - Windows XP (v120_xp)</_PlatformToolsetFriendlyNameFor_v120_xp>
And the results were this:
and this:
To hide the string that gets appended to the project name in the solution explorer simply remove or comment out the corresponding PlatformToolsetShortNameFor. Since it's an xml-file you comment using <!-- and -->
For a couple of weeks now I have been unable to merge Views within Visual Studio 2013 in response to conflicts when getting Source Code from Visual Studio Team Services. I am sure I used to be able to this (we recently moved from Visual Studio Professional 2012 so I cannot be one hundred percent certain - automerging may have been sufficient in the early days of the project).
The "Accept Merge" and move to next change/conflict buttons are all greyed out and inoperable. See screenshot snippet-
This originally only happened with Views, but now seems to affect some other classes. Changes are highlighted and indicated on the scroll bar so the diff tool otherwise appears to be functioning. This only originally affected me, but now affects a new colleague into the team.
I can still either Keep Local Version or Take Server Version but this is rarely sufficient. This leaves me manually altering the local copy to apply changes highlighted by the merge tool. (Edit - See a better workaround in "Second Update" below).
Has anyone come across this before?
Visual Studio 2013 Premium (patch RTM/Update 1/Update 2 - all with the same problem), with Resharper 8.2 (originally 8.0.2) C# and Web Essentials installed. Running on Windows 7 Professional x64.
Project is ASP.NET 4.5 using MVC 5.1.2 (now additionally updated from MVC 5 where the problem first occurred) (upgraded from MVC 4 following the upgrade instructions on the ASP.NET website) in C#, using latest versions of Razor (3.1.2) and Entity Framework (6.1.0 RTM).
Edit: Initially a repair install of Visual Studio 2013 appeared to have fixed the issue. It has now however returned exactly as it was before. Since it took an hour to do the repair I cannot repeatedly do this in order to merge views. I am currently able to round trip the solution between Visual Studio 2012 Update 4 and Visual Studio 2013 in order to do merges in Visual Studio 2012 where it is working normally.
Second Edit: I am currently manually resolving conflicts by selecting the desired code (local/server), saving the merge window and then closing it which will prompt to accept the merge result. This seems to function but is obviously sub-optimal. It may however be helpful for other users.
In the event, installing Resharper 8.1 on top of 8.02 appears to have fixed it fixed it briefly before the problem returned yet again. I had previously completed a repair install of Visual Studio Premium 2013 as well - which briefly seemed to have fixed it before it broke again. I only mention it in case the fix is cumulative.
I am unclear if it was a bug in Resharper that was somehow preventing the merge, or a persistent problem with the installation that the upgrade cleaned up (Resharper removes previous versions and then installs updates, rather than attempting to install over the top). Update - I am extremely confident that this is not related to ReSharper and that it was the configuration of Visual Studio as a result of re-installing the extension and not the extension itself that fixed the issue.
In either case, the issue (for now) seems to have disappeared and this seems to be related to the upgrade, or is an extremely strong co-incidence.
Colleagues with the same versions of Visual Studio and Resharper, working on the same project, the same version of Windows and (in one case) the same hardware were not affected, so it seems likely it is an edge case niche issue caused by corrupted data somewhere.
I have a current working theory that this is related to different patch versions of Visual Studio (for example Visual Studio 2012 Update 2, Visual Studio 2013 RTM, Visual Studio 2013 Update 1, Visual Studio 2013 Update 2. This only affects Visual Studio 2013 for us.
Simple solution I use is carry on with your manual merge process once you are done simply Close the Merge-* tab (the one you are using to merge files) this will bring up a prompt for confirming if you want to Save the changes made (this is the merge changes you made to your local file) click 'yes' Now it comes back to Resolve Conflicts tab and brings up another prompt asking if you want to Accept Merge Result, click 'yes'(this is same as the button Accept Merge)
Since you have VS2012 installed and merge is working there, you can create a link to its TF.exe in VS2013, similar to one on the picture below, and fix the issues there. Set Command to c:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\TF.exe and Arguments to resolve.
You do that in Tools->External Tools.
I have installed Visual Studio 2012 (aka 11) and uninstalled 2010. However I noticed that solution (.sln) files show an icon that has a little "10" on it while others have "11", with no seeming pattern. They are all solutions that I started out using in 2010 but have since worked on in 11. Why is this?
EDIT:
I noticed that I if I open the .sln file in a text editor, the "10" icon corresponds to:
Microsoft Visual Studio Solution File, Format Version 11.00
And the "11" icon corresponds to:
Microsoft Visual Studio Solution File, Format Version 12.00
Yes you read that right (!!!)
EDIT:
What if I change the .sln file in the text editor from 11.00 to 12.00? Is that recommended?
From what I've been able to figure out:
If you make any change inside Visual Studio that causes it to change the .sln file (i.e. adding a text file at the solution level, then deleting it, then doing "Save All"), the header of the .sln file will change to:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
and the icon will change to "11".
You can manually change the header if you want and the same thing will happen.
However, the icon and header really don't matter... you can leave it as is and everything will work fine because the file format is the same as VS2010.
I'm not sure what will happen if you change the headers to 12.00 as above and then try to open it in VS2010
Ignore the file format version number. It would have kept in sync with the VS version number, if it wasn't for VS2003, version 7.1. Essentially a major maintenance release for VS2002, the version that first introduced .NET support. So it's off-by-one right now.
The file format versions have increased with every VS release. That caused a lot of pain, when you worked in a team you'd have a pretty big headache if not all of the team members moved to the next version at the same time. Lots of questions about it at SO.
That changed in VS2012, it is the first version of VS that can read and write the solution and project files of the previous version. Which explains what you see, your VS2010 projects just never got converted, even after opening it in VS2012. Nice feature.
I have both Visual Studio 2008 and 2010 installed, side-by-side, and VSLauncher correctly opens 9.0 .sln-s with VS2008 and 10.0 .sln-s with VS2010.
However, whenever it encounters an older .sln (e.g. 8.0), VSLauncher automatically picks Visual Studio 2010.
For various reasons, I would like to choose which VS it should open to convert to, but it blindly opens VS2010. I see that there's RMB > Open With > Microsoft Visual Studio Version Selector, but this doesn't produce a list of installed VS-es that I'd anticipate, it simply launches VS2010.
Is there a way to get the configuration I'm looking for?
Background info:
They were installed in chronological release order
I'm running Windows 7 x64
Both VS-es are 32-bit
I think that the justification for this behavior is:
If you have an "older" project (say VS2005), then no matter which versino of VS you use to open the project, there is going to be a conversion process.
With that in mind, it makes sense to convert to the newest version available. Converting a VS2005 project to VS2010 isn't significantly harder than converting it to VS2008, but you'll have more capabilities once the conversion is complete.
Old versions of Microsoft products eventually don't get supported anymore... I think the policy is to fully support the last 2 versions, and then the previous version for 2 years (or is that 1 year). Not sure the date that VS2010 came out, but support for VS2005 will expire either 1 or 2 years after that... If you convert your VS2005 project to VS2008, you'll have the same pain all over again 1-2 years after the next version of VS comes out.
That said, the real answer to your question is: Get in the habit of opening .SLN files with Notepad, so that you can figure out what version it is. Then open up the correct version of VS and click on File/Open to open the project. It isn't as convenient as double-click, but once you get into the habit, it isn't all that bad.