Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In 2.2 tools packages, multitarget 2.2 and 2.1 so latest version is usable with LTS SDK #4613

Closed
dagood opened this issue Dec 12, 2018 · 1 comment
Labels
area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-devcerts

Comments

@dagood
Copy link
Member

dagood commented Dec 12, 2018

Problem

Summary from dotnet/source-build#926:

The source-build SDK product used by Red Hat doesn't include ASP.NET Core cli tools (e.g. dotnet-dev-certs). When the user tries to use the tool, they're prompted to run dotnet tool install --global dotnet-dev-certs. That works when the SDK they're using is the latest stable SDK available, like 2.2.101. However, it doesn't work in the 2.1.500 SDK with 2.1.6 Runtime anymore:

$ dotnet tool install -g dotnet-dev-certs
error NU1202:
Package dotnet-dev-certs 2.2.0 is not compatible with netcoreapp2.1 (.NETCoreApp,Version=v2.1) / any.
Package dotnet-dev-certs 2.2.0 supports: netcoreapp2.2 (.NETCoreApp,Version=v2.2) / any

The existence of the 2.2.0 tool package on the NuGet gallery prevents the desired, compatible dotnet-dev-certs 2.1.1 package from being found.

The workaround is to add --version '2.1.*' or a specific version to the dotnet tool install command.

Solution

If the 2.2.0 package also supported netcoreapp2.1, then the user would install 2.2.0 successfully and be on their way. The way to do this is through multitargeting:

-<TargetFramework>netcoreapp2.2<TargetFramework>
+<TargetFrameworks>netcoreapp2.1;netcoreapp2.2<TargetFrameworks>

Reasons this might not work well:

  • To work effectively in the future, every tool package version train (2.2, 3.0, 3.1?, ...) needs to multitarget all previous frameworks. That way, 2.1 SDK will still be able to find a compatible tool when, say, 3.0.0 is the latest.
  • If there are actual functional differences between the 2.1.* and 2.2.* tool packages, I can imagine that being difficult to maintain. I think 2.1 changes would need to be maintained in both the 2.1 ASP.NET branch as well as the 2.2 branch so 2.2 can target netcoreapp2.1.

Alternatives

There are other solutions described in dotnet/source-build#926 that are more palatable and wouldn't need any changes on your part. Multi-targeting is just one approach I think is worth asking about in case I've misjudged it. 😄

/cc @natemcmaster @omajid @wli3

@Eilon Eilon added the area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI label Jan 3, 2019
@mkArtakMSFT
Copy link
Member

Thanks for contacting us. We're closing this issue as there was no community involvement here for quite a while now.

@ghost ghost locked as resolved and limited conversation to collaborators Mar 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-devcerts
Projects
None yet
Development

No branches or pull requests

3 participants