`assembly.GetTypes()` now includes System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes

[Smaug123]

Describe the bug

Before .NET 7, assembly.GetTypes() returned only types that were defined in my assembly. Now, if the assembly in question is a library and not an executable, it additionally returns System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes and System.Diagnostics.CodeAnalysis.DynamicDependencyAttribute.

This is true as of SDK 7.0.400; I have a vague recollection that it wasn't true of some earlier SDKs in the 7.0 series, but not sure about that.

I'm afraid I have absolutely no idea where this issue should go; dotnet/sdk is my best guess.

To Reproduce

Lib/Library1.fsproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <Compile Include="Thing.fs" />
    </ItemGroup>
</Project>

Lib/Thing.fs:

namespace Foo
type Foo = Foo

App/Program.fs:

namespace Foo

module Program =
    [<EntryPoint>]
    let main _ =
        typeof<Foo>.Assembly.GetTypes ()
        |> Array.iter (fun ty -> System.Console.WriteLine ty.FullName)
        0

App/App.fsproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net7.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
      <Compile Include="Program.fs"/>
    </ItemGroup>
    <ItemGroup>
      <ProjectReference Include="..\Lib\Library1.fsproj" />
    </ItemGroup>
</Project>

Running the app gives the following output, demonstrating the problem by its final two lines:

Lib.ThisAssembly
Foo.Foo
<StartupCode$Lib>.$Thing
<StartupCode$Lib>.$Lib.Version
<StartupCode$Lib>.$Lib.AssemblyInfo
<StartupCode$Lib>.$.NETStandard\,Version=v2.0.AssemblyAttributes
System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes
System.Diagnostics.CodeAnalysis.DynamicDependencyAttribute

Further technical details

dotnet --info:

.NET SDK:
 Version:   7.0.400
 Commit:    73bf45718d

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.0
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /nix/store/27hjfsgvv7bklnid729j27kifig070lb-dotnet-sdk-7.0.400/sdk/7.0.400/

Host:
  Version:      7.0.10
  Architecture: arm64
  Commit:       a6dbb800a4

.NET SDKs installed:
  7.0.400 [/nix/store/27hjfsgvv7bklnid729j27kifig070lb-dotnet-sdk-7.0.400/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.10 [/nix/store/27hjfsgvv7bklnid729j27kifig070lb-dotnet-sdk-7.0.400/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.10 [/nix/store/27hjfsgvv7bklnid729j27kifig070lb-dotnet-sdk-7.0.400/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download      

No IDE necessary.

[baronfel]

The dotnet/runtime repo is the place for all questions/problems with .NET BCL types and members. I'll go ahead and move this over.

[jkotas]

The new attribute types are auto-generated by F# compiler.

[Smaug123]

I see that DynamicallyAccessedMemberTypes is annotated with the CustomAttribute data CompilerGenerated, but System.Diagnostics.CodeAnalysis.DynamicDependencyAttribute is not annotated with any custom attributes. From looking over the type's data at runtime, I can't see any principled way we could discover that this type isn't actually part of my assembly.

[vzarytovskii]

Attributes are auto generated if not found for the target sdk/runtime. We do it for multiple attributes.

I'm not entirely sure I understand what's the issue here?

Generating attributes like that is a standard practice for both fsc and Roslyn.

From looking over the type's data at runtime, I can't see any principled way we could discover that this type isn't actually part of my assembly.

It is, in fact, part of assembly.

[Smaug123]

Could it be annotated with CompilerGeneratedAttribute? It's pretty odd that an SDK version bump can make your assembly look like it defines new types, with no indication that those types were not actually defined by the author.

[T-Gro]

We can.
Beware (I saw your PR in the ApiSurface PR which tries to exclude by name), there are more attributes like this which the compiler (both F# as well as Roslyn) includes conditionally, and more are coming in WIP PRs.

Have a look here:
https://sharplab.io/#v2:D4AQTAjAsAUCDMACciDCiDetE+UkALIgLIAUAlJtrgL6w1A=

The combination of:

    [CompilerGenerated]
    [Microsoft.CodeAnalysis.Embedded]

is something that can could be added (we do not generate the Embedded definition itself as of now, we would have to start doing it)

[vzarytovskii]

I don't personally think we should include Microsoft.CodeAnalysis.Embedded since it's entirely Roslyn thing, and part of Roslyn sdk.

[T-Gro]

Which then leaves the CompilerGeneratedAttribute.
I wanted to add it in, but realized it is being added already - to both the enum as well as the attribute.

@Smaug123: I think that the safest approach would be to filter out types having the CompilerGeneratedAttribute attribute