rules_dotnet icon indicating copy to clipboard operation
rules_dotnet copied to clipboard

Cannot resolve NuGet package references to local packages

Open jimevans opened this issue 6 years ago • 4 comments

Many monorepo enthusiasts insist that dependencies are checked into the source control system. The .NET ecosystem supports this by use of a custom NuGet feed. In Visual Studio, this can be achieved by creating a file called NuGet.config XML file and adding a <packageSources> element that contains a reference to the directory on disk containing the .nupkg files. In the IDE, this shows up as an entry in the Package Sources list of the NuGet Package Manager window.

Additionally, this would allow users to use internal packages not published to nuget.org, as there is currently no way to do this. The use case here is a version of a package where the maintainer either has not or will not accept bug fixes, and the development team maintains a forked version of the dependency project. There may not be any need for the development team to build this dependency as part of the target project, and the dependency code should not be a part of the target project.

jimevans avatar May 01 '19 01:05 jimevans

The nuget_package rule support source parameter which specifies package source to use: https://github.com/bazelbuild/rules_dotnet/blob/master/dotnet/workspace.rst#nuget_package

tomaszstrejczek avatar May 01 '19 19:05 tomaszstrejczek

That’s fair, I suppose, but for a package that lives in the source control repo, and therefore already exists locally on disk and doesn’t need to be downloaded, how should that URL be formatted? And do I need to lay the packages out in the repo in a specific directory format (like packages/<packageName>/<packageVersion>/packagefile.nupkg?

jimevans avatar May 01 '19 19:05 jimevans

Currently it will not work. nuget_package under the hood uses download_and_extract (https://docs.bazel.build/versions/master/skylark/lib/repository_ctx.html#download_and_extract) which AFAIK can't handle local files. However custom remote package source should work.

tomaszstrejczek avatar May 18 '19 12:05 tomaszstrejczek

Well, let’s mark this as a feature request then, and see what it would take to develop.

jimevans avatar May 18 '19 18:05 jimevans