New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a property to identify the cross-targeting/SDK project type #534

Closed
AArnott opened this Issue Dec 19, 2016 · 15 comments

Comments

Projects
None yet
8 participants
@AArnott
Contributor

AArnott commented Dec 19, 2016

The cross-targeting / SDK project type offer new functionality that a build extension may want to detect in order to reliably leverage (as opposed to setting properties and blindly hoping the new functionality is present).

Please define a new property that a build extension can check for to detect the use of the new SDK attribute in the project file.

Per a brief side discussion on #528 with @nguerrera.

@AArnott AArnott changed the title from A property should be defined to identify the cross-targeting/SDK project type to Define a property to identify the cross-targeting/SDK project type Dec 19, 2016

@srivatsn srivatsn added the Bug label Dec 21, 2016

@srivatsn srivatsn added this to the 1.0 RTM milestone Dec 21, 2016

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Dec 21, 2016

Member

More than just a property, we need to know how to call it when referring to it in documentation. It needs a "marketing name" too.

Member

onovotny commented Dec 21, 2016

More than just a property, we need to know how to call it when referring to it in documentation. It needs a "marketing name" too.

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Dec 30, 2016

Member

I'd suggest defining a property that indicates the version number of the .NET SDK that is being used. That way if a NuGet package depends on functionality in a new version of an SDK, the package can have MSBuild logic that will generate an error saying you need to use a newer SDK if the current version isn't high enough.

Member

dsplaisted commented Dec 30, 2016

I'd suggest defining a property that indicates the version number of the .NET SDK that is being used. That way if a NuGet package depends on functionality in a new version of an SDK, the package can have MSBuild logic that will generate an error saying you need to use a newer SDK if the current version isn't high enough.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Dec 30, 2016

Member

@dsplaisted Makes sense. Which version should we use? I think it should be System.Version parse-able to be friendly to msbuild's support for semantically correct comparisons of those.

Member

nguerrera commented Dec 30, 2016

@dsplaisted Makes sense. Which version should we use? I think it should be System.Version parse-able to be friendly to msbuild's support for semantically correct comparisons of those.

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Jan 6, 2017

Member

@nguerrera yes, I think it should be a System.Version version, and it would be nice to have another property indicating the semantic version suffix (ie "alpha-1234" or whatever)

Member

dsplaisted commented Jan 6, 2017

@nguerrera yes, I think it should be a System.Version version, and it would be nice to have another property indicating the semantic version suffix (ie "alpha-1234" or whatever)

@ericstj

This comment has been minimized.

Show comment
Hide comment
@ericstj

ericstj Jan 7, 2017

Member

+1 to this. I'm actually blocked on this. I'm creating a nuget package that needs to understand if its in nuget2 vs nuget3 vs nuget4 mode. I thought I had a good condition for this: dotnet/standard@09e9f9e#diff-de762529dcf068a5867280f815198927R9 but it looks like the properties I was using are actually set by targets imported after those imported by NuGet packages so my condition doesn't work 😕. Can you please set a property in .props that indicates the project is in PackageReference mode?

Member

ericstj commented Jan 7, 2017

+1 to this. I'm actually blocked on this. I'm creating a nuget package that needs to understand if its in nuget2 vs nuget3 vs nuget4 mode. I thought I had a good condition for this: dotnet/standard@09e9f9e#diff-de762529dcf068a5867280f815198927R9 but it looks like the properties I was using are actually set by targets imported after those imported by NuGet packages so my condition doesn't work 😕. Can you please set a property in .props that indicates the project is in PackageReference mode?

@ericstj

This comment has been minimized.

Show comment
Hide comment
@ericstj

ericstj May 11, 2017

Member

+1 again. I'd like to poison our new framework packages and point folks to update their SDK. I'd really like something explicit to trigger that on, rather than a side-effect of implementation.

Member

ericstj commented May 11, 2017

+1 again. I'd like to poison our new framework packages and point folks to update their SDK. I'd really like something explicit to trigger that on, rather than a side-effect of implementation.

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott May 11, 2017

Contributor

Maybe if folks +1 the top-level issue itself it will gain more visibility. :)

Contributor

AArnott commented May 11, 2017

Maybe if folks +1 the top-level issue itself it will gain more visibility. :)

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera May 11, 2017

Member

@dsplaisted can you poach this as part of your bug push?

Member

nguerrera commented May 11, 2017

@dsplaisted can you poach this as part of your bug push?

@ericstj

This comment has been minimized.

Show comment
Hide comment
@ericstj

ericstj May 11, 2017

Member

Ideally this is a property to identify both the SDK project type and the SDK version.

Member

ericstj commented May 11, 2017

Ideally this is a property to identify both the SDK project type and the SDK version.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera May 11, 2017

Member

What do you mean by sdk project type?

Member

nguerrera commented May 11, 2017

What do you mean by sdk project type?

@ericstj

This comment has been minimized.

Show comment
Hide comment
@ericstj

ericstj May 11, 2017

Member

What @AArnott described initially.

Member

ericstj commented May 11, 2017

What @AArnott described initially.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera May 11, 2017

Member

So "is this an sdk project or not" not "what kind of sdk project is this". Got it.

Member

nguerrera commented May 11, 2017

So "is this an sdk project or not" not "what kind of sdk project is this". Got it.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera May 23, 2017

Member

Implementing the boolean part in #1242. Plumbing the version through is more problematic so keeping that separate.

Member

nguerrera commented May 23, 2017

Implementing the boolean part in #1242. Plumbing the version through is more problematic so keeping that separate.

@livarcocc

This comment has been minimized.

Show comment
Hide comment
@livarcocc

livarcocc Jun 30, 2017

Member

Closing this issue in the SDK side and moving it to the CLI side to provide an SDK version property. We should do something similar to Microsoft.NETCoreSdk.BundledVersions.props.

Member

livarcocc commented Jun 30, 2017

Closing this issue in the SDK side and moving it to the CLI side to provide an SDK version property. We should do something similar to Microsoft.NETCoreSdk.BundledVersions.props.

@livarcocc

This comment has been minimized.

Show comment
Hide comment
@livarcocc

livarcocc Jun 30, 2017

Member

This issue was moved to dotnet/cli#7051

Member

livarcocc commented Jun 30, 2017

This issue was moved to dotnet/cli#7051

@livarcocc livarcocc closed this Jun 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment