This is related to #1392, but not a prerequisite for it.
It's currently difficult to determine what the path of an <Import> should be, because it requires knowing how to locate the file to be imported, using properties and relative paths.
#1392 introduces the concept of an "SDK" in order to automatically import an Sdk.props before the user project and an Sdk.targets after it. But that's often not sufficiently granular: sometimes you need to override a target (so your definition must be ordered after the imported one), or set a property before importing an initial target.
Design
<Project>
<user prop here>
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk/1.0.0.0" />
...
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk/1.0.0.0" />
<user target here>
</Project>
Should be syntactic sugar for something like
<Project>
<user prop here>
<Import Project="$(MSBuildSDKsPath)\%(___MSBuildSDK.Name)\%(___MSBuildSDK.Version)\Sdk.props" />
...
<Import Project="$(MSBuildSDKsPath)\%(___MSBuildSDK.Name)\%(___MSBuildSDK.Version)\Sdk.targets" />
<user target here>
</Project>
This is a) easier to type than the existing mechanism requiring a rooted path and b) doesn't lose any generality, as #1392 does.
This is related to #1392, but not a prerequisite for it.
It's currently difficult to determine what the path of an
<Import>should be, because it requires knowing how to locate the file to be imported, using properties and relative paths.#1392 introduces the concept of an "SDK" in order to automatically import an
Sdk.propsbefore the user project and anSdk.targetsafter it. But that's often not sufficiently granular: sometimes you need to override a target (so your definition must be ordered after the imported one), or set a property before importing an initial target.Design
Should be syntactic sugar for something like
This is a) easier to type than the existing mechanism requiring a rooted path and b) doesn't lose any generality, as #1392 does.