You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say Alice is a .NET developer writing her own library which she plans to distribute via NuGet.
She's got her new CSProj goodness up to snuff so that everything is really just a matter of dotnet pack, dotnet test, etc.
Because she doesn't like generating version strings on-the-fly and instead much rather checks in the version string into a Directory.Build.props file at the root of the repository so that all projects in the repository get this version property set.
Now that she's ready for bringing her CICD game up to snuff;
for that she wants to use PowerShell.
dotnet test librarytests.csproj
dotnet pack library.csproj
dotnet nuget push library.nupkg -source X -k XAPIKey
Because she doesn't like msbuild target writing and she's forced by the ci service provider to do some magic with remotes in the powershell script already, she would like to git tag / git push directly in powershell.
But now she has a problem: Where does she get the current version string from? She doesn't want to move the version string into the powershell script, because that would mean that her local builds in VS would fall back to version 1.0.0. She also doesn't want to keep both variables.
At the end of the day she gives up, writes a target that generates a file with the string which she may read from powershell afterwards.
Instead of forcing the file writing path, i propose that we offer a read property command that we may use to read a specific property after evaluation.
It'd be super cool if we were able to read a given property value by querying it from the command line.
Example
Given the following project file
UseCase
Let's say Alice is a .NET developer writing her own library which she plans to distribute via NuGet.
She's got her new CSProj goodness up to snuff so that everything is really just a matter of
dotnet pack
,dotnet test
, etc.Because she doesn't like generating version strings on-the-fly and instead much rather checks in the version string into a
Directory.Build.props
file at the root of the repository so that all projects in the repository get this version property set.Now that she's ready for bringing her CICD game up to snuff;
for that she wants to use PowerShell.
Because she doesn't like msbuild target writing and she's forced by the ci service provider to do some magic with remotes in the powershell script already, she would like to
git tag / git push
directly in powershell.But now she has a problem: Where does she get the current version string from? She doesn't want to move the version string into the powershell script, because that would mean that her local builds in VS would fall back to version 1.0.0. She also doesn't want to keep both variables.
At the end of the day she gives up, writes a target that generates a file with the string which she may read from powershell afterwards.
Instead of forcing the file writing path, i propose that we offer a read property command that we may use to read a specific property after evaluation.
The text was updated successfully, but these errors were encountered: