microsoft / msbuildsdks

MSBuild project SDKs

MSBuild SDKs

The MSBuild project SDKs are used to configure and extend your build.

What SDKs are available?

Microsoft.Build.Traversal

Supports creating traversal projects which are MSBuild projects that indicate what projects to include when building your tree. For large project trees, they are replacements for Visual Studio solution files.

Microsoft.Build.NoTargets

Supports utility projects that do not compile an assembly.

Microsoft.Build.Artifacts

Supports staging artifacts from build outputs.

Microsoft.Build.CopyOnWrite

Enables Copy on Write for faster file copies.

Microsoft.Build.RunVSTest

Hooks VSTest to the Test target, allowing running tests concurrently with the build via msbuild /t:Build;Test.

How can I use these SDKs?

When using an MSBuild Project SDK obtained via NuGet (such as the SDKs in this repo) a specific version must be specified.

Either append the version to the package name:

<Project Sdk="Microsoft.Build.Traversal/2.0.12">
  ...

Or omit the version from the SDK attribute and specify it in the version in global.json, which can be useful to synchronise versions across multiple projects in a solution:

{
  "msbuild-sdks": {
    "Microsoft.Build.Traversal" : "2.0.12"
  }
}

Since MSBuild 15.6, SDKs are downloaded as NuGet packages automatically. Earlier versions of MSBuild 15 required SDKs to be installed.

For more information, read the documentation.

What are MSBuild SDKS?

MSBuild 15.0 introduced new project XML for .NET Core that we refer to as SDK-style. These SDK-style projects looks like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>
</Project>

At evaluation time, MSBuild adds implicit imports at the top and bottom of the project like this:

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

msbuildsdks's Issues

binlog file committed to repo

https://github.com/Microsoft/MSBuildSdks/blob/master/src/Traversal/msbuild.binlog

This was likely a mistake and should be removed.

Visual Studio doesn't handle projects using only Microsoft.Build.NoTargets without "upgrading"

Repro
Create an empty solution and a project with a sample file using Microsoft.Build.NoTargets

<!-- test.csproj -->
<Project Sdk="Microsoft.Build.NoTargets">
</Project>

{
  "msbuild-sdks": {
    "Microsoft.Build.NoTargets": "1.0.12"
  }
}

Attempt to add the project via VS.

Expected
VS adds the project and can load it as is

Actual
VS show the "One-way upgrade" dialog and changes the project file to this:

<Project Sdk="Microsoft.Build.NoTargets" ToolsVersion="15.0">
  <PropertyGroup>
    <TargetFrameworkVersion>v2.0</TargetFrameworkVersion>
    <FileUpgradeFlags>
    </FileUpgradeFlags>
    <UpgradeBackupLocation>
    </UpgradeBackupLocation>
    <OldToolsVersion>2.0</OldToolsVersion>
  </PropertyGroup>
</Project>

Traversal builds projects twice when using global properties

ResolveProjectReferences builds projects. This should be disabled in favor of our customized MSBuild task

Microsoft.Build.NoTargets does not import Directory.Build.targets

Failure:

Microsoft.Build.NoTargets does not support Directory.Build.targets. It does however import Directory.Build.props.

Reason:

This is happens because Microsoft.Common.targets is not imported. Microsoft.Common.props is imported.

Fix / Workaround:

You could include Microsoft.Common.targets or you could include the relevant stuff from the common file:

 
 <PropertyGroup>
    <ImportDirectoryBuildTargets Condition="'$(ImportDirectoryBuildTargets)' == ''">true</ImportDirectoryBuildTargets>
  </PropertyGroup>

  <PropertyGroup Condition="'$(ImportDirectoryBuildTargets)' == 'true' and '$(DirectoryBuildTargetsPath)' == ''">
    <_DirectoryBuildTargetsFile Condition="'$(_DirectoryBuildTargetsFile)' == ''">Directory.Build.targets</_DirectoryBuildTargetsFile>
    <_DirectoryBuildTargetsBasePath Condition="'$(_DirectoryBuildTargetsBasePath)' == ''">$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), '$(_DirectoryBuildTargetsFile)'))</_DirectoryBuildTargetsBasePath>
    <DirectoryBuildTargetsPath Condition="'$(_DirectoryBuildTargetsBasePath)' != '' and '$(_DirectoryBuildTargetsFile)' != ''">$([System.IO.Path]::Combine('$(_DirectoryBuildTargetsBasePath)', '$(_DirectoryBuildTargetsFile)'))</DirectoryBuildTargetsPath>
  </PropertyGroup>
  
  <PropertyGroup Condition="'$(ImportDirectoryBuildTargets)' == 'true' and exists('$(DirectoryBuildTargetsPath)')">
    <MSBuildAllProjects>$(MSBuildAllProjects);$(DirectoryBuildTargetsPath)</MSBuildAllProjects>
  </PropertyGroup>

  <Import Project="$(DirectoryBuildTargetsPath)" Condition="'$(ImportDirectoryBuildTargets)' == 'true' and exists('$(DirectoryBuildTargetsPath)')"/>

