Targeting .NET Framework 4 when Framework 4.5 is installed
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
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.