Will there be a custom provider injection ?

[freemstr]

Seeing that there is a growing number of requests for additional providers, would you consider adding
public class ProviderBase: IProvider
so that we create in our projects
public class CustomProvider: BaseProvider

And configuration akin to

{
  "version": "1.0",
  "defaultProvider": "./CustomProviderAssembly.dll; CustomProvider",
  "defaultDestination": "wwwroot/lib"
}

Thank you.

[jimmylewis]

This is a feature we are looking to design, but the discussions we've had so far have gotten caught up in how to ensure an experience works smoothly across all of our scenarios. Implementing a provider is pretty straighforward, but deploying the provider gets complicated quickly.

For example, we want to make sure that the provider can be fetched or restored in some way, so that you don't have to check in its DLL. This experience needs to consider restoring during build, through the CLI, and from VS. At the same time, in order for it to light up IntelliSense or the UI wizard in VS, we would need a VS extension (mainly, something with a .vsixmanifest to register MEF components, as that is how VS extensibility is implemented today).

So we're already trying to figure out if this means that a custom provider is implemented in layers (e.g. a NuGet package that provides restore support? And a separate VSIX for VS feature support?), or if there's a way we can consolidate these into a single package that can provide all of the requisite functionality. These decisions may impact the shape of IProvider or any of the other contract APIs, which is why we haven't really declared custom provider support as a feature yet.

/cc @justcla

[freemstr]

deploying the provider gets complicated quickly

Would it be simpler to cover custom providers in current project for now, this way developers can add external code as nuget or otherwise implement IProvider in the current project? IntelliSense and the extension UI and could hook to compiler for discovery and build process would use binaries coming from the project build itself.

[slaneyrw]

Can we please progress this, specifically allowing assets from NuGet feeds.

ASP.NET web projects allow NuGet packages with assets
ASP.NET Core web project don't.

We have a collection of NuGet packages in our private NuGet repository for handling all our client side assets that has no migration path into ASP.NET Core.

[slaneyrw]

Now I'm trying to bring in bootstrap SCSS... not available in any of the inbuilt providers, but IS available as a NUGET package.

[slaneyrw]

Any updates on this... or at least support NuGet packages
Migration from ASP.NET projects to ASP.NET Core where assets come from NuGet packages is currently impossible without effectively recreating the old PackageManager