Add Microsoft.AspNetCore.BuildTools.ApiCheck to builds #205

dougbu · 2017-03-22T16:48:32Z

api-check support for csproj KoreBuild#143

Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project

include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package
add *.props and *.targets files to hook task into Pack target; runs just before .nupkg is created
reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project
- requires lots of hacks; P2Ps should be allowed when ReferenceOutputAssembly=false even given TFM incompatibilities dotnet/sdk#939 workarounds fail in this scenario

Fall back to RuntimeTargets when RuntimeAssemblies yields no assemblies

Improve project-to-project reference and native assembly handling

avoid FileNotFoundException in AssemblyLoadContext.GetAssemblyName() due to \placeholder\ paths
catch and ignore BadImageFormatException in AssemblyLoadContext.GetAssemblyName()
avoid InvalidOperationException in PackageGraph.RuntimeIsCompatible() due to missing .sha512 file

Change ApiCheck.exe's options and output

add api-check --compact-output option
generally make tool's output more useful to the task
- catch and log FileNotFoundException; output types and stack traces of caught Exceptions
remove --framework option; unused in .NET Framework already
change ApiCheck.exe option from --ApiListing to --api-listing for consistency w/ other options

nits:

remove PackageGraph.RuntimeIsCompatible() candidateRuntime parameter
- not needed and confusingly-named; passed value included in compatibleRuntimes
update solution to use current project type GUID
ignore global.json and launchSettings.json
make some Linq a bit more readable
whitespace and using cleanup
move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj
make a couple of constructors private; used only in public static methods
ignore case a bit more

notes:

don't use UseCommandProcessor==true; ToolTask writes out .cmd file with a BOM that cmd.exe hates

dnfclas · 2017-03-22T16:48:36Z

@dougbu,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

dougbu · 2017-03-22T16:56:03Z

See also the following changes. They must go in first to avoid breaking every Universe build. Note these changes are temporary and should be replaced by exceptions.net(45|core).json fixes in short order. I'll file those issues once the PRs are in.

natemcmaster · 2017-03-22T16:58:39Z

BuildTools.sln

@@ -15,34 +15,36 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution
 EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test", "test", "{60A938B2-D95A-403C-AA7A-3683AD64DFA0}"
 EndProject
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "NuGetPackageVerifier", "src\NuGetPackageVerifier\NuGetPackageVerifier.csproj", "{657AFF5E-164E-493D-8501-8026B7C20808}"
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "NuGetPackageVerifier", "src\NuGetPackageVerifier\NuGetPackageVerifier.csproj", "{657AFF5E-164E-493D-8501-8026B7C20808}"


Can you reverse this? VS probably changed it, but the FAE04EC0 guid is correct. This VS bug is being tracked here: dotnet/project-system#1821

🙈 Not a fan of fighting Visual Studio. We can revert this part of the change when dotnet/project-system#1821 is fixed or wait for a future VS update to change the solution for us.

natemcmaster · 2017-03-22T17:01:38Z

...oft.AspNetCore.BuildTools.ApiCheck.Task/Microsoft.AspNetCore.BuildTools.ApiCheck.Task.csproj

+  <Import Project="..\..\build\common.props" />
+
+  <PropertyGroup>
+    <TargetFramework>netstandard1.6</TargetFramework>


This task assembly probably needs to cross-compile for net46. Visual Studio runs MSBuild.exe which uses .NET Framework. The netstandard1.6 won't load.

🙈 This is intentional. Our engineering team decided not to run the tool within Visual Studio. We may change that after #201 is fixed.

natemcmaster · 2017-03-22T17:44:54Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck.Task/ApiCheckTask.cs

+        /// <inheritdoc />
+        protected override string GenerateCommandLineCommands()
+        {
+            var arguments = string.Empty;


I just added API for this. Can you use it here? See ArgumentEscaper.

🙈 Not the Right Thing:tm: for this task. ArgumentEscaper doesn't handle anything but spaces (not all special bash and cmd characters) and this will run in /every/ Universe build. In addition, MSBuild properties like $(TargetPath) are already in reasonable shape and folder names containing double quotes are incredibly unlikely.

natemcmaster · 2017-03-22T17:45:38Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck.Task/ApiCheckTask.cs

+                return Path.GetFullPath(Path.Combine(taskAssemblyFolder, "..", "net452", ToolExe));
+            }
+
+            var dotnetPath = new FileInfo(AppContext.GetData("FX_DEPS_FILE") as string) // .\Microsoft.NETCore.App.deps.json


