Ability to extend Default Mappings

[wackoisgod]

Details about Problem

NuGet product used: VS UI : Issue is true across all products

NuGet version (x.x.x.xxx): latest dev

dotnet.exe --version (if appropriate):

VS version (if appropriate): 16.7.2

OS version (i.e. win10 v1607 (14393.321)):

Worked before? If so, with which NuGet version: No

Detailed repro steps so we can see the same problem

So the issue here is in the Nuget.Client I cannot in anyway extend the ability to provide Compatibility mappings from customer frameworks from what I can tell. Everything is harcoded so if I have a setup where I have:

NetStandard 2.0 Lib is depending on a CustomFramework Lib which is a subset of Netstandard... I will eventually just run into issues where Nuget complains that NetStandard 2.0 is not compatible with that CustomFramework and from what I can tell there is no way for me to change this or extend it to allow for this. Since the Compatibility mappings are hardcoded into Nuget.

Is there a way to extend this? or add your own Compat/Subset mappings?

[dominoFire]

Unfortunately, there's no concept of custom NuGet Frameworks at this time.

Upcoming releases of net5.0 will have support for OS-specific framework APIs. See https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md

Hope that helps.

[wackoisgod]

@dominoFire Is there ever a plan to support this? Unity has a subset of the netstandard that it uses for one of its runtimes, we have defined this as a custom TFM, but essentially you are saying that we could not ever make it compatible with Nuget?

[dominoFire]

@wackoisgod I haven't heard of Unity custom runtime. If that is based on .NET standard, you can try to use netstandard2.0 as TFM. Use the .NET Standard version closest to the Unity runtime version. After all, .NET standard is an API specification that a runtime can support.

It seems that Unity support .NET Standard 2.0: https://docs.unity3d.com/Manual/dotnetProfileSupport.html

You could also try setting a <RuntimeIdentifier/> in your project file and see how it behaves in Unity: https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#runtimeidentifier

Regarding custom framework support in NuGet. I not aware of any plans. @anangaur @chgill-MSFT @jcjiang do you have any thoughts?

[wackoisgod]

Yea so we had an open task about 6 months ago around this. #9347 where we had spoken around having a custom TFM. Which we can do using MSBuild SDKs except for the nuget support.

[dominoFire]

@wackoisgod Sorry, I missed that issue.

[wackoisgod]

@dominoFire should we keep this issue closed? Or should we engage on the other issue? This is important for us to resolve if we can. I mean right now my only thinking is that we add our own task that essentiallys resolves thing but that would be overriding Nugets behaviour when using the MSBuild SDK but I don't think that scales.

[zivkan]

It's unclear to me if you work for Unity. If so, I think you should already have contacts within Microsoft with "high level" .NET PMs and architects. At least, I have the impression that .NET PMs are in contact with Unity. Otherwise, I think a new issue in dotnet/design would be worthwhile.

2 days ago, Immo posted a blog titled "The Future of .NET Standard". In it, he explains the same type of issues as you're explaining, from the Blazor/webassembly team. They decided not to have a TFM, but instead use an SDK with analyzers.

If that doesn't work for you, I'd rather an end-to-end design on how customers can implement .NET using a subset of the .NET Standard APIs, rather than trying to shoehorn something into NuGet, and then you find another part of the .NET build chain doesn't work well. I imagine that IoT use-cases, Tyzen, and others will also benefit from an end-to-end design.

[wackoisgod]

@zivkan I do work for Unity :D and we have reached out to our contact on the Microsoft side(@rrelyea), and I just posted this issue here more so for visiblity and potentially a quick fix if there was one. I agree that producing a solution that in the long-term resolves for this kinds of usecases.

I have not read Immo's post and will look at that and see if that is reasonable for us, if not I think we It would be wise to as you mentioned come up with a proper purposal for this kind of thing.

[dominoFire]

@dominoFire should we keep this issue closed? Or should we engage on the other issue? This is important for us to resolve if we can. I mean right now my only thinking is that we add our own task that essentiallys resolves thing but that would be overriding Nugets behaviour when using the MSBuild SDK but I don't think that scales.

@wackoisgod I think it's better to engage in the other issue #9347 ;