Open yishaigalatzer opened 8 years ago
I think it would make sense to put this into the existing $(TargetFrameworkDirectory)\RedistList\FrameworkList.xml
.
@mhutch we need to figure out how to find these
The logic is for determining the standard TargetFrameworkDirectory
location from a TFM is straightforward, as frameworks are installed into well-known locations.
This won't be sufficient for places where the user overrides the value in the project file or the targets customize the lookup e.g. in order to support SxS versioning. In those cases the value will need to come from MSBuild to be correct.
We are suggesting as a first step to create a MEF import for framework mapping support. This will enable extending/overriding without having to release a new version of nuget, even before we figure out the whole e2e story of describing the dependencies in files and in shipped frameworks. If we take such a change there is a chance for it to make it into 3.6 (vs15 RTM)
So I am wondering if there was any thought or discussion around this issue? I ask because I am running into an issue where I have a MSBuild SDK which defines a new TFM, and this TFM implicitly brings in a Runtime which then has API levels for which it could bring in based on the TFM.
Today we can do things like:
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Microsoft.NETCore.Platforms" version="2.0.0" />
</group>
</dependencies>
Though I am not allowed to profile my custom framework here because essentially it won't map to anything in FrameworkConstant.cs
or DefaultFrameworkMappings.cs
e.g:
<dependencies>
<group targetFramework="abc2.0">
<dependency id="ABC.API" version="2.0.0" />
</group>
</dependencies>
What would be nice is if I could include something in the nuget package that allowed me to define my own mappings etc... right now in order to work around this I am having to hack something in the Build target files where I am doing a condition on a PackageReference which really isn't that same thing because that is an explicit reference to the project not to the nuget package.
This is to allow platforms like Xamarin and .NET to control their own destiny when it comes to mapping .NET Standard (and perhaps more) through data files rather than hardcoding in the NuGet codebase.
This item needs design, and a discussion with both the .NET team and the Xamarin team.