Add .NET Core CLI commands #4381
Conversation
| @@ -2,6 +2,8 @@ | |||
| <configuration> | |||
| <packageSources> | |||
| <add key="AspNetVNext" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" /> | |||
| <add key="dotnet-cli" value="https://www.myget.org/F/dotnet-cli/api/v3/index.json" /> | |||
| <add key="nugetbuild" value="https://www.myget.org/F/nugetbuild/api/v3/index.json" /> | |||
There was a problem hiding this comment.
@Eilon @pranavkm @victorhurdugaci It might be a chicken-and-egg problem, but are we going to add the CLI packages to our feed?
There was a problem hiding this comment.
For the xunit runner I actually manually pushed some CLI packages to our feed. If you need something from there, I think we should do the same thing as we do for CLR: gated-clone with some sort of verification.
There was a problem hiding this comment.
Yup! They had some issues with their packaging which was why I was avoiding pulling their packages in, but I could set up the CoreCLR configuration to clone the CLI packages.
There was a problem hiding this comment.
There's another problem. Since we don't always have the latest CLR, the packages in the dotnet-cli feed might require never versions.
There was a problem hiding this comment.
I'm not sure mismatched versions will be an issue. The common utility libraries are rather self-contained, so using different versions in different tools should be fine.
There was a problem hiding this comment.
My worry is that you'll not be able to restore because the packages on the CLI feed reference a newer version of the CLR which is not part of their feed and we only have the older version on aspnetcidev/volatile
There was a problem hiding this comment.
So what's the course of action here? I assume other tools are also starting to need these...
|
👍 |
| { | ||
| "version": "1.0.0-*", | ||
| "description": "Entity Framework Core Commands for .NET Core CLI.", | ||
| "repository": { |
There was a problem hiding this comment.
It looks like you added these in f2a1c5d. We're free to remove them now?
|
|
As you mention more error handling would be good, but this is a great first step.
bricelam
changed the title
Part of #3925
This commit puts a stake in the ground. I'm still getting assembly resolution errors locally that may or may not be related to CoreCLR/CLI issues. Most negative cases aren't handled very well. Etc. I'll continue to test and iterate on this, but I think it's at a good point to merge.
For reference, here's ye olde DNX Program.cs.