@RealBboy360: Dammit, stop comparing LINQ to ORMs. It's not about ORMs! It may be used in ORM type things like LINQ to SQL, but my whole point is that gave devs an entirely inaccurate appreciation for what LINQ is really. And it's best described by Bart De Smet, IMNSFHO, or Matthew Podwysocki (http://weblogs.asp.net/podwysocki/archive/2008/10/13/functional-net-linq-or-language-integrated-monads.aspx) or Erik Meijer. So get the "cheevo" of finally groking monads.
Nov 13, 2013 at 10:00 AM
@felix9: Awesome. Very little information about this so far. They should have that blog post up ASAP. Telling us that native C# exists, but little else, is really a bloody tease.
Good to know, but not a feature I need.
If you haven't already found it, this link might help.
Usually in a situation like this I go nuclear and uninstall and re-install for both version of VS rather than trying to upgrade/patch.
Thanks, I did look at that, but it didn't help.
As for the round-tripping feature - it's so that one may develop using the latest version, but still allow other devs to use older versions if they haven't upgraded. It's the best decision MS made for getting new releases adopted more quickly - and more beta testers.
Also, there are some project templates (i.e. BizTalk 2013) that haven't been made available to VS2013 yet, and will probably lag at least 6 months behind, which would basically force us to stay on VS2012 only with every project, instead of just the two that can't be upgraded because there is no template for it, and miss out on the latest C++ compiler and libraries. Alternatively we could use multiple versions of VS, with just the two projects in VS2012, and the rest in VS2013.
EDITED for clarity.
Yes it is. Which I thought was kinda strange.
However, I found a workaround. I changed the VCTargetsPath value, in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\12.0\11.0, to "$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))" and it all works perfectly now. VS2012 still creates v110 and builds fine, by default, then upgrading in VS2013 and going back to VS2012 now builds fine. So VS2012 property sheets are referring to the V120 property sheets.
Weird. I don't know why this stopped working after upgrading to VS2013, but maybe I did something to screw it up later when I was trying to fix something else.
Thanks for your help cbae.
No such warning is presented to me. I get only this:
Review Project And Solution Changes
Upgrade VC++ Compiler and Libraries
The following project(s) uses an earlier version of the Visual c++ compiler and libraries. The project(s) will be upgraded to
use the Microsoft Visual Studio 2013 compiler and libraries. Any managed or native code project(s) using c++/cLl extensions
will be automatically upgraded to target NET Framework 4.5. Note: If you do not upgrade the project(s), building your
project(s) will require the corresponding version of Visual Studio to be installed.
Plus I am sure that this built fine only 2 days ago. :S
I have no problem creating new projects in VS2012 and building. If you have VS2012 and VS2013 side-by-side, the steps to repro are:
1. Create a new C++ Win32 console application in VS2012.
2. Build solution successfully.
3. Close the solution.
4. Open the solution in VS2013; when prompted, choose to upgrade the C++ compiler and libraries.
5. Build the solution in VS2013 successfully.
6. Close the solution.
7. Open the solution in VS2012.
8. Build the solution - fails with "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets(44,5): error MSB8020: The builds tools for v120 (Platform Toolset = 'v120') cannot be found. To build using the v120 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Install v120 to build using the v120 build tools."
What I was thinking is that you could add this (if it doesn't exist):12
This would add VCTargetsPath12 to version 11.0 of VS (i.e. VS2012).
Good idea, but it didn't work. I just tried adding it to both the 64-bit and 32-bit registry nodes.