-
Notifications
You must be signed in to change notification settings - Fork 121
Added Directory Build and Packages.props #128
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove the one empty file and looks good
Does the complexity around having multiple build.props come from targeting two frameworks? I was just curious if we verified that we would still be able to publish both versions. Steve and I had planned on unifying the configuration to only target .NET 8 once it is released. |
Yeah, the multiple framework versions did force my hand on needing more than one build.props. In terms of whether the packages would publish, I had no issues building the nuget packages after the change. The contents of the nuget packages had both net7 and netstandard2 assemblies, but that was the extent of my testing. |
@KyleMcMaster We'll see about removing netstandard support - I got some negative feedback about doing that in another popular nuget package (ardalis/SmartEnum#363) |
Addresses this issue: #111
The packages one was pretty straight forward, but there's a little more nuance with the build props.
For the nuget packages, I setup a build props which consolidates some of the common package properties and the target frameworks.
For the sample and tests, I consolidated the framework version and C# nullable feature.
I'm open to suggestions on other ways of extracting common project configuration, but this seemed like an easy "low hanging fruit" consolidation.
I also updated the ignore file to ignore DS_Store files.