我的计算机上安装了VS2010和VS2012，并将.NET Framework 4.0升级到.NET Framework 4.5。但是，我仍然在开发需要在.NET Framework 4.0上工作的应用程序。该项目表示，它的目标是.NET Framework 4(客户端配置文件)，程序集甚至指向引用程序集下的.NET Framework 4.0文件夹。当我把这个应用程序移到只有4.0的机器上时，问题就出现了。它不会启动，也不会出现错误。直接的问题是由WindowState={Binding WindowState}引起的异常，这在4.0中是不可能的，但在4.5中是可以的。我需要这个把异常扔到我的开发盒上，为什么不呢？我的假设是，尽管我尽了最大努力，它还是使用了4.5 DLL(如果存在的话)。如何在不卸载4.5的情况下真正使用4.0？

更新

若要重新安装.NET Framework 4.5并创建面向.NET Framework 4.0的WPF项目，请执行以下操作。将WindowsState绑定到VM中的属性或代码隐藏，使此属性具有公共get和私有集。.NET Framework 4.5即使在mode=twoway必须忽略set.NET Framework 4没有的情况下也能很好地处理此问题，并引发异常："twoway或OneWayToSource绑定无法在类型为……"的只读属性"state"上工作。在带有.NET Framework 4.5的盒子中，它的工作方式就像一个符咒，在只有.NET Framework 4.0的机器上试试，它会爆炸…那么，对于如何在安装4.5时真正瞄准4.0有什么想法吗？

在此处向MS报告错误：https://connect.microsoft.com/VisualStudio/Feedback/Details/774694/Targeting-Net-Framework-4-0-when-4-5-doesnot-seep-to-work

这似乎是.NET Framework 4.5中的一个错误，应该引发异常，但安装了.NET Framework 4.5后，就无法在.NET Framework 4.0上运行应用程序了，它将始终使用4.5。

有关详细信息，请参阅此报告的错误：http://connect.microsoft.com/VisualStudio/feedback/details/773682/wpf-property-with-private-setter-is-updated-by-a-twoway-binding

是时候讨论这个问题了。我不是WPF的专家，不太喜欢这种问题，调试依赖属性问题是一场噩梦。但我很确信你在追鬼。从3.0开始，WindowsState一直是一个依赖属性，在4.5中它没有发生任何我能看到或听说过的特殊情况。

你收到了一些错误消息，没有人能看到它，这让你确信它与绑定有关。我来自密苏里州。嗯，离威斯康星州足够近。

花更多的时间处理提供可靠异常消息和堆栈跟踪的代码，这些代码有助于诊断部署到的计算机上的错误，而不使用调试器的代码则有助于找出问题所在。您可以通过为appdomain.currentdomain.unhandledException事件编写事件处理程序来完成此操作。记录或显示e.ExceptionObject.ToString()返回值。它提供异常消息和神圣堆栈跟踪。如果这没有帮助，那么用你看到的更新你的问题。

解决方案：

在VS2015之后安装VS2017时，我也遇到了同样的问题：框架4.0刚刚从项目目标列表中消失。

下面是一些关于nuget包的评论：microsoft.codedom.providers.dotnetcompilerplatform 1.0.4和bin fix for 1.0.1。

不要那样做！对于同一个项目，我的构建时间增长了约300%。那是场灾难。

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.

我在网上读着同样的咒语。这根本不是问题的答案。对于任何与工业机械相关的软件来说，框架4.0都是必须的，因为它运行在Windows XP上，而.NET 4.5。在我的场景中是无用的，可能对许多其他现实生活的东西也是无用的。

解决方案很简单：您只需从官方网页下载并安装Visual Studio 2013 Express：https://www.microsoft.com/en-us/download/details.aspx？ID＝44914

安装后，只需打开VS2015，您将再次看到4.0。

…"就地替换…"我的…

这是我对一个重复问题的回答。我在这里发帖是因为这条线索得到了更多的关注，而这里现有的答案并不能解决这个问题。

.NET 4.5将.NET 4.0替换为新的同名库，这些库实际上有一些修复程序。这是个简短的回答。

与早期版本不同，将.NET 4更新为4.5将替换文件，而不是添加并排文件。即使您有这样的文件夹：windows/microsoft.net/framework/v40/，更新后，此文件夹中有更改。文件被更改，一些错误在.NET中被处理，而开发人员不关心。

如何使用.NET 4.5以4.0框架为目标？我还是不知道，但我还在挖

建议阅读此主题：

斯科特·汉塞尔曼：http://www.hanselman.com/blog/netversioningandmultiptargetingnet45isaninplaceupgradeontet40.aspx

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

以及我提出的类似问题：https://stackoverflow.com/questions/26483168/errors-on-net-4-0-dont-appear-on-net-4-5

你说你不能在测试项目中复制这个。所以这意味着它可能会在4.0中运行良好，对吗？您可能有一些在4.0中崩溃的代码组合，这些代码在4.5中被修复。当您以4.0为目标时，只有当您尝试使用编译器可以确定的API/功能时，4.0中不支持这些功能，才会收到警告。

一些应该在4.0中工作的东西可能由于一些很少看到的错误而崩溃，然后在4.5中修复。当您的4.0目标应用程序在4.5环境下运行时，它将受到对4.0中存在的功能的错误修复的影响。

4.0可能有一个包含bug修复的更新，因此，如果用户出于某种原因对4.5升级不利，则不需要进行升级。因此，这甚至可能不是4.5版本的更改，只是一些用户没有4.0版本的所有可用更新(这些更新将累计包含在您的4.5版本中)的巧合。

我很少遇到这种情况，但有时确实会发生，这也是支持桌面.NET应用程序的人臭名昭著的原因，他们要求用户在.NET框架上进行更新，这是在花时间进行故障排除之前首次尝试解决奇怪问题。

有时会发生相反的情况。您的代码只因.NET API的某些错误或不良行为而起作用，稍后更新会清除此问题，也许在某个地方加强安全性是我见过的最常见的事情，而您的代码由于.NET的次要版本更新而突然中断。