Add SDK support for generating deps.json files for .NET CLI Tools by dsplaisted · Pull Request #1128 · dotnet/sdk

dsplaisted · 2017-04-17T15:29:37Z

This is an SDK-side change which will be part of fixing https://github.com/dotnet/cli/issues/6087. There will be a corresponding CLI change which will take advantage of it. We should probably wait to merge this change until I have the CLI change ready, but I think this change can be reviewed as is.

The idea is that when the CLI is going to run a tool, it will check to see if there is a deps.json file next to the project.assets.json under the NuGet .tools folder. If not, it will generate the deps file by building the new GenerateDeps.proj file which is inside the CLI, passing in necessary information such as the path to the assets file.

This will allow the same logic to be used to generate the .deps.json files for tools as is used when apps are built. It will include the conflict resolution logic, which will fix #6087.

eerhardt

Tests?

dsplaisted · 2017-04-17T16:23:49Z

Tests?

@eerhardt I was planning for tests to go in the CLI repo.

eerhardt · 2017-04-17T16:25:03Z

I was planning for tests to go in the CLI repo.

So when we are fixing bugs or adding new features in this area, we won't be able to tell if we broke something until it gets merged into CLI?

eerhardt · 2017-04-18T15:14:06Z

+          Condition=" '$(AdditionalImport)' != '' And Exists($(AdditionalImport))" />
+
+  <PropertyGroup>
+    <TargetFramework>netcoreapp$(BundledNETCoreAppTargetFrameworkVersion)</TargetFramework>


This this always going to hold true? What if the project.assets.json file was restored with netcoreapp1.0? Won't GenerateBuildDependencyFile raise an error because there isn't a netcoreapp2.0 target in the lock file?

Maybe DotnetCliToolTargetFramework should be passed in to this project? Or the TargetFramework should be passed in?

In reply to: 111981249 [](ancestors = 111981249)

This gets passed in now, based on the target framework from the assets file.

eerhardt · 2017-04-18T15:15:02Z

          Outputs="$(ProjectDepsFilePath)">

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


Instead of duplicating these property defaulting in two places, can we default it in a common spot?

eerhardt · 2017-04-18T15:20:09Z

+            }
+            else
+            {
+                fullProjectPath = Path.GetFullPath(projectPath);


This logic concerns me. I don't think this will work correctly if the project includes P2P references.

Maybe alternatively, we always create a mainProjectInfo, and instead have a boolean on it - IncludeInDependencyContext or something similar?

Again, a test would be nice here - have a project that sets <IncludeMainProjectInDepsFile>false</IncludeMainProjectInDepsFile> and has a P2P reference.

I think this kind of scenario could be used in situations like the dotnet/cli uses. See https://github.com/dotnet/cli/blob/master/src/redist/redist.csproj#L62-L64 where we have to go and strip the "main project" from the deps file.

In reply to: 111982912 [](ancestors = 111982912)

dsplaisted · 2017-04-19T14:58:07Z

I've created the corresponding PR for the CLI changes: dotnet/cli#6356

So when we are fixing bugs or adding new features in this area, we won't be able to tell if we broke something until it gets merged into CLI?

@eerhardt You're right, we should probably have some test coverage for this in the SDK repo too. I'm going to first work on adding tests for the end-to-end scenario in the CLI, then I'll come back and look at what kind of tests for this to add to the SDK.

livarcocc · 2017-04-27T02:48:29Z

@MattGertz for approval. This is the other PR I mentioned to you earlier today.

eerhardt · 2017-04-27T14:42:49Z

+        public static ICommand AddTestEnvironmentVariables(ICommand command)
+        {
+            //  Set NUGET_PACKAGES environment variable to match value from build.ps1
+            command = command.EnvironmentVariable("NUGET_PACKAGES", Path.Combine(RepoInfo.RepoRoot, "packages"));


NuGetCachePath?

Yeah, that wouldn't hurt. This code was written before that variable existed, and I'm moving it to a different location here.

eerhardt · 2017-04-27T14:54:35Z

+                .And.HaveStdOutContaining("Successfully loaded runtime graph");
+        }
+
+        //  This method duplicates a lot of logic from the CLI in order to test generating deps files for tools in the SDK repo


I wonder if we need to go this far?

Could we get away with just testing the GenerateDeps.proj file without bringing a bunch of "tools" stuff. Just get a project.assets.json file, and invoke the GenerateDeps.proj file on it....

thoughts?

eerhardt · 2017-04-27T14:55:48Z

+                IsExe = true
+            };
+
+            toolProject.PackageReferences.Add(new TestPackageReference("Microsoft.Extensions.DependencyModel", "2.0.0-preview1-002022", null));


