Skip to content

17.14 - increase fsharpcore build version number #18718

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
Jul 10, 2025

Conversation

T-Gro
Copy link
Member

@T-Gro T-Gro commented Jun 26, 2025

Address #18712

KevinRansom and others added 7 commits April 25, 2025 09:15
#### AI description  (iteration 1)
#### PR Classification
This pull request is for a NuGet patch release, focusing on updating build configurations and dependencies.

#### PR Summary
This pull request updates build scripts and configuration files to support a new NuGet patch release, ensuring compatibility with updated Microsoft Build packages.
- `/eng/build.sh`: Added no-operation implementations for `--runtimesourcefeed` and `--runtimesourcefeedkey` arguments.
- `/eng/Versions.props`: Updated Microsoft Build package versions to use a unified `MicrosoftBuildVersion` variable.
- `/eng/SourceBuildPrebuiltBaseline.xml`: Added new usages for Microsoft Build packages with version `17.13.26`.
- `/azure-pipelines.yml`: Enabled internal sources for source build parameters.
- `/NuGet.config`: Added a new package source for `msbuild-Trusted`.
<!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot -->
rel/d17.14

----
#### AI description  (iteration 1)
#### PR Classification
NuGet package update for a specific release branch.

#### PR Summary
This pull request updates the Azure Pipelines configuration to target the `rel/d17.14` branch for Visual Studio insertion. This change ensures that the build and release processes are aligned with the correct branch for the upcoming release.
- Updated `azure-pipelines.yml` to set `VSInsertionTargetBranchName` to `rel/d17.14`.
<!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot -->
Copy link
Contributor

✅ No release notes required

@T-Gro T-Gro marked this pull request as ready for review June 27, 2025 07:08
@T-Gro T-Gro requested a review from a team as a code owner June 27, 2025 07:08
@github-project-automation github-project-automation bot moved this from New to In Progress in F# Compiler and Tooling Jun 27, 2025
T-Gro and others added 4 commits July 1, 2025 11:47
Otel exported led to a fatal crash in CI:

[xUnit.net 00:00:00.79] FSharp.Build.UnitTests: Catastrophic failure: System.IO.FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at OpenTelemetry.Trace.TracerProviderBuilderBase.Build()
   at OpenTelemetry.Trace.TracerProviderBuilderExtensions.Build(TracerProviderBuilder tracerProviderBuilder)
   at <StartupCode$FSharp-Test-Utilities>.$XunitHelpers.CreateExecutor@130.RunTestCases(IEnumerable`1 testCases, IMessageSink executionMessageSink, ITestFrameworkExecutionOptions executionOptions) in D:\a\_work\1\s\tests\FSharp.Test.Utilities\XunitHelpers.fs:line 142



Revisit this with conditional setting or a binding redirect
@T-Gro T-Gro requested a review from a team as a code owner July 3, 2025 13:12
@T-Gro T-Gro requested a review from a team July 3, 2025 13:12
@T-Gro
Copy link
Member Author

T-Gro commented Jul 3, 2025

@dotnet/source-build-internal :

Due to failing tests which related to usage of msbuild .dll (legacy project system which powers VS behavior for non-SDK style projects in VS), I had to update MS.Build.* dlls.

That in sequence lead to nuget mismatches, which I had to resolve by updating system packages to match what those msbuild packages needed.

This change is for a servicing branch only (aiming 9.0.303) and will not flow to main.

Is it in that case acceptable to have a change in prebuilt baseline?

@ellahathaway
Copy link
Member

ellahathaway commented Jul 3, 2025

@dotnet/source-build-internal :

Due to failing tests which related to usage of msbuild .dll (legacy project system which powers VS behavior for non-SDK style projects in VS), I had to update MS.Build.* dlls.

That in sequence lead to nuget mismatches, which I had to resolve by updating system packages to match what those msbuild packages needed.

This change is for a servicing branch only (aiming 9.0.303) and will not flow to main.

Is it in that case acceptable to have a change in prebuilt baseline?

Source build only builds out of 1xx feature bands (we plan to support multiple bands for 10.0). So yes, as long as these changes don’t flow to 9.0.1xx or main, it is acceptable to add the prebuilts to the prebuilt baseline.

@T-Gro
Copy link
Member Author

T-Gro commented Jul 4, 2025

Thank you @ellahathaway .
Could someone please approve on behalf of @dotnet/source-build here? The PR needs it.

@T-Gro T-Gro merged commit 5cf44dd into release/dev17.14 Jul 10, 2025
33 checks passed
@T-Gro T-Gro deleted the T-Gro-patch-fsharpcore-version branch July 10, 2025 07:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

6 participants