Reading the Source Code of Microsoft.NET.Sdk, Writing the Creative Extension of Compiling

Project node starts to support the Sdk attribute since MSBuild release the 15.0 version which is embedded in Visual Studio 2017. For the Sdk attribute, the C# project file whose file extension is csproj becomes much more powerful and extensible.

We’ll try to read the source code of Microsoft.NET.Sdk which is the default Sdk value of C#.NET project and try to write some creative extension of compiling.

This post is written in multiple languages. Please select yours:

Where to find the source code of Microsoft.NET.Sdk

Search Microsoft.NET.Sdk using Everything or Wox, I find that multiple versions are installed in my computer. As I’ve installed the .NET Core 2.1, the location of my latest version is C:\Program Files\dotnet\sdk\3.0.100-preview6-012264. The official document How to: Reference an MSBuild Project SDK says that if you implement your own Sdk, you can also push it to .

Search Microsoft.NET.Sdk
▲ Search Microsoft.NET.Sdk

The Sdk folder
▲ The Sdk folder on my computer

The NuGet part of Microsoft.NET.Sdk is on GitHub:

The folder structure of Microsoft.NET.Sdk

When clicking into the Microsoft.NET.Sdk folder, we can find that the folder structure is very similar to the NuGet folder structure.

The folder structure of Microsoft.NET.Sdk

I’ve written some posts talking about the NuGet folder structure but unfortunately they are all not in English:

Microsoft have some official document talking about the NuGet folder structure How to create a NuGet package from a convention-based working directory.

But there exists an extra Sdk folder for the Sdk kind of NuGet package.

The extra Sdk folder

The Sdk.props file and the Sdj.targets file will be imported by default and Microsoft’s official document also mentions it here: How to: Reference an MSBuild Project SDK - Visual Studio. It says that the two code blocks are actually the same:

<Project Sdk="Microsoft.NET.Sdk">
    <!-- Implicit top import -->
    <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />


    <!-- Implicit bottom import -->
    <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />

Because of the default importation behavior, Sdk can do variaty of tasks when MSBuild or Roslyn build the .NET projects. The default Sdk Microsoft.NET.Sdk is very extensible so that we can easily use it to customize out compiling behavior and I’ve mentioned these in the two non-English posts above.

The major targets of Microsoft.NET.Sdk

I try to search Target node in the whole Sdk folder and find out 174 Targets. Don’t worry about the huge Target amount because most of them are private by indicating the name with a _ prefix and some of them have the same name to override and wait to be overridden.

So the core compiling Target is not so many and I pick up some core Target here:

Write creative extensions of compiling

I also find some creative Target that inspires me:

<Target Name="DontRestore" BeforeTargets="Restore">
  <Error Text="This project should not be restored" />

▲ If a Restore target exists, then report a compiling error.

<Target Name="ReferenceStaticLegacyPackage" BeforeTargets="CollectPackageReferences">
    <PackageReference Remove="LiteDB" />
    <PackageReference Include="LiteDB" Version="2.0.2" />

▲ This is written by me to prevent a specific package named LiteDB to be upgrade. I post this method in my another non-English post.


本文会经常更新,请阅读原文: ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

如果你想持续阅读我的最新博客,请点击 RSS 订阅,或者前往 CSDN 关注我的主页

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名 吕毅 (包含链接: ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系 ([email protected])