林业厅网站建设方案,网站建设与网页设计制作绿皮书,比较好的品牌策划公司有哪些,学生可以做的网站兼职MSBuild 的 Task 为我们扩展项目的编译过程提供了强大的扩展性#xff0c;它使得我们可以用 C# 语言编写扩展#xff1b;利用这种扩展性#xff0c;我们可以为我们的项目定制一部分的编译细节。NuGet 为我们提供了一种自动导入 .props 和 .targets 的方法#xff0c;同时还… MSBuild 的 Task 为我们扩展项目的编译过程提供了强大的扩展性它使得我们可以用 C# 语言编写扩展利用这种扩展性我们可以为我们的项目定制一部分的编译细节。NuGet 为我们提供了一种自动导入 .props 和 .targets 的方法同时还是一个 .NET 的包平台我们可以利用 NuGet 发布我们的工具并自动启用这样的工具。制作这样的一个跨平台 NuGet 工具我们能够为安装此工具的项目提供自动的但定制化的编译细节——例如自动生成版本号自动生成某些中间文件等。本文更偏向于入门只在帮助你一步一步地制作一个最简单的 NuGet 工具包以体验和学习这个过程。然后我会在另一篇博客中完善其功能做一个完整可用的 NuGet 工具。关于创建跨平台 NuGet 工具包的博客我写了两篇。一篇介绍写基于 MSBuild Task 的 dll一篇介绍写任意的命令行工具可以是用于 .NET Framework 的 exe也可以是基于 .NET Core 的 dll甚至可以是使用本机工具链编译的平台相关的各种格式的命令行工具。内容是相似的但关键的坑不同。我分为两篇可以减少完成单个任务的理解难度如何创建一个基于 MSBuild Task 的跨平台的 NuGet 工具包如何创建一个基于命令行工具的跨平台的 NuGet 工具包本文内容第零步前置条件第一步创建一个项目用来写工具的核心逻辑第二步组织 NuGet 目录第三步编写 Target第四部调试让我们的 Target 能够正确找到我们新生成的 dll准备一个用于测试 Task 的测试项目让我们自定义的 Task 开始工作并能够进入断点第五步发挥你的想象力.targets 向 Task 传参数Task 向 .targets 返回参数在 Target 里编写调试代码在 Task 输出错误或警告加入差量编译支持本地测试 NuGet 包总结参考资料第零步前置条件第一步创建一个项目用来写工具的核心逻辑为了方便制作跨平台的 NuGet 工具新建项目时我们优先选用 .NET Core Library 项目或 .NET Standard Library 项目。紧接着我们需要打开编辑此项目的 .csproj 文件将目标框架改成多框架的并填写必要的信息。!-- Walterlv.NuGetTool.csproj --Project SdkMicrosoft.NET.SdkPropertyGroup!-- 给一个初始的版本号。 --Version1.0.0-alpha/Version!-- 使用 .NET Framework 4.7 和 .NET Core 2.0。 要点 1 - 加入 net47 的支持是为了能让基于 .NET Framework 的 msbuild 能够使用此工具编译 - 加入 netcoreapp2.0 的支持是为了能让基于 .NET Core 的 dotnet build (Roslyn) 能够使用此工具编译 - 当然 net47 太新了只适用于 Visual Studio 2017 的较新版本如果你需要照顾到更多用户建议使用 net46。 要点 2 注意我们使用 NuGet 包来依赖 Task 框架但此 NuGet 包要求的最低 .NET Framework 版本为 4.6。 如果需要制作 .NET Framework 4.5 及以下版本就必须改为引用以下程序集 - Microsoft.Build - Microsoft.Build.Framework - Microsoft.Build.Tasks.v4.0 - Microsoft.Build.Utilities.v4.0 --TargetFrameworksnet47;netcoreapp2.0/TargetFrameworks!-- 这个就是创建项目时使用的名称。 --AssemblyNameWalterlv.NuGetTool/AssemblyName!-- 此值设为 true才会在编译之后生成 NuGet 包。 --GeneratePackageOnBuildtrue/GeneratePackageOnBuild!-- 作者的 Id如果要发布到 nuget.org那么这里就是 NuGet 用户 Id。 --Authorswalterlv/Authors/PropertyGroup/Project然后安装如下 NuGet 包Microsoft.Build.Framework: 提供了编写 ITask 的框架有了这个才能写 ITaskMicrosoft.Build.Utilities.Core: 提供了 ITask 框架的基本实现这样才能用更少的代码写完 Task要特别注意由于我们是一个 NuGet 工具不需要被其他项目直接依赖所以此项目的依赖包不应该传递到下一个项目中。所以请将所有的 NuGet 包资产都声明成私有的方法是在 NuGet 包的引用后面加上 PrivateAssetsAll。想了解 PrivateAssets 的含义一起相关属性可以阅读我的另一篇文章项目文件中的已知 NuGet 属性使用这些属性创建 NuGet 包就可以不需要 nuspec 文件啦 - 吕毅。ItemGroupPackageReference IncludeMicrosoft.Build.Framework Version15.6.85 /PackageReference IncludeMicrosoft.Build.Utilities.Core Version15.6.85 /PackageReference Update(PackageReference) PrivateAssetsAll //ItemGroup接下来就是取名字的时间了为 Class1 类改一个名字。这个类将成为我们这个 NuGet 工具包的入口类。比如我们想做一个用 Git 提交信息来生成版本号的类可以叫做 GitVersion想做一个生成多语言文件的类可以叫做 LangGenerator。在这里为了示范而不是真正的实现功能我取名为 DemoTool。取好名字之后让这个类继承自 Microsoft.Build.Utilities.Task// DemoTool.csusing Microsoft.Build.Utilities;namespace Walterlv.NuGetTool{public class DemoTool : Task{ public override bool Execute() { return true;}}}这时进行编译我们的 NuGet 包就会出现在项目的输出目录 bin\Debug 下了。第二步组织 NuGet 目录刚刚生成的 NuGet 包还不能真正拿来用。事实上你也可以拿去安装不过最终的效果只是加了一个毫无作用的引用程序集而已顺便还带来一堆垃圾的间接引用。所以我们需要进行“一番配置”使得这个项目编译成一个NuGet 工具而不是一个依赖包。现在介绍一下 NuGet 预设的目录如果你想看可以去解压 .nupkg 文件// 根目录用来放 readme.txt 的已经有人提 issue 要求加入 markdown 支持了 /// 用来放引用程序集 .dll文档注释 .xml 和符号文件 .pdb 的 lib/// 用来放那些与平台相关的 .dll/.pdb/.pri 的 runtimes/// 任意种类的文件在这个文件夹中的文件会在编译时拷贝到输出目录保持文件夹结构 content/// 这里放 .props 和 .targets 文件会自动被 NuGet 导入成为项目的一部分要求文件名与包名相同 build/// 这里也是放 .props 和 .targets 文件会自动被 NuGet 导入成为项目的一部分要求文件名与包名相同 buildMultiTargeting/// PowerShell 脚本或者程序在这里的工具可以在“包管理控制台”(Package Manager Console) 中使用 tools/▲ 以上结构可以去官网翻阅原文 How to create a NuGet package - Microsoft Docs不过我这里额外写了一个预设目录 buildMultiTargeting官方文档却没有说。注意到我们的 csproj 文件中的 TargetFrameworks 节点吗如果指定为单个框架则自动导入的是 build 目录下的如果指定为多个框架则自动导入的是 buildMultiTargeting 目录下的。我们的初衷是做一个 NuGet 工具所以我们需要选择合适的目录来存放我们的输出文件。我们要放一个 Walterlv.NuGetTool.targets 文件到 build 和 buildMultiTargeting 文件夹中以便能够让我们定制编译流程。我们要让我们写的 dll也就是那个 Task能够工作但是以上任何预定义的文件夹都不能满足我们的要求于是我们建一个自定义的文件夹取名为 tasks这样 NuGet 便不会对我们的这个 dll 进行特殊处理而将处理权全部交给我们。于是我们自己的目录结构为 build/- Walterlv.NuGetTool.targets buildMultiTargeting/- Walterlv.NuGetTool.targets tasks/ net47/- Walterlv.NuGetTool.dll netcoreapp2.0/- Walterlv.NuGetTool.dll- readme.txt那么如何改造我们的项目才能够生成这样的 NuGet 目录结构呢我们先在 Visual Studio 里建好文件夹随后去编辑项目的 .csproj 文件在最后的 /Project 前面添加下面这些项!-- Walterlv.NuGetTool.csproj --ItemGroupNone IncludeAssets\build\** PackTrue PackagePathbuild\ /None IncludeAssets\buildMultiTargeting\** PackTrue PackagePathbuildMultiTargeting\ /None IncludeAssets\readme.txt PackTrue PackagePath //ItemGroupNone 表示这一项要显示到 Visual Studio 解决方案中其实对于不认识的文件None 就是默认值Include 表示相对于项目文件的路径支持通配符Pack 表示这一项要打包到 NuGetPackagePath 表示这一项打包到 NuGet 中的路径。(如果你想了解更多 csproj 中的 NuGet 属性可以阅读我的另一篇文章项目文件中的已知 NuGet 属性使用这些属性创建 NuGet 包就可以不需要 nuspec 文件啦 - 吕毅) 后来的我们 主演井柏然 / 周冬雨 / 田壮壮 猫眼电影演出 广告 购买 这样的一番设置我们的 build、buildMultiTargeting 和 readme.txt 准备好了但是 tasks 文件夹还没有。由于我们是把我们生成的 dll 放到 tasks 里面第一个想到的当然是修改输出路径——然而这是不靠谱的因为 NuGet 并不识别输出路径。事实上我们还可以设置一个属性 BuildOutputTargetFolder将值指定为 tasks那么我们就能够将我们的输出文件打包到 NuGet 对应的 tasks 文件夹下了。至此我们的 .csproj 文件看起来像如下这样为了减少行数我已经去掉了注释!-- Walterlv.NuGetTool.csproj --Project SdkMicrosoft.NET.SdkPropertyGroupVersion1.0.0-alpha/VersionAssemblyNameWalterlv.NuGetTool/AssemblyNameGeneratePackageOnBuildtrue/GeneratePackageOnBuild!-- ↓ 新增的属性 --BuildOutputTargetFoldertasks/BuildOutputTargetFolder!-- ↓ 新增的属性 --NoPackageAnalysistrue/NoPackageAnalysis!-- ↓ 新增的属性 --DevelopmentDependencytrue/DevelopmentDependencyAuthorswalterlv/Authors/PropertyGroupItemGroupPackageReference IncludeMicrosoft.Build.Framework Version15.6.85 /PackageReference IncludeMicrosoft.Build.Utilities.Core Version15.6.85 /!-- ↓ 在第一步中不要忘了这一行 --PackageReference Update(PackageReference) PrivateAssetsAll //ItemGroupItemGroupFolder IncludeAssets\tasks\ //ItemGroupItemGroup!-- ↓ 新增的三项 --None IncludeAssets\build\** PackTrue PackagePathbuild\ /None IncludeAssets\buildMultiTargeting\** PackTrue PackagePathbuildMultiTargeting\ /None IncludeAssets\readme.txt PackTrue PackagePath //ItemGroup/Project注意到我同时还在文件中新增了另外两个属性配置 NoPackageAnalysis 和 DevelopmentDependency。由于我们没有 lib 文件夹所以 NuGet 会给出警告NoPackageAnalysis 将阻止这个警告。DevelopmentDependency 是为了说明这是一个开发依赖设置为 true 将阻止包作为依赖传递给下一个项目。事实上这又是官方的一个骗局因为新版本的 NuGet 竟然去掉了这个功能已经被吐槽了详见PackageReference should support DevelopmentDependency metadata · Issue #4125 · NuGet/Home。关于这些属性更详细的解释依然可以参见项目文件中的已知 NuGet 属性使用这些属性创建 NuGet 包就可以不需要 nuspec 文件啦 - 吕毅。现在再尝试编译一下我们的项目去输出目录下解压查看 nupkg 文件你就能看到期望的 NuGet 文件夹结构了建议一个个点进去看你可以看到我们准备好的空的 Walterlv.NuGetTool.targets 文件也能看到我们生成的 Walterlv.NuGetTool.dll。第三步编写 Target.targets 文件是对项目功能进行扩展的关键文件由于安装 NuGet 包会自动导入包中的此文件所以它几乎相当于我们功能的入口。现在我们需要徒手编写这个文件了。!-- Assets\build\Walterlv.NuGetTool.targets --ProjectPropertyGroup!-- 我们使用 $(MSBuildRuntimeType) 来判断编译器是 .NET Core 的还是 .NET Framework 的。 然后选用对应的文件夹。--NuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) Core$(MSBuildThisFileDirectory)..\tasks\netcoreapp2.0\/NuGetWalterlvTaskFolderNuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) ! Core$(MSBuildThisFileDirectory)..\tasks\net47\/NuGetWalterlvTaskFolder/PropertyGroupUsingTask TaskNameWalterlv.NuGetTool.DemoTool AssemblyFile$(NuGetWalterlvTaskFolder)\Walterlv.NuGetTool.dll /Target NameWalterlvDemo BeforeTargetsCoreCompileDemoTool //Target/Projecttargets 的文件结构与 csproj 是一样的你可以阅读我的另一篇文章 理解 C# 项目 csproj 文件格式的本质和编译流程 - 吕毅 了解其结构。上面的文件中我们指定 Target 的执行时机为 CoreCompile 之前也就是编译那些 .cs 文件之前。在这个时机我们可以修改要编译的 .cs 文件。如果想了解更多关于 Target 执行时机或顺序相关的资料可以阅读Target Build Order。别忘了我们还有一个 buildMultiTargeting 文件夹也要放一个几乎一样功能的 targets 文件不过我们肯定不会傻到复制一个一样的。我们在 buildMultiTargeting 文件夹里的 targets 文件中写以下内容这样我们的注意力便可以集中在前面的 targets 文件中了。!-- Assets\buildMultiTargeting\Walterlv.NuGetTool.targets --Project!-- 直接 Import 我们在 build 中写的那个 targets 文件。 NuGet 留下了为多框架项目提供特殊扩展的方案其实有时候也是很有用的。--Import Project..\build\Walterlv.NuGetTool.targets //Project第四部调试严格来说写到这里我们的跨平台 NuGet 工具已经写完了。在以上状态下你只需要编译一下就可以获得一个跨平台的基于 MSBuild Task 的 NuGet 工具。只是——你肯定会非常郁闷——心里非常没谱这工具到底有没有工作起来有没有按照我预期的进行工作如果遇到了 Bug 怎么办于是现在我们来掌握一些调试技巧这样才方便我们一步步完善我们的功能嘛额外插一句以上第一到第三步几乎都是结构化的步骤其实非常适合用工具来自动化完成的。让我们的 Target 能够正确找到我们新生成的 dll你应该注意到我们的 targets 文件在 Assets\build 目录下而我们的 Assets 文件夹下并没有真实的 tasks 文件夹里面是空的。于是我们希望在调试状态下dll 能够指向输出目录下。于是我们修改 targets 文件添加配置!-- Assets\build\Walterlv.NuGetTool.targets --ProjectPropertyGroup Condition $(IsInDemoToolDebugMode) True NuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) Core$(MSBuildThisFileDirectory)..\..\bin\$(Configuration)\netcoreapp2.0\/NuGetWalterlvTaskFolderNuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) ! Core$(MSBuildThisFileDirectory)..\..\bin\$(Configuration)\net47\/NuGetWalterlvTaskFolder/PropertyGroupPropertyGroup Condition $(IsInDemoToolDebugMode) ! True NuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) Core$(MSBuildThisFileDirectory)..\tasks\netcoreapp2.0\/NuGetWalterlvTaskFolderNuGetWalterlvTaskFolder Condition $(MSBuildRuntimeType) ! Core$(MSBuildThisFileDirectory)..\tasks\net47\/NuGetWalterlvTaskFolder/PropertyGroupUsingTask TaskNameWalterlv.NuGetTool.DemoTool AssemblyFile$(NuGetWalterlvTaskFolder)\Walterlv.NuGetTool.dll /Target NameWalterlvDemo BeforeTargetsCoreCompileDemoTool //Target/Project这样我们就拥有了一个可以供用户设置的属性 IsInDemoToolDebugMode 了。准备一个用于测试 Task 的测试项目接着我们在解决方案中新建一个调试项目 Walterlv.Debug我选用了 .NET Standard 2.0 框架。然后在它的 csproj 中 Import 我们刚刚的 .targets 文件并设置 IsInDemoToolDebugMode 属性为 True!-- Walterlv.Debug.csproj --Project SdkMicrosoft.NET.SdkPropertyGroupTargetFrameworknetstandard2.0/TargetFrameworkIsInDemoToolDebugModeTrue/IsInDemoToolDebugMode/PropertyGroupImport Project..\Walterlv.NuGetTool\Assets\build\Walterlv.NuGetTool.targets //Project当准备好基本的调试环境之后我们的解决方案看起来是下面这样的样子让我们自定义的 Task 开始工作并能够进入断点最简单能够让 DemoTool 这个自定义的 Task 进入断点的方式当然是加上 Debugger.Launch(); 了就像这样// DemoTool.csusing System.Diagnostics;using Microsoft.Build.Utilities;namespace Walterlv.NuGetTool{public class DemoTool : Task{ public override bool Execute() { // 新增了启动调试器的代码。Debugger.Launch(); return true;}}}这样一旦此函数开始执行Windows 将显示一个选择调试器的窗口我们选择当前打开的 Visual Studio 即可。当然也有一些比较正统的方法为了使这篇文章尽可能简单我只附一张图如果有需要可以自己去尝试现在我们去 Walterlv.Debug 目录下输入 msbuild 命令在输出到如下部分的时候就会进入我们的断点了这下我们的调试环境就全部搭建好了你可以发挥你的想象力在 Task 里面随意挥洒你的代码当然只要你记得去掉 Debugger.Launch();或者加上 #if DEBUG 这样的条件编译那么随时打包就是一个可以发布的跨平台 NuGet 工具包了。提示一旦调试环境搭建好你可能会遇到编译 Walterlv.NuGetTool 项目时发现 dll 被占用的情况这时打开任务管理器结束掉 msbuild.exe 进行即可。第五步发挥你的想象力想象力是没有限制的不过如果不知道 Task 能够为我们提供到底什么样的功能也是无从下手的。这一节我会说一些 Task 在 C# 代码和 .targets 文件中的互相操作。.targets 向 Task 传参数.targets 向 Task 传参数只需要写一个属性赋值的句子就可以了!-- Assets\build\Walterlv.NuGetTool.targets --Target NameWalterlvDemo BeforeTargetsCoreCompileDemoTool IntermediateOutputPath$(IntermediateOutputPath) //Target这里$(IntermediateOutputPath) 是 msbuild 编译期间会自动设置的全局属性代表此项目编译过程中临时文件的存放路径也就是我们常见的 obj 文件夹。当然使用 dotnet build 或者 dotnet msbuild 也是有这样的全局属性的。我们为 DemoTool节点也加了一个属性名为 IntermediateOutputPath。在 DemoTool 的 C# 代码中只需要写一个字符串属性即可接收这样的传参。// DemoTool.cspublic class DemoTool : Task{public string IntermediateOutputPath { get; set; } public override bool Execute() {Debugger.Launch(); var intermediateOutputPath IntermediateOutputPath; return true;}}▲ 在断点中我们能够看到传进来的参数的值你可以尽情发挥你的想象力传入更多让人意想不到的参数实现不可思议的功能。更多 MSBuild 全局参数可以参考我的另一篇文章项目文件中的已知属性知道了这些就不会随便在 csproj 中写死常量啦 - 吕毅。Task 向 .targets 返回参数如果只是传入参数那么我们顶多只能干一些不痛不痒的事情或者就是两者互相约定了一些常量。什么你说直接去改源代码那万一你的代码不幸崩溃了项目岂不被你破坏了当然你去改了源码还会破坏 MSBuild 的差量编译。我们新定义一个属性但在属性上面标记 [Output] 特性。这样这个属性就会作为输出参数传到 .targets 里了。// DemoTool.csusing System.Diagnostics;using System.IO;using Microsoft.Build.Framework;using Microsoft.Build.Utilities;namespace Walterlv.NuGetTool{public class DemoTool : Task{ public string IntermediateOutputPath { get; set; }[Output] public string AdditionalCompileFile { get; set; } public override bool Execute() {Debugger.Launch(); var intermediateOutputPath IntermediateOutputPath; var additional Path.Combine(intermediateOutputPath, DoubiClass.cs);AdditionalCompileFile Path.GetFullPath(additional);File.WriteAllText(AdditionalCompileFile, using System; namespace Walterlv.Debug { public class Doubi { public string Name { get; } private Doubi(string name) Name name; public static Doubi Get() new Doubi(吕毅); } }); return true;}}}然后我们在 .targets 里接收这个输出参数生成一个属性!-- Assets\build\Walterlv.NuGetTool.targets --Target NameWalterlvDemo BeforeTargetsCoreCompileDemoTool IntermediateOutputPath$(IntermediateOutputPath)Output TaskParameterAdditionalCompileFile PropertyNameWalterlvDemo_AdditionalCompileFile //DemoToolItemGroupCompile Include$(WalterlvDemo_AdditionalCompileFile) //ItemGroup/Target这样我们生成的 Walterlv.Debug 调试项目在编译完成之后还会额外多出一个“逗比”类。而且——我们甚至能够直接在 Walterlv.Debug 项目的中使用这个编译中生成的新类。使用编译生成的新类既不会报错也不会产生警告下划线就像原生写的类一样。如果你要在编译期间替换一个类而不是新增一个类例如将 Class1.cs 更换成新类那么需要将其从编译列表中移除!-- Assets\build\Walterlv.NuGetTool.targets --ItemGroupCompile RemoveClass1.cs /Compile Include$(WalterlvDemo_AdditionalCompileFile) //ItemGroup需要注意编译期间才生成的项ItemGroup或者属性PropertyGroup需要写在 Target 节点的里面。如果写在外面则不是编译期间生效的而是始终生效的。当写在外面时要特别留意可能某些属性没有初始化完全你应该只使用那些肯定能确认存在的属性或文件。在 Target 里编写调试代码虽然说以上的每一个步骤我都是一边实操一边写的但即便如此本文都写了 500 多行了如果你依然能够不出错地完成以上每一步那也是万幸了Task 里我能还能用断点调试那么 Target 里面怎么办呢我们可以用 Message 节点来输出一些信息!-- Assets\build\Walterlv.NuGetTool.targets --Target NameWalterlvDemo BeforeTargetsCoreCompileDemoTool IntermediateOutputPath$(IntermediateOutputPath)Output TaskParameterAdditionalCompileFile PropertyNameWalterlvDemo_AdditionalCompileFile //DemoToolMessage Text临时文件的路径为$(WalterlvDemo_AdditionalCompileFile) /ItemGroupCompile Include$(WalterlvDemo_AdditionalCompileFile) //ItemGroup/Target在 Task 输出错误或警告我们继承了 Microsoft.Build.Utilities.Task此类有一个 Log 属性可以用来输出信息。使用 LogWarning 方法可以输出警告使用 LogError 可以输出错误。如果输出了错误那么就会导致编译不通过。加入差量编译支持如果你觉得你自己写的 Task 执行非常耗时那么建议加入差量编译的支持。关于加入差量编译可以参考我的另一篇文章每次都要重新编译太慢让跨平台的 MSBuild/dotnet build 的 Target 支持差量编译。本地测试 NuGet 包在发布 NuGet 包之前我们可以先在本地安装测试。由于我们在 C:\Users\lvyi\Desktop\Walterlv.NuGetTool\Walterlv.NuGetTool\bin\Debug输出路径下已经有了打包好的 nupkg 文件所以可以加一个本地 NuGet 源。我们找一个其他的项目然后在 Visual Studio 中设置 NuGet 源为我们那个 NuGet 工具项目的输出路径。这时安装编译完之后我们就会发现我们的项目生成的 dll 中多出了一个“逗比(Doubi)”类并且可以在那个项目中编写使用 Doubi 的代码了。总结不得不说制作一个跨平台的基于 MSBuild Task 的 NuGet 工具包还是比较麻烦的我们总结一下准备项目的基本配置设置各种必要的项目属性安装必要的 NuGet 依赖建立好 NuGet 的文件夹结构编写 Task 和 Target新增功能、调试和测试如果你在实践的过程中遇到了各种问题欢迎在下面留言一般我会在一天之内给予回复。如果在阅读这篇文章时存在一些概念理解上的问题或者不知道如何扩展本文的功能可能需要阅读下我的另一些文章理解 C# 项目 csproj 文件格式的本质和编译流程 - 吕毅项目文件中的已知属性知道了这些就不会随便在 csproj 中写死常量啦 - 吕毅项目文件中的已知 NuGet 属性使用这些属性创建 NuGet 包就可以不需要 nuspec 文件啦 - 吕毅当然还有一些正在编写过一段时间可以阅读到。参考资料NuGet pack and restore as MSBuild targets - Microsoft DocsBundling .NET build tools in NuGetShipping a cross-platform MSBuild task in a NuGet packageMSBuild Reserved and Well-Known Propertiesbuild process - How does MSBuild check whether a target is up to date or not? - Stack OverflowHow to: Build IncrementallyHow To: Implementing Custom Tasks – Part I – MSBuild Team BlogOverwrite properties with MSBuild - Stack OverflowHow to Access MSBuild properties inside custom taskvisual studio - How to get property value of a project file using msbuild - Stack Overflowdavidfowl/NuGetPowerTools: A bunch of powershell modules that make it even easier to work with nuget[MSBuild and Skipping target “ because it has no outputs - Stack Overflow](https://stackoverflow.com/questions/27377095/msbuild-and-skipping-target-targetname-because-it-has-no-outputs)WriteCodeFragment TaskDon’t include dependencies from packages.config file when creating NuGet package - Stack OverflowNuGet 2.7 Release Notes - Microsoft DocsPackageReference should support DevelopmentDependency metadata · Issue #4125 · NuGet/Homedebugging - How to debug MSBuild Customtask - Stack Overflow本文会经常更新请阅读原文 https://walterlv.github.io/post/create-a-cross-platform-msbuild-task-based-nuget-tool.html 以避免陈旧错误知识的误导同时有更好的阅读体验。原文地址: https://walterlv.github.io/post/create-a-cross-platform-msbuild-task-based-nuget-tool.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com Reward 长按二维码向我转账 受苹果公司新规定影响微信 iOS 版的赞赏功能被关闭可通过二维码转账支持公众号。