Exclude Implicit references from Microsoft.Build.CentralPackageVersions?

Would it be possible to add an option to Microsoft.Build.CentralPackageVersions to exclude the implicit package references from requiring a PackageVersion entry?

I'd prefer to let those be managed automatically as they currently are, but still have the control that Microsoft.Build.CentralPackageVersions provides for all the other packages.

dotnet restore doesn't download Microsoft.Build.NoTargets nuget package

<Project Sdk="Microsoft.Build.NoTargets">
  <PropertyGroup>
   <!-- 
      Any target framework you want as long as its compatible 
      with your referenced NuGet packages
     -->
    <TargetFramework>net45</TargetFramework>
  </PropertyGroup>
  
  <Target Name="HelloWorld" AfterTargets="Build">
    <Message Text="Hello World" Importance="High" />
  </Target>
  <ItemGroup>
    <PackageReference Include="Microsoft.Build.NoTargets" />
  </ItemGroup>

</Project>

I have this project file, and when I run dotnet restore (version 15.5.0-preview-007044) I get the following error... am I misunderstanding how this ties together with Nuget?

detailed error

Build started 4/11/2018 5:01:52 PM.
     1>Project "D:\tmp\source\dotnetapp\empty.tsproj" on node 1 (Restore target(s)).
     1>Building with tools version "15.0".
     1>D:\tmp\source\dotnetapp\empty.tsproj : error MSB4236: The SDK 'Microsoft.Build.NoTargets' specified could not be found.
     1>Done Building Project "D:\tmp\source\dotnetapp\empty.tsproj" (Restore target(s)) -- FAILED.

Build FAILED.

       "D:\tmp\source\dotnetapp\empty.tsproj" (Restore target) (1) ->
         D:\tmp\source\dotnetapp\empty.tsproj : error MSB4236: The SDK 'Microsoft.Build.NoTargets' specified could not be found.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.06

[Question] Custom SDK doesn't show under 'Dependencies -> SDK' node in VS

Is this the correct behavior that a custom SDK, like NoTargets doesn't show under the Dependencies -> SDK node in Visual Studio?

Perhaps two points I see:

1. When using a custom SDK and define this like the project XML tag like

<Project Sdk="MyCompany.MyProduct.SDK/2018.1.0-preview3">
...

then we cannot display and update the SDK inside Visual Studio and the NuGet Package Manager. Both don't see and detect the custom SDK.

2. When using a custom SDK and define it with

...
<ItemGroup>
  <PackageReference Include="MyCompany.MyProduct.SDK" Version="2018.1.0-preview3" PrivateAssets="All" />
</ItemGroup>
...

then it be displayed and is updateable from NuGet Package Manager inside Visual Studio.

Set default TargetFramework in NoTargets so projects don't need to specify it

SDK-style project must specify a TargetFramework to load properly in Visual Studio. If the NoTarets SDK specified a TargetFramework, projects would not have to.

One drawback would be picking the default. If the default is net46 but a user happens to consume a package that doesn't support that framework, they'd get a restore error when they aren't even setting a TargetFramework. So we'd need to determine the most compatible target framework or find a way to turn of the compatibility check all together since NoTargets projects don't need it.

Related to #97

[Traversal] build with All.proj fails

We build against an msbuild file All.proj at the root of our repository which looks like this:

<Project Sdk="Microsoft.Build.Traversal/2.0.2">
    <Import Project="Build\Build.proj" />
  <ItemGroup>
    <Dependencies Include="$(RepositoryDir)\Sources\Sources.proj">
      <Binary>True</Binary>
    </Dependencies>    
    <ProjectReference  Include="@(Dependencies)"/>
  </ItemGroup>
