Home Dashboard Directory Help
Search

In-place upgrade breaks backward compatibility by JAlexandrian


Status: 

Closed
 as Duplicate Help for as Duplicate


13
0
Sign in
to vote
Type: Bug
ID: 759745
Opened: 8/27/2012 6:02:29 AM
Access Restriction: Public
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

After upgrading to VS 2012, the .Net framework was upgraded in-place from 4 to 4.5 (4.0.30319.17929). Using the project properties to target .Net framework 4 does not appear to work as 1 developer was able to introduce a change that works on machines with the upgraded framework, but breaks the app for anyone running the previous .Net Framework 4. The target framework was 4 and not 4.5.

Uninstalling VS 2012 left the upgraded framework.

As a result, our team cannot use VS2012 until all users have been upgraded to 4.5 since the multi-targeting feature is not working.
Details
Sign in to post a comment.
Posted by Kathleen Dollard on 11/21/2012 at 5:51 AM
This was reallly poorly discussed, although everything that was said was correct...

Concerns over breaking changes are real. Googlebing .net 4.5 breaking changs. MS states they have a high priority on solving any non-intentional breaks (bugs).

Many issues will affect you when the target machine is upgraded, so failing to update your dev team and test with the new libraries is a bad idea.

However, the design is that the new features are blocked by Visual Studio when you target an older framework, and the common set of functionality is all that is available when using portable libraries. If this has any issues, they should be reported as bugs.
Posted by JAlexandrian on 9/11/2012 at 1:56 PM
This really is unfortunate. If Microsoft won't address this, then our entire team cannot upgrade to VS2012 until our enterprise has deployed .Net 4.5 everywhere, otherwise we can accidentally introduce code that uses new 4.5 libraries that are not backward compatible. That type of bug can be very difficult and time-consuming to track down in an application (no repro). So, we will be sticking with VS2010. Especially since Simone said "...and there's lots of them."

We had problems like this with the SP1 for .Net 3.5. When new features are added in libraries that overwrite the previous version, it's very difficult to know if a user's machine can make use of that feature even if they are running the right version of the .Net framework.
Posted by Vaccanoll on 9/7/2012 at 11:08 AM
>>This is actually unfortunately by design.

Not to sound too harsh, but this was a poor design then.
Posted by Simone Busoli on 9/5/2012 at 9:56 AM
This is actually unfortunately by design. Although you keep targeting 4.0 you are using new libraries, old ones don't exist anymore on your machine as they've been upgraded. Multi-tatgeting indeed works as it's supposed to work and just prevents you from being able to use new assemblies/types/members introduced in 4.5, but you'll get the changes in the behaviors which have been introduced to libraries that already existed in 4.0, and there's lots of them.
Posted by Microsoft on 8/29/2012 at 11:54 PM
Thanks for your feedback. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 8/27/2012 at 8:00 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project to demonstrate this issue so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 8/27/2012 at 11:52 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.