I just added API for this. Can you use it here? See DotNetMuxer.

natemcmaster · 2017-03-22T17:47:37Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/Loader/AssemblyLoader.cs

 #if NETCOREAPP1_1
            var lockFile = new LockFileFormat().Read(assetsJson);
-            var graph = PackageGraph.Create(lockFile, framework);
+            var graph = PackageGraph.Create(lockFile, "netcoreapp1.1");


What about .NET Core 2.0? This adds a problem we're trying to undo in other build tools. See conversation on #121

As we discussed offline, moving to netcoreapp2.0 hit some roadblocks. Would likely need to build this tool against a specific shared library version to ensure consuming projects run it in something newer. For now, leaving this as-is because it's earlier than what KoreBuild installs.

On the other hand, I have preserved the dependency version cleanup I did to get rid of package downgrades after moving every .exe to netcoreapp2.0.

Let me clarify: I didn't mean we upgrade the tool to run on netcoreapp2.0. Rather I was asking if we can allows this tool to parse the graph for multiple versions of netcoreapp1.0.

More context: some other tools hardcode netcoreapp1.0 which led to #121. Hardcoding netcoreapp1.1 is repeating the same mistake. A fix for #121 will likely revert the removal of framework if you commit this as is.

Thanks for the context. I'll restore the --framework command-line option.

natemcmaster · 2017-03-22T17:55:01Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/build/Common.props

+<Project>
+  <!-- Set nothing if handled in project file or already done in outer build. -->
+  <PropertyGroup>
+    <EnableApiCheck Condition=" '$(EnableApiCheck)' == '' AND '$(MSBuildRuntimeType)' == 'Core' ">true</EnableApiCheck>


Why is this only enabled on dotnet.exe builds? Don't we want to see build errors in VS?

🙈 No, we don't want this in developer's faces when they are just hacking things together.

I disagree. We want developers aware of breaking changes. Many times their unintentionally and we don't catch them until the tool actually runs. We have developers who only build + test in VS.

But I'll let others weigh in to settle this. Should API check cause building in VS to fail? Or should it only fail on build.cmd? cc @Eilon @muratg

🙈 We've already had this conversation.

I wasn't aware of a design discussion about this. Please re-consider. Making VS builds and build.cmd as similar as possible is a highly desirable goal.

If the only concern is that api check errors might impede a developer's inner loop, there are better solutions. Two come to mind: (1) make api check failures a warning in Debug but an error in Release. (2) detect "BuildingInsideVisualStudio" and demote errors to being non-fatal.

It was discussed w/ the engineering team that we don't want this to run when building from VS.

natemcmaster · 2017-03-22T17:56:47Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/build/Common.props

+    <ExcludePublicInternalTypes_InApiCheck Condition=" '$(ExcludePublicInternalTypes_InApiCheck)' == '' ">true</ExcludePublicInternalTypes_InApiCheck>
+
+    <!-- Hook API checks into Pack run, prior to creating the .nupkg but after build (if any). -->
+    <GenerateNuspecDependsOn Condition=" ! $(GenerateNuspecDependsOn.Contains('ApiCheck')) ">$(GenerateNuspecDependsOn);ApiCheck</GenerateNuspecDependsOn>


This should append to BuildDependsOn. API Check failures should cause the /t:Build target to fail.

By thew way, MSBuild will de-dup the property so you don't need the .Contains condition.

Sure, I'll remove the Condition.

Don't understand your point about $(BuildDependsOn) versus $(GenerateNuspecDependsOn). Failures in this target cause command-line builds to fail. Also, the intent is to check the APIs of assemblies we ship (aka pack), not everything we build.

Producing an and API check are orthogonal concerns. GenerateNuspecDependsOn is not guaranteed to run as a part of producing an binary.

natemcmaster · 2017-03-22T17:59:59Z

...icrosoft.AspNetCore.BuildTools.ApiCheck/build/Microsoft.AspNetCore.BuildTools.ApiCheck.props

