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.
Related
Relates to Error while using Qt in Visual Studio 2019
I have the same error. Unfortunately I cannot still fix it, as Qt VS Tools for VS 2015 aren't updated. But my question is not how to avoid background build.
My question: what is background build?
Oh, I believe you are running into the 32767 names for this.
Let me preface this by stating that 2015 may have been the last time I used Visual Studio or developed anything for a Microsoft platform.
Part of your answer is in this discussion.
I believe the latest (or more current) name for "background build" is "live code compilation."
This is a resource robbing, highly annoying, syntax checking thing Microsoft thought would be great. It ranks right up there with Microsoft Clippy as far as tragic ideas go.
Basically, as you type, visual studio tries to build your stuff, puts squiggles under errors and generally consumes a whole lot of resources.
If you are using that Qt plug-in to build a QMake project this can cause all kinds of hardship, especially when you have UI files that need to MOC compile and are in the designer modifying the .UI file.
Whatever version of Visual Studio I was forced to use for that project, the first thing I did was find out how to turn that off.
Qt appears to not play well with Visual Studio it seems.
Here is a more complete description if you happen to have the plug-in.
BuildOnSave is an extension for Visual Studio 2019 and 2017 that
builds the current solution as soon a file is saved, and in
combination with the the extension SaveAllTheTime, enables a live,
background build experience while you type.
I am using Visual Studio 2015, but I have to show my project from Visual Studio 2013 pc, Is it harmful for solution file? or any file? Visual Studio 2015 have some extra feature, that cant's contain Visual Studio 2013. Now how can I solve it?
I want to recommend not to mix different versions of Visual Studio. Please strictly create different folders for different versions e.g . one for VS2013 and another for VS2015.
You know - different versions installed on one PC is possible.
If you really want to go one version back to show your VS2015 project in a VS2013 IDE make sure you have a backup in a safe place. You maybe warned - don't make the mistake of mixing code versions when you switch from one PC to another.
Try to open and show for your needs in your special development environment by yourself it is possible but be careful like mentioned above. Having used the highest dotnet version possible in VS2015 you'll get errors.
We have a large solution (112 projects) in VS2013 Ultimate.
I love the Code Map feature, however when I am dragging types onto a Code Map dgml it insists on building the solution - even though I have not made any changes.
I can't see many options for this great feature, but is there anyway to tell it to stop building the solution everytime I add a type to the diagram?
This is a known issue and major complaint with Code Map in Visual Studio 2013. It affects certain types of projects (like ASP.NET ones) more than others because these projects always report that they have changes and need to be rebuilt.
The experience is improved in Visual Studio 2015 Enterprise, as we have added a "skip build" option.
We've made many improvements to CodeMap in Visual Studio 2015, so it's definitely worth getting it if you use Code Maps. Note that you can install VS 2015 along side VS 2013, so you don't have to migrate projects etc.
I see the code map document window in VS 2015 now contains a button labelled "Skip Build" which seems to solve this problem
I recently installed Visual Studio 2013 Ultimate version on my machine. I'm just trying to create a sample windows form project and trying to open the designer / form by double clicking on Form1.cs and I'm getting this weird error message:
"the service microsoft.visualstudio.shell.interop.iselectioncontainer already exists in the service container"
My system is already having Visual Studio 2010 which is working smoothly from a long time. I then installed Visual Studio 2012 which was giving the same problem as above. So I went ahead with installing VS 2013 hoping that I might be able to get rid of this issue, but no use.
Once I click OK on the error windows, I can see the following "message" in the bottom Error List window:
"The file 'C:\Users\ABCD\Documents\Visual Studio 2013\Projects\WebSite1\WindowsFormsApplication1\Form1.cs' does not support code parsing or generation because it is not contained within a project that supports code."
I have spent 2-3 days searching various blogs like these, all of which talk about previous version of Visual Studio like VS 2005 / VS 2008:
https://connect.microsoft.com/VisualStudio/feedback/details/311949/the-service-microsoft-visualstudio-shell-interop-iselectioncontainer-already-exists-in-the-service-container
Form inheritance in Visual Studio 2008 doesn't work
I have even tried uninstalling and reinstalling VS 2013, again no use.
It would be really great if someone can help me out in fixing this.
I've just had the exact same error message.
After compiling the solution(F6 or Build->Build Solution) it worked fine for me.
To deal with your issue, please first make sure that you installed latest updates on your Windows 8 machine, and then repair VS2013.
During your repairing process, please temporally turn off your anti-virus/antispyware software and repair VS2013 with the Administrator privilege.
follow this link
The problem got resolved finally, after so many days and various frustrating tries to resolve the issue. I should thank Tim Atkins from Microsoft for helping me with resolving this issue.
Fix: When we tried 'gacutil /l system.design', we found that there were 3 variants of system.design; One from .Net 2.0 targetting MSIL, second from .Net 4.0 targetting x86 and last one also from .Net 4.0, but targetting MSIL.
On a working machine, there were only 2 entries, the .Net 4.0 one targetting x86 wasn't there. Hence we uninstalled this version using gacutil which did the magic. I was so relieved seeing the win forms popping up without any errors anymore :)
I changed the target framework from 4.5 to 4.6.1 and it fixed it for me. My assumption is sometimes when you change target framework back and forth and the process does not go through all the way (cancelling in the middle of changing it) - something happens that leads to this error. Hope that helps
I solved this be closing VS, deleting contents of the .vs folder where my solution is, restarting VS and recompiling.
Seems like one of those file/settings/caching problems that pop up now and then, might be after switching source branch.
VS2019, .net fw 4.6.2.
If your C drive (Where you are installing Visual Studio) does not have enough space, try moving some files from the C drive to another drives.
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.