Only disable StartupHookSupport in non-Debug builds; remove MetadataUpdaterSupport from ILLink.targets

[Copilot]

Microsoft.NET.ILLink.targets was unconditionally disabling StartupHookSupport and MetadataUpdaterSupport for all trimmed/AOT builds, blocking Hot Reload in Debug AOT apps and overriding the SDK's correct per-configuration handling of MetadataUpdaterSupport.

Description

• Microsoft.NET.ILLink.targets
  • StartupHookSupport: added and '$(Configuration)' != 'Debug' to the condition — startup hooks (and thus Hot Reload) are preserved in Debug builds
  • MetadataUpdaterSupport: removed entirely — the SDK (Microsoft.NET.Sdk.targets) already sets this to false for non-Debug builds; ILLink.targets was erroneously overriding that in Debug

<!-- Before -->
<StartupHookSupport Condition="'$(StartupHookSupport)' == ''">false</StartupHookSupport>
<MetadataUpdaterSupport Condition="'$(MetadataUpdaterSupport)' == ''">false</MetadataUpdaterSupport>

<!-- After -->
<StartupHookSupport Condition="'$(StartupHookSupport)' == '' and '$(Configuration)' != 'Debug'">false</StartupHookSupport>

No test changes are included — per reviewer guidance, this kind of MSBuild targets testing is done in the SDK repo.

[dotnet-policy-service]

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

[MichalStrehovsky]

If we do this change, there will be a warning when publishing debug:

D:\>dotnet new console -o starthook
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring D:\starthook\starthook.csproj:
Restore succeeded.



D:\>cd starthook

D:\starthook>dotnet publish -c Debug -p:PublishTrimmed=true -p:StartupHookSupport=true
Restore complete (1.2s)
  starthook net10.0 win-x64 succeeded with 1 warning(s) (4.9s) → bin\Debug\net10.0\win-x64\publish\
    ILLink : Trim analysis warning IL2026: System.StartupHookProvider.ProcessStartupHooks(String): Using member 'System.StartupHookProvider.CallStartupHook(StartupHookProvider.StartupHookNameOrPath)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. The StartupHookSupport feature switch has been enabled for this app which is being trimmed. Startup hook code is not observable by the trimmer and so required assemblies, types and members may be removed.

Build succeeded with 1 warning(s) in 6.4s

Are we okay with that?

These are the intentional warnings that we put in place so that people are warned the feature will not work.

We could suppress the intentional warning in Corelib, but that breaks the promise that no warnings means the app will work the same with or without trimming.

I really wonder whether we should just introduce a private mechanism for this that corelib can check for in addition to StartupHookSupport and do something so we can still trim this when publishing.

Cc @dotnet/illink

[tmat]

@MichalStrehovsky We discussed options in #123778. Specifically comments #123778 (comment) and #123778 (comment).

What about updating runtimeconfig.json when it's being published to "System.Reflection.Metadata.MetadataUpdater.IsSupported": false?

Actually, I just found that there is a concept of .runtimeconfig.dev.json. It seems like that's what we want. Set "System.Reflection.Metadata.MetadataUpdater.IsSupported": true in .runtimeconfig.dev.json and "System.Reflection.Metadata.MetadataUpdater.IsSupported": false in .runtimeconfig.json, assuming that .dev takes precedence if present.

Unfortunately, it looks like configurationProperties specified in .runtimeconfig.json overwrite those in .runtimeconfig.dev.json:

runtime/src/native/corehost/runtime_config.cpp

Line 98 in f7fcd1c

m_properties[property.name.GetString()] = property.value.GetString();

@agocke is that intentional? It would make more sense the other way around.

[MichalStrehovsky]

@MichalStrehovsky We discussed options in #123778. Specifically comments #123778 (comment) and #123778 (comment).

I saw that, but I didn't see the warnings discussed. Warnings like this are problematic because it's a bad UX and people love to do WarningsAsErrors, then forget they set it and never think about it again, and get completely blocked by a relatively harmless warning.

It feels like what we need is to make this line conditional somehow:

https://github.com/dotnet/sdk/blob/61c38b063559ae55bf6d312ad9a5940aa5d5a0ea/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L708-L711

Would BuildingInsideVisualStudio property work (would it be set when doing publish in the VS UI)? Would we need something else for dotnet watch?

[tmat]

Would BuildingInsideVisualStudio property work (would it be set when doing publish in the VS UI)? Would we need something else for dotnet watch?

No, we don't want to use any such property. BuildingInsideVisualStudio is a hack that shouldn't even exist. I think the right solution is to use runtimeconfig.dev.json as described above and fix how properties in runtimeconfig(.dev).json are overridden.

[tmat]

Filed #126606

[agocke]

@elinor-fung for runtimeconfig/runtimeconfig.dev.json question