+  <Import Project="$(MSBuildThisFileDirectory)Common.props"/>
+
+  <PropertyGroup>
+    <_ApiCheckTaskAssembly>$(MSBuildThisFileDirectory)..\tools\netstandard1.6\Microsoft.AspNetCore.BuildTools.ApiCheck.Task.dll</_ApiCheckTaskAssembly>


This needs to check for MSBuildRuntimeType and use a differenet assembly if MSBuildRuntimeType != Core. See this example.

Intentionally not part of non-Core MSBuild. But, if I left out the condition, I'll add it.

natemcmaster · 2017-03-22T18:04:30Z

...rosoft.AspNetCore.BuildTools.ApiCheck/build/Microsoft.AspNetCore.BuildTools.ApiCheck.targets

+  for use outside of Microsoft.
+-->
+<Project>
+  <Target Name="ApiCheck" Condition=" '$(EnableApiCheck)' == 'true' AND $(IsPackable) == 'true' ">


Why does IsPackable need to be enabled for ApiCheck to run?

Because we don't check code we don't ship.

Pack and api check are separate and shouldn't be intermingled. It's possible to produce a binary can end up in a nuget package even when IsPackable is false. EnableApiCheck should be sufficient to disable the target.

The target can use existence of baseline.json files to avoid running.
The target can use the IsTestProject property to suppress the warning on test projects.

The agreed plan was to do the API Check as part of the Pack target.

natemcmaster · 2017-03-22T18:25:56Z

...rosoft.AspNetCore.BuildTools.ApiCheck/build/Microsoft.AspNetCore.BuildTools.ApiCheck.targets

@@ -0,0 +1,30 @@
+<!--


This breaks one of our design patterns for tools and targets. To keep our tools composible and to separate concerns, tools packages only deliver the tool. Integration into build cycle is specified by KoreBuild and/or Internal.AspNetCore.Sdk.

For example, the NuGetPackageVerifier package contains the tool, but the target to light it up actually is defined in KoreBuild.
Likewise, the GetGitCommitInfo task is defined and delivered by Internal.AspNetCore.BuildTools.Tasks, but the target that ties it into MSBuild compile step is defined in Internal.AspNetCore.Sdk.

This fix should be simple. Lift the ApiCheck target into Internal.AspNetCore.Sdk instead.

Why is that odd distance between tasks and where they are used a "design pattern"?

https://en.wikipedia.org/wiki/Separation_of_concerns

Tasks != targets.

Done, mainly because consuming the Api Check package directly may be useful in some cases e.g. just to run the tool from a command line. Don't want to affect the consuming project then.

dougbu · 2017-03-24T01:51:45Z

🆙📅 with numerous changes. Have a look at recent commit titles to get some sense of what's changed.

This should be ready to go. Running another local Universe build to confirm. But, that's been hanging while cloning repos (before these tools are used) for some reason…

dougbu · 2017-03-24T05:10:53Z

… hanging was a temporary issue with my machine. This PR is working.

natemcmaster

Please revert the dependency version changes made to anything except ApiCheck.csproj. This needs to done more carefully as this change will break patch builds that will not have access to 1.2.0-* packages. Dependency version changes that break backward compatibility should result in a change to the tool package version number. For instance, this bumps netcoreapp1.0 tools to 4.3.0 CoreFx packages, which was meant for use with netcoreapp1.1.

Please limit the scope your changes those required for making ApiCheck work. We'll take care of version bumps in #200.

Side note: M.Ex.CommandLineUtils doesn't exist anymore. It's now a .Sources only package cref dotnet/extensions#205

natemcmaster · 2017-03-24T17:09:32Z

src/Internal.AspNetCore.BuildTools.Tasks/Internal.AspNetCore.BuildTools.Tasks.csproj

@@ -18,7 +18,7 @@
  </PropertyGroup>

  <ItemGroup>
-    <PackageReference Include="NETStandard.Library" Version="1.6.0" PrivateAssets="All" />
+    <PackageReference Include="NETStandard.Library" Version="$(NetStandardImplicitPackageVersion)" PrivateAssets="All" />


Please revert the version bumps. These versions were picked specifically to align with what is in MSBuild for .NET Core 1.0. A dependency version bump in tools packages should result in a tools version bump. This may break patch builds. We'll take care of the upgrade in #200

