如何使 CSharpCodeProvider 以 .NET 4.5.0 而不是 .NET 4.6.2 为目标？答案

【问题标题】：How to make CSharpCodeProvider target .NET 4.5.0 instead of .NET 4.6.2?如何使 CSharpCodeProvider 以 .NET 4.5.0 而不是 .NET 4.6.2 为目标？
【发布时间】：2016-10-28 15:07:09
【问题描述】：

我像这样创建一个CSharpCodeProvider：

CSharpCodeProvider  codeProvider        = new CSharpCodeProvider(new Dictionary<string, string>{{ "CompilerVersion", "v4.0" }});
CompilerParameters  compileParameters   = new CompilerParameters(refs.ToArray(), newFile, debugBuild) { WarningLevel = 4 };

我有一个创建 WPF FormattedText 对象的脚本，如下所示：

FormattedText volumeText = new FormattedText(volumeString, Core.Globals.GeneralOptions.CurrentCulture, FlowDirection.LeftToRight, typeFace, SuperDom.Font.Size, ForeColor) { MaxLineCount = 1, MaxTextWidth = renderWidth - 6, Trimming = TextTrimming.CharacterEllipsis };

.NET 4.6.2 添加了一个用于指定 DPI 缩放的新构造函数，并且我们当前使用的方法已弃用。但是，我们的应用程序面向 .NET 4.5.0，这就是我们所支持的全部。但是，在编译我的代码时，我仍然收到以下警告：

Warning: 'System.Windows.Media.FormattedText.FormattedText(string, System.Globalization.CultureInfo, System.Windows.FlowDirection, System.Windows.Media.Typeface, double, System.Windows.Media.Brush)' is obsolete: 'Use the PixelsPerDip override'

没有有效的用例（对我们来说）新的构造函数是有效的，事实上，如果有人试图使用它，我会期望得到一个编译错误，因为该方法签名对于 4.5 不正确。

有没有办法避免这些警告？以前我们没有为代码提供者指定CompilerVersion，但添加它并没有帮助，并且根据我在此处的其他问题中看到的内容，v4.0 是唯一适用于我的案例的有效版本。不同的警告级别会避免这种情况吗？

【问题讨论】：

This question 详细介绍了如何使用 CodeDom 定位不同的框架。不知道今天是否同样的方法适用于 4.5 框架，但这是您的问题，而不是编译器版本。
Hmya，您实际上并不是针对 4.5。借助 VS 安装的“开发人员包”，您可以有意地在您的开发机器上定位旧的 .NET 版本。不适用于 System.CodeDom，您的客户端将无法使用它们。你会得到客户端机器上安装的任何版本，这是不可预测的。确实对 FormattedText 造成了严重破坏，您也不能依赖采用 pixelsPerDip 参数的重载。没有干净的解决方案，您将不得不接受该警告。
@HansPassant 我的项目面向 .NET 4.5。如果我尝试在自己的代码中使用 .NET 4.6.2 中引入的重载，则会出现编译错误。这就是我在编译脚本时想要发生的事情，而不是得到上面不推荐使用的警告。
仅供参考support for 4.5 ended in January，你真的应该看 4.5.2
@lgaud 明白了，但不幸的是这不取决于我

标签： c# wpf

【解决方案1】：

Visual Studio 处理此问题的方式是在编译期间不使用系统程序集。相反，使用了一组引用程序集，其中包含正确的类和方法，但没有实现。 4.5 和 4.6 的参考程序集可能不同，因此在以 4.5 参考程序集为目标时将看不到在 4.6 中添加的特定属性。除非这些参考程序集在运行时系统上可用，否则除了抑制警告之外，没有办法避免警告，例如使用#pragma。

但是如果编译发生在运行时系统上，那么我不得不不同意你的断言：

但是，我们的应用程序面向 .NET 4.5.0，因此新的处理方式无关紧要。

您正在针对 .NET 4.6 程序集编译脚本，因此新的处理方式非常相关。如果您在运行时系统上编译，您可以动态检测新的构造函数是否可用，如果是，则使用它。您的应用程序可能是针对 .NET 4.5 构建的，但您的脚本不是，或者至少并非总是如此。

【讨论】：

我已将我的问题改写为更清楚。我们不希望在我们的脚本中支持 4.6.2 代码，因此我想要的是针对 4.5 编译的脚本。如果有人尝试使用新方法，我预计会出现编译错误。无论是建议的解决方案还是您说无法解决此问题，我都没有关注您的回复。
那么你的脚本是在哪里编译的？在您的系统上，还是在最终用户的系统上？ “脚本”这个名字暗示了后者。您可以找到一种方法在您拥有参考程序集的您自己的系统上进行编译，或者确保用户拥有参考程序集。无论哪种方式，没有什么不可能的，只要确保使用它们。