starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

[PR #12707] Terminal would benefit from having a single canonical version number for each of its NuGet dependencies #29196

New Issue
Open
opened 2026-01-31 09:33:26 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:33:26 +00:00
Owner
Copy Link

Original Pull Request: https://github.com/microsoft/terminal/pull/12707

State: closed
Merged: Yes

These changes are purely a refactoring of the build files. There should
be no difference to the compiled result or runtime behavior.

Currently there are packages.config files in lots of directories, with
those same projects referencing props/targets from packages/ with a
version string in the path. This is frustrating because version changes
or new dependencies require updating lots and lots of build files
identically. There is also the possibility of error where locations are
missed.

With these changes there is a single canonical nuget configuration that
takes effect for all of OpenConsole.sln. Updating version numbers
should be limited to a single set of global files.

The changes were done incrementally but the result is basically that
dep\nuget\packages.config serves as the global NuGet dependency list. A
pair of common build files (common.nugetversions.props and
common.nugetversions.targets) were added to contain the various imports
and error checks. There is also a special build target to ensure that
the restore happens before builds even though a given directory doesn't
have a packages.config for Visual Studio to observe.

These new .nugetversions. files are imported in pretty much every
vcxproj/csproj in the solution in the appropriate place to satisfy the
need for packages. There are opt-in configuration values (e.g.
TerminalCppWinrt=true) that must be set to opt into a given
dependency. Adding a new dependency is just a matter of adding a new
opt-in value. The ordering of include does matter, which was a
difficult challenge to realize and address.

There was also a preexisting issue in 3 test projects where
cppwinrt.props was included but not cppwinrt.targets. By consolidating
things globally that "error" was fixed, but broke the build in a way
that was very confusing. Those projects don't need the cppwinrt targets
so they were opted out of the cppwinrt build files entirely to fix the
breaks and get back to previous behavior.

There are two notable exceptions to this canonical versioning. The
first is that there are dueling XAML 2.7 dependencies. I avoided that
by leaving those as per-project package.config entries. The second is
that any projects outside of the .sln (such as the Island samples) were
not touched.

Validation Steps Performed

The primary validation is that the solution builds without errors. That
is what I'm seeing (x64|Debug). I also ran git clean -fdx from the
root of the repo to wipe it to clean and then opened the solution and
was able to build successfully. The project F5 deploys and looks fine
to me with just a cursory glance. The tests also largely pass (7418
pass, 188 fail, 14 other) which is as good or better than the baseline I
established from a clean clone.

Closes #12708

**Original Pull Request:** https://github.com/microsoft/terminal/pull/12707 **State:** closed **Merged:** Yes --- These changes are purely a refactoring of the build files. There should be no difference to the compiled result or runtime behavior. Currently there are packages.config files in lots of directories, with those same projects referencing props/targets from packages/ with a version string in the path. This is frustrating because version changes or new dependencies require updating lots and lots of build files identically. There is also the possibility of error where locations are missed. With these changes there is a single canonical nuget configuration that takes effect for all of OpenConsole.sln. Updating version numbers should be limited to a single set of global files. The changes were done incrementally but the result is basically that dep\nuget\packages.config serves as the global NuGet dependency list. A pair of common build files (common.nugetversions.props and common.nugetversions.targets) were added to contain the various imports and error checks. There is also a special build target to ensure that the restore happens before builds even though a given directory doesn't have a packages.config for Visual Studio to observe. These new *.nugetversions.* files are imported in pretty much every vcxproj/csproj in the solution in the appropriate place to satisfy the need for packages. There are opt-in configuration values (e.g. `TerminalCppWinrt=true`) that must be set to opt into a given dependency. Adding a new dependency is just a matter of adding a new opt-in value. The ordering of include does matter, which was a difficult challenge to realize and address. There was also a preexisting issue in 3 test projects where cppwinrt.props was included but not cppwinrt.targets. By consolidating things globally that "error" was fixed, but broke the build in a way that was very confusing. Those projects don't need the cppwinrt targets so they were opted out of the cppwinrt build files entirely to fix the breaks and get back to previous behavior. There are two notable exceptions to this canonical versioning. The first is that there are dueling XAML 2.7 dependencies. I avoided that by leaving those as per-project package.config entries. The second is that any projects outside of the .sln (such as the Island samples) were not touched. ## Validation Steps Performed The primary validation is that the solution builds without errors. That is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the root of the repo to wipe it to clean and then opened the solution and was able to build successfully. The project F5 deploys and looks fine to me with just a cursory glance. The tests also largely pass (7418 pass, 188 fail, 14 other) which is as good or better than the baseline I established from a clean clone. Closes #12708
claunia added the pull-request label 2026-01-31 09:33:26 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#29196
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?