natemcmaster · 2017-03-24T17:24:21Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/Loader/AssemblyLoader.cs

 #if NETCOREAPP1_1
            var lockFile = new LockFileFormat().Read(assetsJson);
-            var graph = PackageGraph.Create(lockFile, framework);
+            var graph = PackageGraph.Create(lockFile, "netcoreapp1.1");


Let me clarify: I didn't mean we upgrade the tool to run on netcoreapp2.0. Rather I was asking if we can allows this tool to parse the graph for multiple versions of netcoreapp1.0.

More context: some other tools hardcode netcoreapp1.0 which led to #121. Hardcoding netcoreapp1.1 is repeating the same mistake. A fix for #121 will likely revert the removal of framework if you commit this as is.

natemcmaster · 2017-03-24T17:29:40Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/Microsoft.AspNetCore.BuildTools.ApiCheck.csproj

+  </ItemGroup>
+
+  <ItemGroup Condition=" '$(TargetFramework)' != 'netstandard1.0' ">
+    <PackageReference Include="Microsoft.Extensions.CommandLineUtils" Version="$(AspNetCoreVersion)" />


This package isn't being produced anymore. Use Microsoft.Extensions.CommandLineUtils.Sources.

natemcmaster · 2017-03-24T17:35:45Z

src/NugetReferenceResolver/NugetReferenceResolver.csproj

  <ItemGroup>
+    <PackageReference Include="Microsoft.DotNet.PlatformAbstractions" Version="$(AspNetCoreVersion)" />


Can you add a different version variable for this one? We don't produce this package and it may not be the same as AspNetCoreVersion. For example, its latest version is 2.0.0-*, not 1.2.0-*

natemcmaster · 2017-03-24T17:36:21Z

src/VersionTool/VersionTool.csproj

-    <PackageReference Include="Microsoft.DotNet.ProjectModel" Version="1.0.0-rc3-1-003177" />
+    <PackageReference Include="Microsoft.DotNet.Cli.Utils" Version="$(DotNetCliUtilsVersion)" />
+    <PackageReference Include="Microsoft.DotNet.ProjectModel" Version="$(DotNetProjectModelVersion)" />
+    <PackageReference Include="Microsoft.Extensions.CommandLineUtils" Version="$(AspNetCoreVersion)" />


natemcmaster · 2017-03-24T17:44:17Z

src/Microsoft.AspNetCore.BuildTools.ApiCheck/Microsoft.AspNetCore.BuildTools.ApiCheck.csproj

  <PropertyGroup>
-    <VersionPrefix>1.0.1</VersionPrefix>
-    <TargetFrameworks>netcoreapp1.1;net452</TargetFrameworks>
+    <VersionPrefix>1.0.2</VersionPrefix>


👍 thanks for incrementing the version. This makes it safer to bump dependency versions.

natemcmaster · 2017-03-24T17:55:42Z

Separate to the changes requested above, I wanted to re-iterate my concern about picking the concept of ApiCheck and producing a NuGet package. These are orthogonal concerns. While we currently only API Check when we also pack with Microsoft.NET.Sdk, it may not always be the way we want to use it. E.g. in current form, it would not work on https://github.com/aspnet/AspNetKatana or https://github.com/aspnet/EntityFramework6.

There are 2 simple changes I'm proposing to decouple API Check from pack targets:

Chain off of Build instead of GenerateNuSpec
Use Condition="Exists('baseline.json')" to determine if a API check should run, not IsPackable=true.

dougbu · 2017-03-24T17:56:32Z

Side note: M.Ex.CommandLineUtils doesn't exist anymore. It's now a .Sources only package cref dotnet/extensions#205

That's unexpected. The .Sources package won't work for at least one project. Don't remember which one but we have tested APIs that expose CommandLineUtils types.

dougbu · 2017-03-24T18:01:06Z

These are orthogonal concerns.

I agree the concerns are orthogonal. However this is where we decided to hook the task in by default.

in current form, it would not work on https://github.com/aspnet/AspNetKatana or https://github.com/aspnet/EntityFramework6.

All unusual repos will be able to hook the task in differently as they wish. The current approach works fine throughout Universe.

not IsPackable=true

As it turns out, this condition is redundant. I'll remove it.

natemcmaster · 2017-03-24T18:05:38Z