</Project>

The projects compile as expected but we get an error at the end of compilation :

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(3430,5): error MSB3491: Could not write lines to file "obj\Win32\Release\All.proj.CoreCompileInputs.cache". Could not find a part of the path 'D:\MyRepo\obj\Win32\Release\All.proj.CoreCompileInputs.cache'

It looks like the targets ResolveAssemblyReferences and _GenerateCompileDependencyCache are running on this file as well. What do you advise?

Users should be able to force CentralPackageVersions to be enabled

In #84 CentralPackageVersions was disabled for projects that don't support PackageReference. However, some users chose to have .nuproj projects in their tree that aren't actually from the NuProj project system. There is currently no way for these users to force CentralPackageVersions to be enabled which is a bug.

CentralPackageVersions: Microsoft.AspNetCore.All should be excluded

Microsoft.AspNetCore.All is a package which isn't implicit but also should not have a version specified.

In the .NET Core SDK if you try to specify a version for this package you get:

warning NETSDK1071: A PackageReference to 'Microsoft.AspNetCore.All' specified a Version of `[2.2.2]`. Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs

But then if you remove the version, you get this from CentralPackageVersions:

error : The package reference 'Microsoft.AspNetCore.All' must have a version defined in '<redacted>\Packages.props'

Location of third party SDK

Hello MSBuild Team,

not sure if i am right here but - I read about your SDK System and was curious if there are any tutorials and so on for writing own Sdks.

Until now I just found out that MSBuild Looks for Sdks in Folder where dotnet.exe is located.
I saw how other Sdks are made and followed them. So was able to create a Sdk.props and Targets file and it worked - very nice and easy to understand. BUT!

The dotnet Folder require admin rights - so are there other Locations it will check?
Before was thinking maybe it checking my ".nuget" Folder but seems it does not.

Thanks for your time and very good work! :D your SDK System is really something makes MSBuild more easy.

Question: does CentralPackageVersions support wildcards

Hi,

I always want to reference the latest version. Does CentralPackageVersion support wildcards?

Thanks,
René

How to specify build order with Microsoft.Build.Traversal?

If I have some .proj file that cannot be referenced by a .csproj file, how can I specify the build order explicitly?

For example:
A.proj generate some cs file that will be used by B.csproj, how can I make A.proj be built before B.csproj? Will MSBuild detect and help me sort them?

Allow loading in VS for .msbuildproj using NoTargets SDK

It's quite common for NoTargets SDK projects to be just MSBuild scripts. Loading and editing these projects in VS would be useful for managing package references as well as editing and building from VS.

