Skip to content

Conversation

@ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Nov 20, 2025

Contributes to #118583

For reference, this was last year's PR for net10.0. #106599

@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Nov 20, 2025
@dotnet-policy-service dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Nov 20, 2025
@am11 am11 added area-Infrastructure and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Nov 26, 2025
@dotnet-policy-service
Copy link
Contributor

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

@am11
Copy link
Member

am11 commented Nov 28, 2025

@ViktorHofer, does it depend on dotnet/dotnet#2271?

@ViktorHofer
Copy link
Member Author

Not necessarily but it would be better to get that in first. I included the branding update in this PR (see eng/Versions.props changes).

@ViktorHofer
Copy link
Member Author

ViktorHofer commented Dec 3, 2025

D:\a_work\1\s.dotnet\sdk\10.0.100-rc.2.25502.107\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(188,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 11.0. Either target .NET 10.0 or lower, or use a version of the .NET SDK that supports .NET 11.0. Download the .NET SDK from https://aka.ms/dotnet/download [D:\a_work\1\s\src\installer\tests\Assets\Projects\HostApiInvokerApp\HostApiInvokerApp.csproj]

Need this property: https://github.com/dotnet/runtime/blob/69310d88a431951addcc65ad093ea59528f80c48/Directory.Build.targets#L56C6-L56C30

@am11
Copy link
Member

am11 commented Dec 5, 2025

--- a/src/native/managed/cdac/Directory.Build.props
+++ b/src/native/managed/cdac/Directory.Build.props
@@ -1,5 +1,11 @@
 <Project>
     <Import Project="..\Directory.Build.props" />
+
+    <PropertyGroup>
+      <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
+      <AppendTargetFrameworkToOutputPath Condition="'$(BuildingInsideVisualStudio)' == 'true'">true</AppendTargetFrameworkToOutputPath>
+    </PropertyGroup>
+
     <ItemGroup>
       <AssemblyAttribute Include="System.Diagnostics.CodeAnalysis.ExperimentalAttribute">
         <_Parameter1>NETCDAC0001</_Parameter1>

@am11
Copy link
Member

am11 commented Dec 5, 2025

I didn't asked to move it out, I meant to add it in cDAC 🙂

@steveisok
Copy link
Member

I didn't asked to move it out, I meant to add it in cDAC 🙂

Bad use of words - meant the same thing.

@am11
Copy link
Member

am11 commented Dec 5, 2025

I didn't find that change pushed in this PR. Did you tried it locally on some community platform? Could you show the command (or just push to branch so we can see the error in CI).

@steveisok
Copy link
Member

I didn't find that change pushed in this PR. Did you tried it locally on some community platform? Could you show the command (or just push to branch so we can see the error in CI).

I tried it locally on cross building freebsd. Same exact restore error.

@am11
Copy link
Member

am11 commented Dec 5, 2025

I tested this patch am11@1cfe520 and built:

both passed the restore and cDAC package build and later failing at ApiCompat stage.

The reason why I was asking you for the command or pushing the change because just like my workflow, runtime CI is also using --bootstrap for community platform along --cross arg and that's the only supported combination for community platform these days. It's documented by @jkoritzinsky in the link I shared above.

@elinor-fung
Copy link
Member

HostActivation.Tests "hanging" on MacOS - likely unrelated

Yep, unrelated: #122171 (comment)

@jkoritzinsky
Copy link
Member

Looking at the patch, I believe @am11's patch is the right solution for the cDAC problem.

@steveisok
Copy link
Member

both passed the restore and cDAC package build and later failing at ApiCompat stage.

I tried it both locally and I see @lewing pushed a change. Neither work.

The TargetFramework part of the change produces Ahead-of-time compilation is not supported for the target runtime identifier 'freebsd-x64'. That is a different message, but it's still tanking on restore.

@lewing
Copy link
Member

lewing commented Dec 6, 2025

#122258 has sdk branding flow which will make it easier to solve the remaining workload issues here but we will keep both up to date. dotnet/sdk#52031 is in progress for the sdk
.

@am11
Copy link
Member

am11 commented Dec 6, 2025

@lewing, it turned out my branch was old, was based on older commit (which is why appcompat issue was present in my runs). Could you please apply:

am11@1dae2e4

it only affects community platforms and fixes the issue.

@steveisok
Copy link
Member

steveisok commented Dec 6, 2025

am11@1dae2e4

it only affects community platforms and fixes the issue.

Thanks for the suggestion. I think I understand why it was failing earlier. NetCoreAppToolCurrent isn't 11 and as a result, will skip

<PropertyGroup Condition="'$(DisableImplicitFrameworkReferences)' != 'true' and
'$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
'$(TargetFrameworkVersion)' == 'v$(NetCoreAppCurrentVersion)'">
<UseLocalTargetingRuntimePack Condition="'$(UseLocalTargetingRuntimePack)' == ''">true</UseLocalTargetingRuntimePack>
</PropertyGroup>
. That means it'll try to download the packs and can't.

If we try to change the TargetFramework to NetCoreAppCurrent, restore will fail because of some validation that produces Ahead-of-time compilation is not supported for the target runtime identifier 'freebsd-x64'. I think any solution to that needs to be done in a follow up.

@jkoritzinsky
Copy link
Member

We should update the logic to always use the local packs when UseBootstrapLayout is true. Then it should do the "right thing".

@am11
Copy link
Member

am11 commented Dec 6, 2025

We should update the logic to always use the local packs when UseBootstrapLayout is true. Then it should do the "right thing".

Yup, that will resolve #115622 as well. :)

Copy link
Member

Choose a reason for hiding this comment

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

Delete?

Copy link
Member

Choose a reason for hiding this comment

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

Are these translation files needed?

lewing and others added 4 commits December 6, 2025 15:21
…iversal.csproj

Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
…ion upgrades

It is tempting to read the version from an environment variable, but this
breaks scenarios where we do a major version upgrade (e.g., net10.0
to net11.0) because we may be running the test build from an older runtime.
private static readonly string s_latestTargetFramework = $"net{Environment.Version.Major}.0";
private static readonly string s_previousTargetFramework = $"net{Environment.Version.Major - 1}.0";
// are really the previous version.
private static readonly int TargetMajorVersion = 11; /* net11 */
Copy link
Member

Choose a reason for hiding this comment

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

private const int?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-Infrastructure linkable-framework Issues associated with delivering a linker friendly framework

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

9 participants