where we decided

Was that decision made along with the information and concerns I have expressed? We are not bound to bad decisions.

dougbu · 2017-03-24T18:09:13Z

this bumps netcoreapp1.0 tools to 4.3.0 CoreFx packages

I agree with this part of your concern. The rest isn't valid because we have no patch branches using MSBuild. So, I'll make sure we're building for netcoreapp1.1 everywhere.

natemcmaster · 2017-03-24T18:53:05Z

The rest isn't valid because we have no patch branches using MSBuild.

Talked in person with @dougbu. I'm assuming this comment was after that because in person we discussed that we do have patch branches on MSbuild. aspnet/DotNetTools, aspnet/EntityFramework.Tools and aspnet/Scaffolding.

natemcmaster · 2017-03-24T18:55:27Z

I'm dropping my requests to chain off build not pack, and to run API check in VS. I may disagree with the design, but I'm not part of the decision process so @dougbu is correct here in following the design agreed upon by the build engineering team.

- aspnet/KoreBuild#143 Add Microsoft.AspNetCore.BuildTools.ApiCheck.Task project - include task assembly in the Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck package - add *.props and *.targets files to hook task into `Pack` target; runs just before .nupkg is created - reference Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck project from the Sdk project - requires lots of hacks; dotnet/sdk#939 workarounds fail in this scenario Fall back to `RuntimeTargets` when `RuntimeAssemblies` yields no assemblies Improve project-to-project reference and native assembly handling - avoid `FileNotFoundException` in `AssemblyLoadContext.GetAssemblyName()` due to `\placeholder\` paths - catch and ignore `BadImageFormatException` in `AssemblyLoadContext.GetAssemblyName()` - avoid `InvalidOperationException` in `PackageGraph.RuntimeIsCompatible()` due to missing .sha512 file Change ApiCheck.exe's options and output - add `api-check --compact-output` option - generally make tool's output more useful to the task - catch and log `FileNotFoundException`; output types and stack traces of caught `Exception`s - remove `--framework` option; unused in .NET Framework already - change ApiCheck.exe option from `--ApiListing` to `--api-listing` for consistency w/ other options nits: - remove `PackageGraph.RuntimeIsCompatible()` `candidateRuntime` parameter - not needed and confusingly-named; passed value included in `compatibleRuntimes` - update solution to use current project type GUID - ignore global.json and launchSettings.json - make some Linq a bit more readable - whitespace and `using` cleanup - move all property groups above item groups in Microsoft.AspNetMicrosoft.AspNetCore.BuildTools.ApiCheck.csproj - make a couple of constructors `private`; used only in `public static` methods - ignore case a bit more notes: - don't use `UseCommandProcessor==true`; `ToolTask` writes out .cmd file with a BOM that cmd.exe hates

- everything should now be using `NETStandard.Library` v1.6.1, CoreFx packages v4.3.0, etc. - remove duplicate `<PropertyGroup>` from `NugetReferenceResolver` project - add two dependencies to `BuildTools.Tasks.Tests` project to avoid package downgrade warnings

- VersionTool project cannot do this because it has `public` properties of these `internal` types - just sorted the dependencies - will file a separate issue to make those properties `internal` if possible; probably low-pri

- don't change default: `$(NetStandardImplicitPackageVersion)` -> `$(NetStandardPackageVersion)` - don't use `$(IsPackable)` in a condition; redundant and may block direct use of the `ApiCheck` target

dougbu · 2017-03-24T23:16:31Z

🆙📅 Rebased on dev and added 4 5 new commits. I restored ApiCheck.exe's --framework option, used that in ApiCheckTask, reverted many dependency version changes, remove an $(IsPackable) check, and used the Microsoft.Extensions.CommandLineUtils.Sources package where possible.

natemcmaster · 2017-03-24T23:18:59Z

Nice work :)

pranavkm · 2017-03-24T23:48:13Z

build/dependencies.props

@@ -1,9 +1,12 @@
 <Project>
  <PropertyGroup>
    <AspNetCoreVersion>1.2.0-*</AspNetCoreVersion>


Could we reference the versions on NuGet.org? It's kinda weird to reference ci-dev packages from this repo since it runs independent of Universe and needs to exist beyond the lifetime of these packages.

I'll see how much this is used now. If it's just for the CommandLineUtils, I'll leave it as-is. Due to patch releases, might have to use too many versions for NuGet use to be interesting and controllable from this file.

BTW I didn't change this property or add a source to the NuGet.config file 😺

pranavkm · 2017-03-24T23:52:49Z

src/Internal.AspNetCore.Sdk/build/ApiCheck.targets

+             Importance="normal"
+             Text="Checking for breaking changes in $(MSBuildProjectName), $(TargetFramework)" />
+    <ApiCheckTask Condition=" '$(_ApiListingFile)' != '' "
+                  ApiListingPath="$(_ApiListingFile)"


Could we use the same indentation as C#? Maintaining these indentations over time is just a pain.

This is how VS indents XML by default. But, I agree it won't be easy to maintain this in Notepad and VS Code.

I am not changing existing indentation to match. There's a random mix in this repo.

dougbu · 2017-03-25T04:58:14Z

dnfclas added the cla-already-signed label Mar 22, 2017

dougbu requested review from pranavkm, natemcmaster and javiercn March 22, 2017 16:48

natemcmaster suggested changes Mar 22, 2017

View reviewed changes

javiercn mentioned this pull request Mar 22, 2017

Api check tool is slow and cannot handle some projects #201

Closed

dougbu mentioned this pull request Mar 23, 2017

Tools on .NET Core 2.0 #200

Closed

dougbu force-pushed the dougbu/check-api.143 branch from 30735b0 to 2f241db Compare March 23, 2017 20:09

natemcmaster suggested changes Mar 24, 2017

View reviewed changes

dougbu added 14 commits March 24, 2017 14:43

Use DotNetMuxer

d9f2b91

Use Exception.ToString()

83fd1a8

Remove unecessary Condition and override project in a corner case

09625a3

Bump ApiCheck package version

ad3b9f5

Get this repo building on Linux

05e1df9

Rework Common.props to disable more API checks x-plat.

a4b0ce5

Move targets over to the Sdk project

46c6743

Don't need API checks in this repo

84d976f

Restore the --framework command-line option

d360953

Leave non-ApiCheck projects with current mix of dependency versions

1174dc7

Use Microsoft.Extensions.CommandLineUtils.Sources package

42ef4b6

- VersionTool project cannot do this because it has `public` properties of these `internal` types - just sorted the dependencies - will file a separate issue to make those properties `internal` if possible; probably low-pri

Use restored --framework option in ApiCheckTask; other cleanup

76eba60

- don't change default: `$(NetStandardImplicitPackageVersion)` -> `$(NetStandardPackageVersion)` - don't use `$(IsPackable)` in a condition; redundant and may block direct use of the `ApiCheck` target

dougbu force-pushed the dougbu/check-api.143 branch from 96f8344 to 76eba60 Compare March 24, 2017 23:10

Update appveyor.yml now that VS 2017 RC image is no more

150106a

natemcmaster approved these changes Mar 24, 2017

View reviewed changes

pranavkm approved these changes Mar 25, 2017

View reviewed changes

dougbu closed this Mar 25, 2017

dougbu deleted the dougbu/check-api.143 branch March 25, 2017 05:00

		<ItemGroup>
		<PackageReference Include="Microsoft.DotNet.PlatformAbstractions" Version="$(AspNetCoreVersion)" />

Add Microsoft.AspNetCore.BuildTools.ApiCheck to builds #205

Add Microsoft.AspNetCore.BuildTools.ApiCheck to builds #205

Conversation

dougbu commented Mar 22, 2017

dnfclas commented Mar 22, 2017

dougbu commented Mar 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natemcmaster Mar 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dougbu commented Mar 24, 2017

dougbu commented Mar 24, 2017

natemcmaster left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natemcmaster commented Mar 24, 2017

dougbu commented Mar 24, 2017

dougbu commented Mar 24, 2017

natemcmaster commented Mar 24, 2017

dougbu commented Mar 24, 2017

natemcmaster commented Mar 24, 2017

natemcmaster commented Mar 24, 2017

dougbu commented Mar 24, 2017 • edited

natemcmaster commented Mar 24, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dougbu commented Mar 25, 2017

natemcmaster Mar 22, 2017 •

edited

dougbu commented Mar 24, 2017 •

edited