Implement NuGetPackageResolver.
See #5653
I essentially proposed a flavor of this in F# suggestions, but building on the awesome dotnet core nuget integration. It would seriously help with Azure Functions. I think it is time to look at this again. cc @tmat @filipw
So this is still not done?
We really need it for F# scripting and C# scripting.
It's a community standalone package at the moment, you can plug it into Roslyn if you need. See Dotnet.Script.DependencyModel.NuGet
here https://github.com/filipw/dotnet-script/releases/tag/0.14.0
@filipw I'm looking at NuGetMetadataReferenceResolver
but I can't see how it's providing NuGet references. It seems to merely wrap another resolver and when the #r
starts with "nuget" it returns a reference to its own assembly, which contains no other types. What am I missing? Where is the download of the package happening?
From https://github.com/dotnet/roslyn/pull/5653#issuecomment-145575763:
...we decided to postpone NuGet support to the next release.
That comment was written in October 2015. More than two years has passed and we still don't have this, IMHO, essential feature. I see that 8 days ago, it was removed from the 15.6 milestone (I was excited to see it on that milestone) and moved to "unknown". Is there a reason this keeps getting postponed (2 years and counting). I believe the ability to reference NuGet packages is they key to truly unlock .NET scripting into being generally useful.
I believe the ability to reference NuGet packages is they key to truly unlock .NET scripting into being generally useful.
I agree. NuGet provides an excellent extensibility model for scripting and makes bootstrapping all the requirements for a script much, much easier.
Is this ever going to make into a release or was this dropped permanently?
With C# 9 removing so much boiler plate from console apps, a console app is getting much closer to resembling a "script". If we added this feature to C# proper (not just some "scripting" variant) then all that is left is to do is add defaults for a couple more properties in csproj
:
OutputType
=> Exe
TargetFramework
=> the latest netcoreapp{x}.{y}
or net{x}.{y}
(in the case of .NET 5 and later) available...and then, in the simple case, we can skip csproj
entirely, and a console app can be a single cs
file!
this will be like the transition from nodejs with its package.json to deno with embedded import statements and single file executable!
Most helpful comment
With C# 9 removing so much boiler plate from console apps, a console app is getting much closer to resembling a "script". If we added this feature to C# proper (not just some "scripting" variant) then all that is left is to do is add defaults for a couple more properties in
csproj
:OutputType
=>Exe
TargetFramework
=> the latestnetcoreapp{x}.{y}
ornet{x}.{y}
(in the case of .NET 5 and later) available...and then, in the simple case, we can skip
csproj
entirely, and a console app can be a singlecs
file!