Skip to content

Conversation

@jonathanpeppers
Copy link
Member

@jonathanpeppers jonathanpeppers commented Oct 28, 2025

Context: #1287

We have a need again for Spectre.Console in .NET 11 (dotnet/sdk#51430).

Bringing back #1287, and addressing other issues.

  • Update spectre-console submodule to 0.52.0

  • Add patch file to delete problematic binaries:

#1287 (comment)

@jonathanpeppers jonathanpeppers changed the title Add Spectre.Console 0.52.0 (#1287) Add Spectre.Console 0.52.0 Oct 28, 2025
@jonathanpeppers
Copy link
Member Author

jonathanpeppers commented Oct 28, 2025

After mirroring Wcwidth.Sources 3.0.0 to dotnet-public, I also had to run:

./generate.sh --type text --package Wcwidth.Sources,3.0.0

@MichaelSimons
Copy link
Member

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jonathanpeppers jonathanpeppers marked this pull request as ready for review October 29, 2025 13:53
@jonathanpeppers jonathanpeppers requested a review from a team as a code owner October 29, 2025 13:53
Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, I triggered a run of a full unified build source-build to validate everything is working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintaining patches is non-trivial. As a follow-up I propose opening a issue/PR against Spectre.Console to see if they would be accepting of adding an msbuild property to condition this reference in order to eliminate the need for this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like they would only need PolySharp for the netstandard2.0 target framework, and we don't even build that?

I will send a PR to condition it, and see what they say.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch feels expensive to maintain. Any changes to these files will require regeneration of the patch. Because of the binary content, hand edits are likely off the table. What is the problem being solved here? Is this just a problem of checked in binaries?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, is there a better way to do this? We could probably exclude the entire docs folder, and the build would succeed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two options:

  1. Cloak the files from the VMR. Cloaking will prevent the files from getting mirrored to the VMR. To do this you add the path(s) to https://github.com/dotnet/dotnet/blob/main/src/source-mappings.json#L89. Here is an example.
  2. Add the binaries to allowed VMR binaries. Adding these files to https://github.com/dotnet/dotnet/blob/main/eng/allowed-vmr-binaries.txt will tell the system that these are known binaries allowed in the VMR. They will get stripped/removed when doing a source-build. If they are binaries required for source-build, then you would need to add them to https://github.com/dotnet/dotnet/blob/main/eng/allowed-sb-binaries.txt. As you mentioned they should be removed during source-builds.

If the files are sizable, I would lean towards cloaking. If they are minimal in number and size, allowed binaries feels appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the patch for now, and I will send a PR to dotnet/dotnet for allowed-sb-binaries.txt. 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this some more, I lean towards cloaking/excluding the entire docs folder. You will want to add that exclusion in the VMR prior to merging this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think we should cloak them

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the PR: dotnet/dotnet#3146

@jonathanpeppers
Copy link
Member Author

@akoeplinger I added src/externalPackages/patches/spectre-console/0002-Remove-problematic-binary-files.patch to delete the files mentioned in:

Are there any others I missed?

jonathanpeppers added a commit to jonathanpeppers/spectre.console that referenced this pull request Oct 29, 2025
Context: dotnet/sdk#51430
Context: dotnet/source-build-reference-packages#1447

We would like to use Spectre.Console for the `dotnet` CLI, and .NET has
to be able to be completely built from source.

It would help us to have `PolySharp` only included when building for
`netstandard2.0`, as that is the only target framework that needs the
polyfills.

.NET would probably only use the latest target framework.

Thanks!
@akoeplinger
Copy link
Member

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

jonathanpeppers added a commit to dotnet/dotnet that referenced this pull request Oct 29, 2025
Context: dotnet/source-build-reference-packages#1447
Context: dotnet/source-build-reference-packages#1287 (comment)

The docs folder contains binary files, that are not needed for building from source.
@MichaelSimons
Copy link
Member

FYI, The source-build-reference-packages-unified-build leg isn't going to pass until the cloak is defined. The binary check is going to fail and block the build.

@akoeplinger
Copy link
Member

ok I canceled it for now. we can retrigger it once dotnet/dotnet#3146 is merged

@MichaelSimons
Copy link
Member

ok I canceled it for now. we can retrigger it once dotnet/dotnet#3146 is merged

I force merged since the source-mappings aren't validated. Let's try again.

/azp run source-build-reference-packages-unified-build

@MichaelSimons
Copy link
Member

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jonathanpeppers
Copy link
Member Author

Did it fail because my PR here is from a fork? Or is there another error?

Context: dotnet#1287

* Update spectre-console submodule to 0.52.0

* Add patch file to delete problematic binaries:

dotnet#1287 (comment)

Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
@MichaelSimons
Copy link
Member

MichaelSimons commented Oct 29, 2025

Did it fail because my PR here is from a fork? Or is there another error?

I do not understand what the issue is. @dotnet/prodconsvcs - Can you help diagnose the sync failure here? Is this AFD related? TIA

@MichaelSimons
Copy link
Member

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@premun
Copy link
Member

premun commented Oct 30, 2025

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@premun
Copy link
Member

premun commented Oct 30, 2025

@MichaelSimons I had no idea we're still using vmr-sync.sh somewhere. I think this is a regression because we're changing these commands a bit.
I pinned darc version for now and that should fix it for now and I will make some adjustments in arcade-services to account for using it in this way still.

@akoeplinger
Copy link
Member

/__w/1/vmr/.dotnet/sdk/10.0.100-rc.1.25420.111/Roslyn/Microsoft.CSharp.Core.targets(84,5): error : Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:03000098:digital envelope routines::invalid digest [/__w/1/vmr/src/source-build-reference-packages/src/externalPackages/src/spectre-console/artifacts/clone/src/Spectre.Console/Spectre.Console.csproj::TargetFramework=net10.0]

Looks like we need to enable PublicSign so it doesn't try to do sign.

@akoeplinger
Copy link
Member

/azp run source-build-reference-packages-unified-build

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@MichaelSimons
Copy link
Member

@MichaelSimons I had no idea we're still using vmr-sync.sh somewhere. I think this is a regression because we're changing these commands a bit. I pinned darc version for now and that should fix it for now and I will make some adjustments in arcade-services to account for using it in this way still.

I believe this is done for the optional VMR legs that can be triggered from repo PRs.
https://github.com/dotnet/dotnet/blob/main/eng/pipelines/templates/jobs/vmr-build.yml#L377

@MichaelSimons MichaelSimons merged commit 1a7981f into dotnet:main Oct 30, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants