缩短的MSBuild格式是否与旧的.NET版本兼容？

问题描述：

与以前的版本相比，Visual Studio 2017时使用的MSBuild文件可以大大缩短。如所解释的，例如in a blogpost：缩短的MSBuild格式是否与旧的.NET版本兼容？

为了使MSBuild格式清晰可读，删除了很多样板配置。

事实上，当你创建一个新的.NET标准的项目，产生的.csproj文件只包含几行默认：

<Project Sdk="Microsoft.NET.Sdk"> 

    <PropertyGroup> 
    <TargetFramework>netstandard1.4</TargetFramework> 
    </PropertyGroup> 

</Project>

当创建在同一VS正常的.NET Framework项目，不过，.csproj文件仍将只要前面，拥有一些<PropertyGroup>和<ItemGroup>元素，引用一些默认的BCL组件的调试设置定义等

肤浅的测试由爱德手动缩短源代码以例如瞄准.NET Framework 2.0似乎没有导致任何问题（至少，不是错误消息）。不过，我现在想知道：可以使用缩短的MSBuild格式来定位其他/旧的框架版本，而不是.NET Standard？

这并不是那么简单，项目类型很重要。项目文件可以包含与msbuild有关的特定项目项目和与IDE相关的元素。像SubType，DependentUpon，DesignTime，HintPath，Content，Generator等东西。所以对于Winforms，WPF和商店应用程序来说，这是一件非常困难的事情。 –

@HansPassant：好的，也许我的问题听起来有点太绝对了。我可以添加引用，项目组，并且逐个文件包含诸如SubType，DependentUpon等元素，以支持例如编译WPF文件 - 只要我可以放弃Debug和Release版本的属性组的显式定义。 –

答

是的，您可以使用此语法来驯服任何受支持的平台。它只给你一些额外的默认值。

但是，某些功能可能会丢失 - 如设计师对经典EF，ASP.NET和WPF的支持。虽然这些项目应该编译，但您可能会遇到一些困难，需要自定义msbuild hack才能使其工作。

但是，如果你只是编写库，控制台应用程序/ windows服务，你应该没问题。

如果您想使用CLI编译，您至少需要定位.NET 4.如果您定位的是较低版本，例如net35该项目将仅在windows或mono的msbuild上使用开发人员命令提示符下的msbuild进行编译。

即使对于便携式目标，也存在一些解决方法。例如，Netwonsoft.Json最近从具有共享c＃源文件的多个csproj和sln文件的复杂设置移动到single consolidated csproj file that multitargets to many frameworks。

“自定义msbuild黑客” - 由此，你的意思是添加''元素（或类似的，与他们各自的子元素）为几个需要特殊待遇的文件，或更麻烦？ “如果你想使用dotnet CLI进行编译（...），项目只能使用msbuild进行编译” - 实际上，到目前为止我还没有意识到这两个选项。但是，这意味着什么 - 使用'msbuild'来编译关于手头的问题还是有问题，或者一些目标框架只能用一个编译，有些只能用另一个命令编译？ –

1.要编译.net

1.这意味着我限制了可以构建源的环境集合，同时扩展了稍后可以执行我的程序集的环境集合？如果是这样，那对我来说听起来不错。这听起来也很有用，而且还比为不同的目标框架维护几个并行项目文件要好得多。 –

缩短的MSBuild格式是否与旧的.NET版本兼容？

相关推荐