Targeting .NET Framework 4 when Framework 4.5 is installed

Question

I have VS2010 and VS2012 installed on my computer and had the .NET Framework 4.0 which I then upgraded to .NET Framework 4.5. However, I am still developing apps that need to work on .NET Framework 4.0. The project says that it is targeting .NET Framework 4 (Client Profile) the assemblies even point to .NET Framework 4.0 folder under Referenced Assemblies. The problem comes when I move this application to a machine that only has 4.0 it won't start and come up with errors the immediate problem being an exception resulting from WindowState={Binding WindowState} which you can't do in 4.0 but you can in 4.5. I need this to throw the exception on my development box, why doesn't it? My assumption is that despite my best efforts is that it uses the 4.5 dlls if they exist. How can I make it really use 4.0 without uninstall 4.5?

Update

To repro this install .NET Framework 4.5 and create a WPF project targeting .NET Framework 4.0. Bind the WindowState to a property in a VM or code behind make this property have a public get and private set. .NET Framework 4.5 handles this just fine even when Mode=TwoWay must ignore the set .NET Framework 4 doesn't and throws an exception: "A TwoWay or OneWayToSource binding cannot work on the read-only property 'State' of type...". On the box with .NET Framework 4.5 works like a charm try it on a machine with only .NET Framework 4.0 and it blows up... So any ideas on how to really target 4.0 when 4.5 is installed?

Bug report to MS here: https://connect.microsoft.com/VisualStudio/feedback/details/774694/targeting-net-framework-4-0-when-4-5-doesnt-seem-to-work

Answer 1

This appears to be a bug in .NET Framework 4.5 and it should throw the exception but with .NET Framework 4.5 installed there is no way to have your application run on .NET framework 4.0 it will always use 4.5.

See this reported bug for more info: http://connect.microsoft.com/VisualStudio/feedback/details/773682/wpf-property-with-private-setter-is-updated-by-a-twoway-binding

Answer 2

Time to punt this question. I'm no expert on WPF, don't like it much for exactly these kind of problems, debugging dependency property problems is a nightmare. But I'm pretty convinced you are chasing a ghost. WindowState has been a dependency property all the way back to 3.0, nothing special happened to it in 4.5 that I can see or ever heard of.

You got some kind of error message that nobody can see that convinced you that it had something to do with the binding. I'm from Missouri, the Show Me State. Well, close enough to Wisconsin.

Spend more time working on code that gives you a reliable exception message and stack trace that helps you diagnose errors on the machine you deploy to, the one without a debugger to help you figure out what's going wrong. You do so by writing an event handler for the AppDomain.CurrentDomain.UnhandledException event. Log or display the e.ExceptionObject.ToString() return value. It gives you the exception message and the Holy Stack Trace. If that doesn't help then update your question with what you saw.

Answer 3

You said you can't reproduce this in a test project. So that implies that it may be something that should work fine in 4.0 right? You might have some combination of code that is crashing on a bug in 4.0, that was fixed in 4.5. When you target 4.0, you will only get warnings when you try to use API's/features that the compiler can determine are not supported in 4.0.

Something that should work in 4.0 may crashed due to some rarely seen bug, and then fixed in 4.5. When your 4.0 targeted app runs under 4.5 environment, it will be affected by bug fixes to features that existed in 4.0.

There may be an update for 4.0 that includes the bug fix, so as not to require 4.5 upgrade if users are adverse to that for some reason. So it might not even be a 4.5 change, but simply a coincidence that some users don't have all of the updates available for 4.0(which would have been cumulatively includes in your 4.5).

These kind of cases I've rarely encountered, but do happen sometimes and are the reason people who support desktop .NET applications are notorious for asking users to update there .NET framework as a first try at solving odd issues before spending time troubleshooting.

Sometimes the opposite occurs. Your code only works due to some bug or poor behavior of a .NET API, and later an update cleans this up, perhaps tightening security somewhere is the most often thing I've seen, and your code suddenly breaks due to a minor version update of .NET.

Answer 4

.Net 4.5 replaces .net 4.0 with new, same-named libraries, that actually have some fixes. That's short answer.

Unlike earlier versions, updating .net 4 to 4.5 replaces files, instead of adding sided by side files. Even if you have folder like this Windows/Microsoft.Net/Framework/v40/ , After update, there is a change in this folder. Files are changed, some errors were handled in .net without developer's concern.

How to target 4.0 framework using .net 4.5 ? I still don't know, but I'm still digging

Suggested read on this topic:

Scott Hanselman : http://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx

Rick Strahl: http://weblog.west-wind.com/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40

And similar problem, created by me: https://stackoverflow.com/questions/26483168/errors-on-net-4-0-dont-appear-on-net-4-5

Answer 5

The solution:

I've got the same problem when installed VS2017 after VS2015: Framework 4.0 just disappeared from project target list.

Following some comments around here I've tried with NuGet package: Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.4 and bin fix for 1.0.1.

Don't do that! My build time went ~300% up for the same project. It was disaster.

I see that 4.5 is an "in place replacement" for 4.0 However this does not explain why I cant see both options in my target frameworks combo.

I was reading the same mantra all around the web. It's simply not answer to the problem. Framework 4.0 is a must for any industrial machinery related software - because it runs on Windows XP, while .NET 4.5. is useless in my scenario, and probably for many other real-life stuff.

The solution is simple: You just have to download and install Visual Studio 2013 Express from official web page: https://www.microsoft.com/en-us/download/details.aspx?id=44914

After installing it, just open your VS2015 and you'll see 4.0 again.

... "In place replacement ..." my....

---

This is re-post of answer I gave on a duplicate question. I'm posting here since this thread got more attention and existing answers here give no solution for the issue.