17.1 final branding#7225
Conversation
rainersigwald
left a comment
rainersigwald
left a comment
There was a problem hiding this comment.
Looks good but per usual I'm requesting changes to reduce the likelihood of an accidental merge.
| <Project> | ||
| <PropertyGroup> | ||
| <VersionPrefix>17.1.0</VersionPrefix> | ||
| <VersionPrefix>17.1.0</VersionPrefix><DotNetFinalVersionKind>release</DotNetFinalVersionKind> |
There was a problem hiding this comment.
I've been meaning to ask, why not add this to a new-line instead?
Like so…
| <VersionPrefix>17.1.0</VersionPrefix><DotNetFinalVersionKind>release</DotNetFinalVersionKind> | |
| <VersionPrefix>17.1.0</VersionPrefix> | |
| <DotNetFinalVersionKind>release</DotNetFinalVersionKind> |
There was a problem hiding this comment.
When it's on the same line, it's guaranteed to cause a merge conflict with the bump to 17.2. That ensures that when this branch is merged back to main we don't accidentally produce a "final release 17.2" build.
There was a problem hiding this comment.
- Review Block (on purpose)
- Merge Conflict (on purpose)
So, we have twice the protection!? 🤣👌
There was a problem hiding this comment.
Well, they're protection at different stages. The review block prevents us from merging this PR prematurely, that is, before we feel reasonably confident we're finished with 17.1 (pre-servicing); putting them on the same line ensures that when this merges into main, we don't keep the final branding.
I did this in a semi-automated way:
1. `Get-ChildItem -r src/PublicAPI.*.txt | Clear-Content`
2. Open MSBuild.sln in Visual Studio, let it settle
3. Find a green squiggle for the analyzer and fix all in solution
4. `Get-ChildItem -r PublicAPI.Unshipped.txt | % { Move-Item -Force -Path $_ (Join-Path $_.Directory.FullName "PublicAPI.Shipped.txt") && New-Item $_ }`
…ckonce sources (dotnet#7328) ClickOnce's msbuild task to generate the application manifest has code that imports COM Component by reading their registration data from the registry. In this scenario, the COM reference is an x86 binary that is registered under HKCR\WOW6432Node\Clsid node. In dev17 with msbuild being an x64 process, the code is not reading from the WOW6432Node. The fix is to update the code that's reads COM registration data to look under the WOW6432 node of HKCR as well. Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1463446. Co-authored-by: Sujit Nayak <sujitn@exchange.microsoft.com>
5 participants
...to be merged after 17.1 is updated (+ a little time in case something really high-pri comes in in the next couple weeks)