Most of this support is already in place as long as the project extension is .msbuildproj (I'm using this in AutoCodeFix, for example). It would be nice if the two lines it takes to make it load in VS were included in the SDK, namely:

<Target Name="CompileDesignTime" />

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\Managed\Microsoft.Managed.DesignTime.targets" Condition="Exists('$(MSBuildExtensionsPath)\Microsoft\VisualStudio\Managed\Microsoft.Managed.DesignTime.targets')" />

CentralPackageVersions not work with APS.NET Core 2.2

Repro Steps

• Create a new sln: dotnet new sln -n MySln
• Create a new project dotnet new console -n MyConsoleApp
• Add that project to the sln: dotnet sln ./MySln.sln add ./MyConsoleApp
• Add the CentralPackageVersions SDK to the .csproj
• Add a reference to Microsoft.AspNetCore
• Create the Packages.props file alongside the .sln
• Build the project

Actual behavior

The package reference 'Microsoft.AspNetCore' must have a version defined in 'C:\Users\keeger\Downloads\PackageTest\Packages.props'.

Adding <PackageReference Update="Microsoft.AspNetCore" /> (without the Version) to the Packages.props does not resolve the problem. Only adding an explicit version as a VersionOverride fixes it.

This is problematic as the .Net docs specify When the version is not specified, an implicit version is specified by the SDK, that is, Microsoft.NET.Sdk.Web. We recommend relying on the implicit version specified by the SDK and not explicitly setting the version number on the package reference.

Expected behavior

Microsoft.AspNetCore can be added to Packages.props without an explicit version.

Central package versions cannot be explicitly enabled for projects that don't support PackageReference

Setting EnableCentralPackageVersions to true should enable central package versions for projects like .nuproj where its disabled by default.

Traversal should prevent FindUnderPath error in Clean

Originally reported in #34

The clean target attempts to look for files in OutDir but OutDir is only set if a Configuration was not specified.

This ends up generating an error. We should either not run clean since traversal projects don't generate outputs or set OutputPath by default.

Microsoft.Build.CentralPackageVersions README seems incomplete

The README for Microsoft.Build.CentralPackageVersions doesn't seem to show how to use this SDK.

It shows how to create the Packages.props file and that you can't have versions for packages in your project files, but the actual Microsoft.Build.CentralPackageVersions SDK doesn't appear to be referenced anywhere in the examples.

What's the correct way to get this working?

NoTargets should disable resource compilation

Resource compilation is enabled by default with Microsoft.NET.Sdk. However, in most cases there are no *.resx files included so it doesn't do anything. NoTargets should disable resource generation since nothing is being compiled in the first place.

Quick start doc

It'd be useful to show how to use these SDKs.

I wanted to use Microsoft.Build.NoTargets so just put that string into the Sdk attribute of my Project, which then gave:

The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.

Detailed Information:
C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\Sdks\Microsoft.Build.NoTargets\Sdk not found. Check that a recent enough .NET Core SDK is installed and/or increase the version specified in global.json.

After some experimentation it seems that this works:

<Project>
  <Sdk Name="Microsoft.Build.NoTargets" Version="1.0.73" />
  ...

However I'm not really sure that's correct. I saw mention of Directory.Build.props in some discussion on the issue tracker, but again it's not clear what to put in that file.

A few additional paragraphs on the root README would be helpful.

Packages.props should not be imported for projects that use packages.config

Projects that use packages.config should not declare any PackageReference items for Visual Studio will not be able to manage the packages in Package Manager. Also, certain project types like VCXPROJ and CCPROJ do not support PackageReference. There is no point in importing the central package versions file for these projects because it could include global references.

Microsoft.Build.CentralPackageVersions does not work on test projects

When Microsoft.Build.CentralPackageVersions is used on test projects, the tests are no longer recognized. It seems that the reference to Microsoft.NET.Test.Sdk does not work.

Anyway to implement "Test on Build" with Traversal?

It seems most dotnet core test projects have a VSTest target and it will start the testing. However, normal projects using "Microsoft.Net.Sdk" have this target as well, is there a way to distinguish them and then invoke VSTest target on right projects?

CentralPackageVersions: ability to import other .props file into Packages.props

Hi,

We want to standardize on a set of versions for the common third party packages we're using across a set of repositories/solutions,
but since each repo should be self-contained, we want to distribute (by copy) a Packages.Common.props into each repo and
import it into Packages.props.

We've tried to:

• <Import Project="Packages.Common.props" /> in the Packages.props file -> error: the package reference 'XXX' must have a version defined in (...)Packages.props
• Set the CustomBeforePackageVersionsProps to $(MSBuildThisFileDirectory)Packages.Common.props in a Directory.Build.props file -> same error as above.

Does anyone know if this should be possible without making changes to the SDK?

Add technology-specific SDK for WPF

See #8 (comment) for context.

VS Manage NuGet Packages support for CentralPackageVersions

When I use the VS buildin Manage NuGet Packages to update package versions, it adds the Version attribute back to the PackageReference instead of modifying the Packages.props file.

This breaks the integration

Add support for Pack target in Microsoft.Build.Traversal

I'm working on replacing solution files with dirs.proj files and I noticed that the Pack target doesn't exist on the dirs.proj file. Any chance you can add support for the Pack target similar to the Build and Test targets?

Add Target to Microsoft.Build.Traversal to generate Visual Studio Solution

As mentioned in the README, the Microsoft.Build.Traversal project files are meant as replacements for solution files. However, AFAIK neither VS or VSCode can open a dirs.proj file and load up the referenced projects as though a solution file was opened. It would be really useful for the user experience to be able to use MSBuild with the dirs.proj file to generate a solution file to work with for VS or VSCode.

What's the difference between Microsoft.Build.NoTargets and just not specifying an Sdk?

Well I can see a difference. I can see that NoTargets actually imports Microsoft.NET.Sdk, but I don't understand why?

One of the examples shows:

<Project Sdk="Microsoft.Build.NoTargets">
  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
    <MyTool>mytool.exe</MyTool>
  </PropertyGroup>

  <Target Name="RunTool" AfterTargets="Build">
    <Exec Command="$(MyTool) -arg1 value" />
  </Target>
</Project>

Why do we need the .NET SDK and to specify the target framework if we are just running a tool?

Traversal projects should specify unique property to identify themselves

We need a unique property like UsingMicrosoftTraversalSdk so that systems can identify when the traversal SDK is in use.

The target "CreateManifestResourceNames" does not exist in the project.

I get this error when I try to build this project:

The target "CreateManifestResourceNames" does not exist in the project.

<Project Sdk="Microsoft.Build.Traversal/2.0.12"  ToolsVersion="15.0">
  <ItemGroup>
    <!-- Build all projects recursively under the "src" folder -->
    <ProjectReference Include="src\**\*.*proj" />
  </ItemGroup>
</Project>

CentralPackageVersions should be disabled for design-time build

For performance reasons, the CheckPackageReferences should not run for design time builds because its relatively expensive and runs for every project.

Add technology-specific SDK for Windows Forms

See #8 (comment) for context.

Not seeing any files in VS when using NoTargets on .njsproj

If I use Sdk="Microsoft.Build.NoTargets/1.0.40" on a .csproj file and open it in VS, I see all the files in the project. However, if I then change the extention to .njsproj (part of NodeJS Tools for VS), the files are no longer included by default.

This is what my project file looks like:

<Project Sdk="Microsoft.Build.NoTargets/1.0.40">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <ProjectGuid>{5b0bd6b6-7b14-4b2a-aef9-e2066fdac8ac}</ProjectGuid>
    <StartWebBrowser>True</StartWebBrowser>
    <SaveNodeJsSettingsInProjectFile>True</SaveNodeJsSettingsInProjectFile>
  </PropertyGroup>
  <Target Name="RunTool" BeforeTargets="Build">
  </Target>
</Project>

Is there a reason it works with .csproj but not .njsproj?

• NTVS Version: 1.4.20907.4
• Visual Studio Version: VS 2017 15.8.5

Project file using NoTargets refuses to load in Visual Studio

Title really says it all. An error dialog says "Project file is incomplete. Project file is missing required imports" but fails to say what those imports are. I am using version 1.0.39 of NoTargets and Visual Studio 15.7.5. Could someone help me out here? Thanks!

NoTargets should set IncludeBuildOutput to false so that Pack task does not attempt to include an assembly

seems like dotnet pack expects an assembly in the output folder which is not generated of course:

error NU5026: Die im Paket einzubeziehende Datei "D:\Temp_Demo\CrossCutting.Build\CrossCutting.Nunit\bin\Debug\netstandard1.1\CrossCutting.Nunit.dll

Allow per project package references that are not centrally managed.

SDK: Microsoft.Build.CentralPackageVersions
Version: 2.0.36

The current behavior of Microsoft.Build.CentralPackageVersions forces the consumer to completely opt-in and have all packages version centrally managed.

It is desirable to have a subset of packages versions be centrally managed, and in the same time have per project packages that are not centrally managed.

For example, one could have Microsoft.Extensions.* packages centrally managed in for all projects in a repo, and at the same time continue to reference packages per project as needed.

A project would look like:

<PackageReference Include="Microsoft.Extensions.Configuration"  /> <!-- Centrally managed -->
<PackageReference Include="Grpc" Version="1.21.0" /> <!-- regular package reference -->

Artifacts item name should be just Artifact

The document references an <Artifact /> item but what's actually in use is <Artifacts />. It is more common for item names to be singular. So the item name should be <Artifact /> which is a breaking change and will require a new major version.

Open custom SDK project in Visual Studio

Is it the expected behavior, that a custom SDK project cannot be opened inside VS?
Or goes something wrong on my machine...

Typo in CentralPackageVersions readme

Since V2 PackageVersion is replaced by PackageReference

On line 11

To get started, you will need to create an MSBuild project at the root of your repository named `Packages.props` that declares `PackageVersion` items.

should be replaced by

To get started, you will need to create an MSBuild project at the root of your repository named `Packages.props` that declares `PackageReference` items.

Microsoft.Build.Traversal: GetNativeManifest and FindUnderPath errors when attempting to build

I'm not sure if this belongs here or MSBuild, but I'm getting the following when attempting to use Traversal as suggested in dotnet/msbuild#1730 (comment):

λ dotnet build PackageBuild.csproj -c Release /p:CI=true
Microsoft (R) Build Engine version 15.6.84.34536 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 60.71 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.EF6\MiniProfiler.EF6.csproj.
  Restore completed in 58.76 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore\MiniProfiler.AspNetCore.csproj.
  Restore completed in 59.64 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\MiniProfiler.AspNetCore.Mvc.csproj.
  Restore completed in 1.66 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Redis\MiniProfiler.Providers.Redis.csproj.
  Restore completed in 0.64 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServerCe\MiniProfiler.Providers.SqlServerCe.csproj.
  Restore completed in 7.52 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Shared\MiniProfiler.Shared.csproj.
  Restore completed in 2.23 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServer\MiniProfiler.Providers.SqlServer.csproj.
  Restore completed in 0.58 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler\MiniProfiler.csproj.
  Restore completed in 4.3 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Sqlite\MiniProfiler.Providers.Sqlite.csproj.
  Restore completed in 26.68 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\MiniProfiler.AspNetCore.Mvc.csproj.
  Restore completed in 27 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\MiniProfiler.AspNetCore.Mvc.csproj.
  Restore completed in 0.85 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Mvc5\MiniProfiler.Mvc5.csproj.
  Restore completed in 2.41 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.EntityFrameworkCore\MiniProfiler.EntityFrameworkCore.csproj.
  Restore completed in 1.62 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MySql\MiniProfiler.Providers.MySql.csproj.
  Restore completed in 7.32 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MongoDB\MiniProfiler.Providers.MongoDB.csproj.
  Restore completed in 2.64 ms for C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.RavenDB\MiniProfiler.Providers.RavenDB.csproj.

  Bundler: Begin processing bundleconfig.json

  Bundler: Begin processing bundleconfig.json

  Bundler: Begin processing bundleconfig.json
  Bundler: Done processing bundleconfig.json
  Bundler: Done processing bundleconfig.json
  Bundler: Done processing bundleconfig.json
  MiniProfiler.Shared -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Shared\bin\Release\netstandard1.5\MiniProfiler.Shared.dll
  MiniProfiler.Shared -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Shared\bin\Release\netstandard2.0\MiniProfiler.Shared.dll
  MiniProfiler.Shared -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Shared\bin\Release\net461\MiniProfiler.Shared.dll
  MiniProfiler.EntityFrameworkCore -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.EntityFrameworkCore\bin\Release\netstandard2.0\MiniProfiler.EntityFrameworkCore.dll
  MiniProfiler.EF6 -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.EF6\bin\Release\net461\MiniProfiler.EF6.dll
  MiniProfiler.Providers.Sqlite -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Sqlite\bin\Release\netstandard1.5\MiniProfiler.Providers.Sqlite.dll
  MiniProfiler.Providers.RavenDB -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.RavenDB\bin\Release\netstandard1.5\MiniProfiler.Providers.RavenDB.dll
  MiniProfiler.AspNetCore -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore\bin\Release\netstandard1.5\MiniProfiler.AspNetCore.dll
  MiniProfiler.Providers.SqlServer -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServer\bin\Release\netstandard1.5\MiniProfiler.Providers.SqlServer.dll
  MiniProfiler -> C:\git\MiniProfiler\dotnet\src\MiniProfiler\bin\Release\net461\MiniProfiler.dll
  MiniProfiler.Providers.MySql -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MySql\bin\Release\net461\MiniProfiler.Providers.MySql.dll
  MiniProfiler.Providers.MongoDB -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MongoDB\bin\Release\net461\MiniProfiler.Providers.MongoDB.dll
  MiniProfiler.Providers.MySql -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MySql\bin\Release\netstandard1.6\MiniProfiler.Providers.MySql.dll
  MiniProfiler.AspNetCore -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore\bin\Release\net461\MiniProfiler.AspNetCore.dll
  MiniProfiler.Providers.RavenDB -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.RavenDB\bin\Release\net461\MiniProfiler.Providers.RavenDB.dll
  MiniProfiler.Providers.MongoDB -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MongoDB\bin\Release\netstandard1.5\MiniProfiler.Providers.MongoDB.dll
  MiniProfiler.Providers.Redis -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Redis\bin\Release\netstandard1.5\MiniProfiler.Providers.Redis.dll
  MiniProfiler.Providers.SqlServer -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServer\bin\Release\net461\MiniProfiler.Providers.SqlServer.dll
  MiniProfiler.Providers.Sqlite -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Sqlite\bin\Release\netstandard2.0\MiniProfiler.Providers.Sqlite.dll
  MiniProfiler.Providers.Redis -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Redis\bin\Release\net461\MiniProfiler.Providers.Redis.dll
  MiniProfiler.Providers.SqlServerCe -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServerCe\bin\Release\net461\MiniProfiler.Providers.SqlServerCe.dll
  MiniProfiler.Providers.Sqlite -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Sqlite\bin\Release\net461\MiniProfiler.Providers.Sqlite.dll
  MiniProfiler.AspNetCore -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore\bin\Release\netstandard2.0\MiniProfiler.AspNetCore.dll
  MiniProfiler.Mvc5 -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Mvc5\bin\Release\net461\MiniProfiler.Mvc5.dll
  MiniProfiler.Providers.MongoDB -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MongoDB\bin\Release\netstandard2.0\MiniProfiler.Providers.MongoDB.dll
  MiniProfiler.AspNetCore.Mvc -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\bin\Release\netstandard2.0\MiniProfiler.AspNetCore.Mvc.dll
  MiniProfiler.AspNetCore.Mvc -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\bin\Release\netstandard1.6\MiniProfiler.AspNetCore.Mvc.dll
  MiniProfiler.AspNetCore.Mvc -> C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\bin\Release\net461\MiniProfiler.AspNetCore.Mvc.dll
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.RavenDB\MiniProfiler.Providers.RavenDB.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Mvc5\MiniProfiler.Mvc5.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.EF6\MiniProfiler.EF6.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MongoDB\MiniProfiler.Providers.MongoDB.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Redis\MiniProfiler.Providers.Redis.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore\MiniProfiler.AspNetCore.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.EntityFrameworkCore\MiniProfiler.EntityFrameworkCore.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.AspNetCore.Mvc\MiniProfiler.AspNetCore.Mvc.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.MySql\MiniProfiler.Providers.MySql.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.Sqlite\MiniProfiler.Providers.Sqlite.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Shared\MiniProfiler.Shared.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServerCe\MiniProfiler.Providers.SqlServerCe.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler.Providers.SqlServer\MiniProfiler.Providers.SqlServer.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\git\MiniProfiler\dotnet\src\MiniProfiler\MiniProfiler.csproj : error MSB4057: The target "GetNativeManifest" does not exist in the project.
C:\Program Files\dotnet\sdk\2.1.104\Microsoft.Common.CurrentVersion.targets(4841,5): error MSB4044: The "FindUnderPath" task was not given a value for the required parameter "Path". [C:\git\MiniProfiler\dotnet\PackageBuild.csproj]

Environment:

λ dotnet --info
.NET Command Line Tools (2.1.104)

Product Information:
 Version:            2.1.104
 Commit SHA-1 hash:  48ec687460

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.104\

Host (useful for support):
  Version: 2.1.0-preview2-26406-04
  Commit:  6833f3026b

.NET Core SDKs installed:
  1.1.7 [C:\Program Files\dotnet\sdk]
  2.0.2 [C:\Program Files\dotnet\sdk]
  2.0.3 [C:\Program Files\dotnet\sdk]
  2.1.1 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.100-preview-007363 [C:\Program Files\dotnet\sdk]
  2.1.100 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.102 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.200-preview-007474 [C:\Program Files\dotnet\sdk]
  2.1.200-preview-007517 [C:\Program Files\dotnet\sdk]
  2.1.200-preview-007576 [C:\Program Files\dotnet\sdk]
  2.1.200-preview-007589 [C:\Program Files\dotnet\sdk]
  2.1.200-preview-007597 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.300-preview1-008174 [C:\Program Files\dotnet\sdk]
  2.1.300-preview2-008530 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview1-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.0-preview2-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview1-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.0-preview2-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-preview1-26216-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-preview2-26406-04 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

I've created a branch with the repro here: https://github.com/MiniProfiler/dotnet/tree/craver/traversal

To run:

dotnet build PackageBuild.csproj -c Release /p:CI=true

I see related issues in MSBuild here:

• dotnet/msbuild#2688
• dotnet/msbuild#2874

...but I would assume (dangerous!) those downstream issues are from traversal double-includes of projects, or possible from the tree beneath a project (some of the projects in there reference others, with most of them referencing MiniProfiler.Shared at the end) not being fully evaluated on what to build? Just trying to save some time with observations here...hopefully the repro above helps more than anything.

Add documentation for new Artifacts feature

IsTraversal determination is case-sensitive

Need to do a case-insensitive Contains() here: https://github.com/Microsoft/MSBuildSdks/blob/master/src/Traversal/Sdk/Sdk.props#L22

GitHub dependents not detected

https://github.com/microsoft/MSBuildSdks/network/dependents

The nuspec files here are stopping GitHub from showing who is using these SDK packages, presumably due to <packageId>$id</packageid> syntax.

Not a biggie, but I was looking for some usages of these SDKs to learn more about their use.

cant add Microsoft.Build.CentralPackageVersions to directory.build.props

hi,

would this be feasible?

D:\prod\structures\Test\TestTools\TestAdapters\FarmiAdapterTask\FarmiAdapterTask.fsproj : error  : Importing the file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Microsoft.Common.props" into the file "C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props" results in a circular dependency.  C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props

D:\prod\structures\Test\TestTools\TestAdapters\NunitTSServer\NunitTSServer.csproj : error  : Importing the file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Microsoft.Common.props" into the file "C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props" results in a circular dependency.  C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props

D:\prod\structures\Test\TestTools\TestAdapters\FarmiAdapterTask\FarmiAdapterTask.fsproj : error  : Importing the file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Microsoft.Common.props" into the file "C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props" results in a circular dependency.  C:\Users\jocs\.nuget\packages\microsoft.build.centralpackageversions\2.0.36\Sdk\Sdk.props

So we dont need to import the sdk into all projects, so easier to maintain the centralpackageversions also

thanks

CentralPackageVersions does not support F#

Hi,

if i create a F# project and include

i get this error

The package reference 'FSharp.Core' should not specify a version.  Please specify the version in 'D:\prod\structures\Packages.props' or set VersionOverride to override the centrally defined version.	

Supose the FSharp msbuild files are already having a PackageReference defined. So it should be possible to ignore this error

thanks

Microsoft.Build.NoTargets does not define "Test" target

I wanted to dogfood Microsoft.Build.NoTargets in the project system. Doing so I get error:

error MSB4057: The target "Test" does not exist in the project.

...as seen in this build.

Is Test a standard target that should also be included here?

Microsoft.Build.NoTargets does not import Microsoft.Common.targets

Failure:

Microsoft.Build.NoTargets does not import the common targets file from Microsoft.Common.targets. It does however import Microsoft.Common.props.

A lot of stuff is broken, like Directory.Build.targets (#40) and referenced nuget packages (#41)

Example

<Project Sdk="Microsoft.Build.NoTargets/1.0.26">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <PackageReference Include="Nerdbank.GitVersioning" Version="2.1.*" />
  </ItemGroup>

  <Target Name="Testing123" AfterTargets="Build" DependsOnTargets="GetBuildVersion">
    <Message Importance="High" Text="BuildVersion: $(BuildVersion)" />
  </Target>

</Project>

Expected

C:\test>msbuild sometest.proj
Microsoft (R) Build Engine version 15.6.85.37198 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 21-06-2018 14:05:03.
Project "C:\test\sometest.proj" on node 1 (default targets).
CopyFilesToOutputDirectory:
  sometest ->
Testing123:
  BuildVersion: 1.2.3-09ed9e47
Done Building Project "C:\test\sometest.proj" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.39

Actual

C:\test>msbuild sometest.proj
Microsoft (R) Build Engine version 15.6.85.37198 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 21-06-2018 14:01:46.
Project "C:\test\sometest.proj" on node 1 (default targets).
CopyFilesToOutputDirectory:
  sometest ->
C:\test\sometest.proj(11,50): error MSB4057: The target "GetBuildVersion" does not exist in the pr
oject.
Done Building Project "C:\test\sometest.proj" (default targets) -- FAILED.


Build FAILED.

"C:\test\sometest.proj" (default target) (1) ->
  C:\test\sometest.proj(11,50): error MSB4057: The target "GetBuildVersion" does not exist in the
project.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.78

Microsoft.Build.NoTargets does not import nuget targets

Failure:

Microsoft.Build.NoTargets does not import the nuget targets file from obj\$(MSBuildProjectFile).nuget.g.targets. It does however import obj\$(MSBuildProjectFile).nuget.g.props.

Reason:

This is happens because Microsoft.Common.targets is not imported. Microsoft.Common.props is imported.