Skip to content
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
Closed

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

AArnott opened this issue Dec 19, 2016 · 15 comments
Assignees
Labels
Milestone

Comments

@AArnott
Copy link
Contributor

@AArnott 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 A property should be defined to identify the cross-targeting/SDK project type 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
@clairernovotny
Copy link
Member

@clairernovotny clairernovotny 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
Copy link
Member

@dsplaisted 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
Copy link
Member

@nguerrera 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
Copy link
Member

@dsplaisted 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
Copy link
Member

@ericstj 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
Copy link
Member

@ericstj 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
Copy link
Contributor Author

@AArnott AArnott commented May 11, 2017

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

@nguerrera
Copy link
Member

@nguerrera nguerrera commented May 11, 2017

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

@ericstj
Copy link
Member

@ericstj ericstj commented May 11, 2017

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

@nguerrera
Copy link
Member

@nguerrera nguerrera commented May 11, 2017

What do you mean by sdk project type?

@ericstj
Copy link
Member

@ericstj ericstj commented May 11, 2017

What @AArnott described initially.

@nguerrera
Copy link
Member

@nguerrera nguerrera commented May 11, 2017

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

@nguerrera
Copy link
Member

@nguerrera nguerrera commented May 23, 2017

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

@livarcocc
Copy link
Contributor

@livarcocc 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
Copy link
Contributor

@livarcocc livarcocc commented Jun 30, 2017

This issue was moved to dotnet/cli#7051

@livarcocc livarcocc closed this Jun 30, 2017
mmitche pushed a commit to mmitche/sdk that referenced this issue Jun 5, 2020
* Moving the Import profile logic to a separate file

* Removing an unwanted comment from the target file

* Splitting the Sdk and targets folder
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.