Can we get this version from our DependencyVersions.props file? That way we are constantly updating it.

Since the point is to test conflict resolution, I think we want a fixed version so that we don't roll forward to a version of the library that doesn't need it (because it targets .NET Core / .NET Standard 2.0).

Then let's use a released version, like 1.0.0 or 1.1.0, etc. Not some random daily build.

…T CLI tools

…ET Core bundled in the CLI Also include GenerateDeps.proj in tasks project

…I to use to get the path to it in the SDK

…122.5 (dotnet#1128) - Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19572.5

Fixes dotnet#1132 Fixes dotnet#1128 Fixes dotnet#1127 Fixes dotnet#1126 Fixes dotnet#1125 Fixes dotnet#1124 Fixes dotnet#1115

dsplaisted requested review from eerhardt and nguerrera April 17, 2017 15:29

dnfclas added the cla-already-signed label Apr 17, 2017

eerhardt requested changes Apr 17, 2017

View reviewed changes

eerhardt reviewed Apr 18, 2017

View reviewed changes

dsplaisted mentioned this pull request Apr 19, 2017

Use .NET SDK to generate deps.json for tools dotnet/cli#6356

Merged

This was referenced Apr 25, 2017

Re-enable DotNetCliToolReference in samples for netcoreapp2.0 aspnet/Universe#506

Closed

[2.0.0-preview1] Update dotnet-ef to netcoreapp2.0 dotnet/efcore#8281

Merged

livarcocc approved these changes Apr 26, 2017

View reviewed changes

livarcocc added the Pending Shiproom Approval label Apr 27, 2017

MattGertz added Approved to merge and removed Pending Shiproom Approval labels Apr 27, 2017

eerhardt reviewed Apr 27, 2017

View reviewed changes

dsplaisted changed the base branch from master to release/2.0.0 April 27, 2017 15:07

dsplaisted added 8 commits April 27, 2017 08:09

Add option to not include "main project" info in deps file

53a0175

Add GenerateDeps.proj to be used to generate .deps.json files for .NE…

c5a64e7

…T CLI tools

Set the TFM used to restore .NET CLI tools to match the version of .N…

645556b

…ET Core bundled in the CLI Also include GenerateDeps.proj in tasks project

Include GenerateDeps.proj in SDK layout, and set property for .NET CL…

0478a81

…I to use to get the path to it in the SDK

Set DotnetCliToolTargetFramework in crosstargeting builds

9e7d1b8

Apply code review feedback

4d1ab8c

Add tests for tool deps file generation

60e0b73

Fix path casing for deps file generation test

3aaabde

Use common variable for nuget cache path

dc9139b

dsplaisted force-pushed the generate-tools-deps branch from 44120b4 to dc9139b Compare April 27, 2017 15:09

dsplaisted added 2 commits April 27, 2017 08:33

Disable deps file generation tests on full framework MSBuild

cb5afa9

Use released version of Microsoft.Extensions.DependencyModel for test

ec5d03c

dsplaisted merged commit c8d7d33 into dotnet:release/2.0.0 Apr 27, 2017

dsplaisted added a commit to dsplaisted/sdk that referenced this pull request May 3, 2017

Add license headers I forgot in dotnet#1128

cd7e9b7

mmitche pushed a commit to mmitche/sdk that referenced this pull request Jun 5, 2020

Update dependencies from https://github.com/dotnet/arcade build 20191…

a894a93

…122.5 (dotnet#1128) - Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19572.5

GangWang01 pushed a commit to GangWang01/sdk that referenced this pull request Jun 7, 2022

Fixes the bugs discovered during the verification

27c0257

Fixes dotnet#1132 Fixes dotnet#1128 Fixes dotnet#1127 Fixes dotnet#1126 Fixes dotnet#1125 Fixes dotnet#1124 Fixes dotnet#1115

GangWang01 pushed a commit to GangWang01/sdk that referenced this pull request Jul 11, 2022

Fixes the bugs discovered during the verification

edd6c6b

Fixes dotnet#1132 Fixes dotnet#1128 Fixes dotnet#1127 Fixes dotnet#1126 Fixes dotnet#1125 Fixes dotnet#1124 Fixes dotnet#1115

Conversation

dsplaisted commented Apr 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eerhardt left a comment

Choose a reason for hiding this comment

Uh oh!

dsplaisted commented Apr 17, 2017

Uh oh!

eerhardt commented Apr 17, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dsplaisted commented Apr 19, 2017

Uh oh!

livarcocc commented Apr 27, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dsplaisted commented Apr 17, 2017 •

edited

Loading