Skip to content
This repository has been archived by the owner on Apr 20, 2023. It is now read-only.

Add "path" property to .deps.json file libraries #4032

Closed
wants to merge 213 commits into from

Conversation

joelverhagen
Copy link
Member

This is step #3 in this NuGet issue: NuGet/Home#2522. This work is also tracked by this CLI issue: https://github.com/dotnet/cli/issues/2874.

This PR adds a "path" property to the "libraries" entries in the .deps.json file. For packages, this is the relative path appended to the global packages folder (or fallback folder) to access the package's assets. For projects and other library types, this value is null.

After this work, the .NET Core host process need to be modified to prefer this property over the concatenation of the package ID and version.

/cc @eerhardt @emgarten @rrelyea @piotrpMSFT

brthor and others added 30 commits June 23, 2016 13:57
dotnet-build3 Adding msbuild execution command to cli
FI rel/1.0.0 into feature/msbuild
This adds the DotNetTool custom task, with `dotnet restore` implemented.
Implement RestorePackages in MSBuild.
Implement DownloadHostAndSharedFxArtifacts
Implement ZipTemplates
Switch the Prepare target to use all the MSBuild targets.
CompileTargets moved to MSBuild. Still need to work on input/outputs, refactoring of targets, specially around CompileStage and moving some of the tasks back to msbuild instead of C# code.
…msbuild caching of targets."

This reverts commit e100b95.
Finish converting 'Prepare' to MSBuild.
Implement incremental builds for Prepare targets.
Piotr Puszkiewicz and others added 19 commits August 9, 2016 13:22
Fix and re-enable build3 tests for windows and OSX
This capability is being replaced by MSBuild, and the project.json tests are very long running.
Conflicts:
	Microsoft.DotNet.Cli.sln
	build_projects/dotnet-cli-build/PackageTargets.cs
	build_projects/dotnet-cli-build/TestPackageProjects.cs
	build_projects/dotnet-cli-build/TestTargets.cs
	src/Microsoft.Extensions.DependencyModel/CompilationLibrary.cs
	src/Microsoft.Extensions.DependencyModel/DependencyContext.cs
	src/Microsoft.Extensions.DependencyModel/DependencyContextLoader.cs
	src/Microsoft.Extensions.DependencyModel/DependencyContextPaths.cs
	src/Microsoft.Extensions.DependencyModel/DependencyContextWriter.cs
	src/Microsoft.Extensions.DependencyModel/Resolution/AppBaseCompilationAssemblyResolver.cs
	src/Microsoft.Extensions.DependencyModel/Resolution/PackageCacheCompilationAssemblyResolver.cs
	src/Microsoft.Extensions.DependencyModel/Resolution/ResolverUtils.cs
	src/Microsoft.Extensions.DependencyModel/project.json
	test/Microsoft.Extensions.DependencyModel.Tests/DependencyContextJsonWriterTests.cs
	test/Microsoft.Extensions.DependencyModel.Tests/FunctionalTests.cs
	test/Microsoft.Extensions.DependencyModel.Tests/PackageCacheResolverTest.cs
	test/Microsoft.Extensions.DependencyModel.Tests/PackageResolverTest.cs
…ractions. Also updated the xunit template to add internalabstractions.

Conflicts:
	src/Microsoft.DotNet.Cli.Utils/project.json
	test/dotnet-build.Tests/BuildOutputTests.cs
…lsAbstractions version to 2.0.0, since I removed some public APIs from it.
@eerhardt
Copy link
Member

@joelverhagen, I hate to break this to you, but @livarcocc just removed the DependencyModel library from the dotnet/cli repo in the feature/msbuild branch. Instead, this library now lives in https://github.com/dotnet/core-setup/tree/master/src/Microsoft.Extensions.DependencyModel.

Is there any way you can port your changes to DependencyModel into that repo?

@@ -69,7 +69,7 @@ public static int Run(string[] args)
}
catch (Exception ex)
{
Reporter.Error.WriteLine(ex.Message.Red());
Reporter.Error.WriteLine(ex.ToString().Red());

This comment was marked as spam.

This comment was marked as spam.

@joelverhagen
Copy link
Member Author

@joelverhagen, I hate to break this to you, but @livarcocc just removed the DependencyModel library from the dotnet/cli repo in the feature/msbuild branch.

No worries. I'll react to this change and close this PR if necessary.

@eerhardt
Copy link
Member

I looked through the changes, and they all look good to me. Minus the part about this library being moved to another repo.

Maybe the best way forward is to make the change to DependencyModel and the DotNetHost in core-setup first. And then make the CLI changes in the feature/msbuild branch.

@joelverhagen
Copy link
Member Author

Closing because this should be based off of the feature/msbuild branch (due to DependencyModel change).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
6 participants