Targets and PowerShell script to auto update project versions #222
Conversation
|
If it helps you can have a look at https://github.com/Azure/azure-sdk-for-net/blob/0076189829cb2e2c3139a64e221f0f53105b63e5/eng/scripts/Update-PkgVersion.ps1 which is what AzureSDK uses for the same task. We'll probably have our own needs based on style/conventions but it might have some interesting features/edge-cases to borrow. |
That's exactly where I got inspiration from. I was initially considering adopting their functionality and modifying it to match our needs, but I realized it is extremely complex and does a lot of things we most likely don't need. So instead I opted for keeping it as simple as possible, and increase complexity only where it's needed. For example, I'm wondering if I even need to have msbuild tasks at all, since I could easily do everything with powershell. |
|
Alright I reverted the msbuild changes, I'm doing everything with powershell now, it's much simpler and straightforward. I added a couple of commits that tested the script and it worked. I then reverted them because the endlines are getting changed, I don't want those changes merged. Now I need to work on the yaml. |
ericstj
left a comment
ericstj
left a comment
There was a problem hiding this comment.
Some of these comments were from before your latest changes, but leaving them in just to give perspective on target vs xml approach.
eng/scripts/Update-Packages.ps1
Outdated
| ) | ||
|
|
||
| $packageIdLower = $PackageId.ToLowerInvariant() | ||
| $url = "https://api.nuget.org/v3/flatcontainer/$packageIdLower/index.json" |
There was a problem hiding this comment.
We might want to make the feed a parameter - in case we version before pushing to NuGet.
There was a problem hiding this comment.
Good suggestion.
eng/scripts/Update-Packages.ps1
Outdated
|
|
||
| foreach ($assemblyVersion in $propertyGroup.Elements("AssemblyVersion")) | ||
| { | ||
| $assemblyVersion.Value = Get-NewVersion $assemblyVersion.Value -negativePosition -2 |
There was a problem hiding this comment.
How are you handling the cases where we don't want to change this version?
There was a problem hiding this comment.
Not being handled yet. I know azure does allow passing it as a parameter. I thought at the moment we didn't need it, as we would want the tool to update all the numbers in a consistent way. I think we could easily add such functionality in the future if we need it.
| if ($null -ne $conditionedVersionPrefix -and $conditionedVersionPrefix.GetType() -eq [System.Xml.Linq.XElement]) | ||
| { | ||
| if ($latestNuGetVersion -eq $conditionedVersionPrefix.Value) | ||
| { |
There was a problem hiding this comment.
For all of the below - do we want to fail if any are not found, or do any comparisons against latestNuGetVersion?
|
|
||
| foreach ($file in $msBuildVersionFilePaths) | ||
| { | ||
| $xdoc = [System.Xml.Linq.XDocument]::Load($file, [System.Xml.Linq.LoadOptions]::PreserveWhitespace) |
There was a problem hiding this comment.
If you wanted to try it there is an MSBuild construction API https://learn.microsoft.com/en-us/dotnet/api/microsoft.build.construction. Not sure it adds much value here since we're just modifying existing elements, but it might help with the save issues you were facing.
There's also native support for XML in powershell which might also be an option. I see some folks using it in dotnet repos including to modify projects: https://github.com/search?q=org%3Adotnet+%2F%5C%5Bxml%5C%5D%2F+path%3A*.ps1&type=code
eng/scripts/Update-Packages.ps1
Outdated
|
|
||
| $stringWriter = New-Object System.IO.StringWriter | ||
| $xmlWriterSettings = New-Object System.Xml.XmlWriterSettings | ||
| $xmlWriterSettings.Indent = $false |
There was a problem hiding this comment.
I think false is the default.
| $xmlWriterSettings.Indent = $false |
| If ($output.EndsWith("`r`n")) | ||
| { | ||
| $output = $output.Substring(0, $output.Length - 2) | ||
| } | ||
| ElseIf ($output.EndsWith("`n")) | ||
| { | ||
| $output = $output.Substring(0, $output.Length - 1) | ||
| } |
There was a problem hiding this comment.
Maybe [System.Xml.NewLineHandling]::None will fix this
There was a problem hiding this comment.
Okay I just realized that it's VS Code that adds the newline whenever I open the file, not the xml API. So I don't need the NewLineHandling nor these if/else.
There was a problem hiding this comment.
Hmm they're still getting added even if I open the file in notepad, and even if I add that NewLineHandline.None setting. Oh well, I'll have to keep the if/else.
There was a problem hiding this comment.
This worked for me:
[Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
$xdoc = [System.Xml.Linq.XDocument]::Load("in.csproj", [System.Xml.Linq.LoadOptions]::PreserveWhitespace)\
$xmlWriterSettings = New-Object System.Xml.XmlWriterSettings
$xmlWriterSettings.OmitXmlDeclaration = $true
$xmlWriterSettings.NewLineHandling = [System.Xml.NewLineHandling]::None
$xmlWriter = [System.Xml.XmlWriter]::Create("out.csproj", $xmlWriterSettings)
$xdoc.WriteTo($xmlWriter)
$xmlWriter.Close()It was able to round trip the project file produced by .NET new without any changes.
I also found that the built-in XML support in PS worked well as shown in those other scripts.
2 participants
Draft.
Problems to solve:
[xml]$csproj = Get-Content $projectFileor$csproj = New-Object System.Xml.XmlDocumentbecause simple elements get auto-converted to strings by PowerShell and there's no power in this planet to delete them and convert them back to XmlElements. What worked was usingAdd-Type -AssemblyName System.Xml.Linq; $csproj = [System.Xml.Linq.XDocument]::Load($CsprojPath).ProjectReferenceor the powershell script fails.