How to publish an app using daily runtime packages? #84372

eerhardt · 2023-04-05T19:07:51Z

I'm seeing the following exception from the ASP.NET benchmarks for PublishTrimmed/ReadyToRun/SingleFile:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.RuntimeTypeHandle.RegisterCollectibleTypeDependency(System.RuntimeType, System.Reflection.RuntimeAssembly)
   at System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute(System.String, System.Reflection.RuntimeModule)
   at System.Reflection.CustomAttributeTypedArgument..ctor(System.Reflection.RuntimeModule, System.Reflection.CustomAttributeEncodedArgument)
   at System.Reflection.RuntimeCustomAttributeData.get_ConstructorArguments()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.GetDynamicallyAccessedMemberTypes(System.Type)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations(System.Type, System.Type[], System.Type, System.Type[])
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(System.Collections.Generic.ICollection`1<Microsoft.Extensions.DependencyInjection.ServiceDescriptor>, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
   at Program.<Main>$(System.String[])

Minimal Repro instructions

Using a recent .NET 8 SDK
dotnet publish the following app:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishSingleFile>true</PublishSingleFile>
  </PropertyGroup>

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>
</Project>

using System.Diagnostics.CodeAnalysis;
using System.Reflection;

Console.WriteLine(GetDynamicallyAccessedMemberTypes(typeof(MyGenericType<>).GetGenericArguments()[0]));

static DynamicallyAccessedMemberTypes GetDynamicallyAccessedMemberTypes(Type serviceGenericType)
{
    foreach (CustomAttributeData attributeData in serviceGenericType.GetCustomAttributesData())
    {
        if (attributeData.AttributeType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMembersAttribute" &&
            attributeData.ConstructorArguments.Count == 1 &&
            attributeData.ConstructorArguments[0].ArgumentType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes")
        {
            return (DynamicallyAccessedMemberTypes)(int)attributeData.ConstructorArguments[0].Value!;
        }
    }

    return DynamicallyAccessedMemberTypes.None;
}

internal class MyGenericType<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] T1>
{
}

.\bin\Release\net8.0\win-x64\publish\Net8Console.exe

Original Repro instructions

Using a recent .NET 8 SDK
git clone https://github.com/aspnet/Benchmarks
cd benchmarks\src\BenchmarksApps\BasicMinimalApi
Edit the BasicMinimalApi.csproj to ensure you are using a recent runtime version (I know that recent SDKs don't have the latest runtime currently):

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>

dotnet publish /p:PublishTrimmed=true /p:PublishReadyToRun=true /p:PublishSingleFile=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true
bin\Release\net8.0\win-x64\publish\BasicMinimalApi.exe

Expected result

The app should run successfully

Actual result

The above exception crashes the app

Notes

From looking at the last passing run to the first failing run, this appears to start occurring between 60b4804...390c2d5.

Looking through the commit list above I believe this is caused by #84159, since that change deleted the unmanged TypeNameParser and the exception stacktrace contains System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute. But I haven't verified that is the reason for this failure.

cc @jkotas @AaronRobinsonMSFT

The text was updated successfully, but these errors were encountered:

ghost · 2023-04-05T19:07:59Z

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

Issue Details

I'm seeing the following exception from the ASP.NET benchmarks for PublishTrimmed/ReadyToRun/SingleFile:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.RuntimeTypeHandle.RegisterCollectibleTypeDependency(System.RuntimeType, System.Reflection.RuntimeAssembly)
   at System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute(System.String, System.Reflection.RuntimeModule)
   at System.Reflection.CustomAttributeTypedArgument..ctor(System.Reflection.RuntimeModule, System.Reflection.CustomAttributeEncodedArgument)
   at System.Reflection.RuntimeCustomAttributeData.get_ConstructorArguments()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.GetDynamicallyAccessedMemberTypes(System.Type)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations(System.Type, System.Type[], System.Type, System.Type[])
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(System.Collections.Generic.ICollection`1<Microsoft.Extensions.DependencyInjection.ServiceDescriptor>, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
   at Program.<Main>$(System.String[])

Repro instructions

Using a recent .NET 8 SDK
git clone https://github.com/aspnet/Benchmarks
cd benchmarks\src\BenchmarksApps\BasicMinimalApi
Edit the BasicMinimalApi.csproj to ensure you are using a recent runtime version (I know that recent SDKs don't have the latest runtime currently):

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>

dotnet publish /p:PublishTrimmed=true /p:PublishReadyToRun=true /p:PublishSingleFile=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true
bin\Release\net8.0\win-x64\publish\BasicMinimalApi.exe

Expected result

The app should run successfully

Actual result

The above exception crashes the app

Notes

From looking at the last passing run to the first failing run, this appears to start occurring between 60b4804...390c2d5.

Looking through the commit list above I believe this is caused by #84159, since that change deleted the unmanged TypeNameParser and the exception stacktrace contains System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute. But I haven't verified that is the reason for this failure.

cc @jkotas @AaronRobinsonMSFT

Author:	eerhardt
Assignees:	-
Labels:	`untriaged`, `area-Extensions-DependencyInjection`
Milestone:	-

eerhardt · 2023-04-05T19:14:25Z

After doing some tweaks to the repro steps, this issue still exists if I do:

dotnet publish /p:PublishTrimmed=true /p:PublishSingleFile=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true

but it no longer happens when I do:

dotnet publish /p:PublishTrimmed=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true --sc

So it doesn't appear to be a ReadyToRun issue. But appears to be a combination of PublishTrimmed and PublishSingleFile. Looking at the stacktrace, PublishTrimmed is necessary because Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations only happens in publish trimmed apps. So the minimal repro might be calling CustomAttributeData.ConstructorArguments in a PublishSingleFile app. I've updated the top comment for the minimal app I can make that repros this issue.

jkotas · 2023-04-05T21:11:31Z

 <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />

This creates version mismatch. It upgrades the reference to the runtime pack, but not to the apphost pack. Single file apphost in apphost pack contains the build of the whole runtime. It means that we end up using new CoreLib with old runtime that results into this crash.

It does not repro with PublishSingleFile=false since the runtime and Corelib both come from the runtime pack and there is no mismatch.

ghost · 2023-04-05T21:13:46Z

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

I'm seeing the following exception from the ASP.NET benchmarks for PublishTrimmed/ReadyToRun/SingleFile:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.RuntimeTypeHandle.RegisterCollectibleTypeDependency(System.RuntimeType, System.Reflection.RuntimeAssembly)
   at System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute(System.String, System.Reflection.RuntimeModule)
   at System.Reflection.CustomAttributeTypedArgument..ctor(System.Reflection.RuntimeModule, System.Reflection.CustomAttributeEncodedArgument)
   at System.Reflection.RuntimeCustomAttributeData.get_ConstructorArguments()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.GetDynamicallyAccessedMemberTypes(System.Type)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations(System.Type, System.Type[], System.Type, System.Type[])
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(System.Collections.Generic.ICollection`1<Microsoft.Extensions.DependencyInjection.ServiceDescriptor>, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
   at Program.<Main>$(System.String[])

Minimal Repro instructions

Using a recent .NET 8 SDK
dotnet publish the following app:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishSingleFile>true</PublishSingleFile>
  </PropertyGroup>

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>
</Project>

using System.Diagnostics.CodeAnalysis;
using System.Reflection;

Console.WriteLine(GetDynamicallyAccessedMemberTypes(typeof(MyGenericType<>).GetGenericArguments()[0]));

static DynamicallyAccessedMemberTypes GetDynamicallyAccessedMemberTypes(Type serviceGenericType)
{
    foreach (CustomAttributeData attributeData in serviceGenericType.GetCustomAttributesData())
    {
        if (attributeData.AttributeType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMembersAttribute" &&
            attributeData.ConstructorArguments.Count == 1 &&
            attributeData.ConstructorArguments[0].ArgumentType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes")
        {
            return (DynamicallyAccessedMemberTypes)(int)attributeData.ConstructorArguments[0].Value!;
        }
    }

    return DynamicallyAccessedMemberTypes.None;
}

internal class MyGenericType<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] T1>
{
}

.\bin\Release\net8.0\win-x64\publish\Net8Console.exe

Original Repro instructions

Using a recent .NET 8 SDK
git clone https://github.com/aspnet/Benchmarks
cd benchmarks\src\BenchmarksApps\BasicMinimalApi
Edit the BasicMinimalApi.csproj to ensure you are using a recent runtime version (I know that recent SDKs don't have the latest runtime currently):

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>

dotnet publish /p:PublishTrimmed=true /p:PublishReadyToRun=true /p:PublishSingleFile=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true
bin\Release\net8.0\win-x64\publish\BasicMinimalApi.exe

Expected result

The app should run successfully

Actual result

The above exception crashes the app

Notes

From looking at the last passing run to the first failing run, this appears to start occurring between 60b4804...390c2d5.

Looking through the commit list above I believe this is caused by #84159, since that change deleted the unmanged TypeNameParser and the exception stacktrace contains System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute. But I haven't verified that is the reason for this failure.

cc @jkotas @AaronRobinsonMSFT

Author:	eerhardt
Assignees:	-
Labels:	`area-VM-coreclr`, `area-Host`, `untriaged`
Milestone:	-

eerhardt · 2023-04-05T21:27:54Z

FYI @sebastienros - this sounds be an issue with how we run jobs with dotnet/crank.

We also have #81382 for similar request with NativeAOT.

@agocke @vitek-karas @sbomer - What is the recommended/supported approach for specifying the Runtime Version explicitly? The crank benchmark infrastructure runs benchmarks on the latest runtime version without waiting for dotnet/runtime to flow all the way to dotnet/installer.

https://github.com/dotnet/crank/blob/ccca37ada2ed270b2b9d4fcda92e21efbccd7c3f/src/Microsoft.Crank.Agent/Startup.cs#L3581-L3614

jkotas · 2023-04-05T21:29:08Z

We do have documentation for how to use daily runtime packages at https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md#option-2-self-contained . Unfortunately, these instructions do not work. Setting RuntimeFrameworkVersion updates all packs versions including ASP.NET, but there is no guarantee that the ASP.NET packs of given version exist (they typically do not). These instructions should be updated.

agocke · 2023-05-04T22:53:04Z

I'm not sure what the right answer is here. I think RuntimeFrameworkVersion is ideally the right name -- and I would not expect it to alter the ASP.NET version. But it seems like that would be a breaking change now.

Is introducing a new NetRuntimeFrameworkVersion property the right answer?

sbomer · 2023-05-04T23:00:38Z

But it seems like that would be a breaking change now.

Yeah, and it sounds like the current behavior was intentional, based on dotnet/sdk#2792.

@dsplaisted might have opinions on the naming or the approach.

eerhardt · 2023-05-05T00:13:35Z

Bike-shedding on the name. Maybe

$(MicrosoftNETCoreAppVersion)
$(MicrosoftNETCoreAppRuntimeVersion)
$(MicrosoftNETCoreAppFrameworkVersion)
$(MicrosoftNETCoreAppRuntimeFrameworkVersion)

The first 2 seem like good names, but they are already used inside dotnet repos. So maybe we don't want to pick ones that are already used?

agocke · 2023-05-05T00:21:45Z

It's explicitly not just netcore app though -- it's also the host, and the Microsoft.DotNet.ILCompiler package.

lewing · 2023-05-05T01:01:02Z

the problem is much broader than this if you consider workloads which have similar version grouping problems (a compiler, other tasks, sdk packs)

jkotas · 2023-05-05T03:14:57Z

Instead of or in addition to creating new properties, we may want to document how to use the existing mechanisms to override default packs versions:

For example, I use this snippet when I want to compile a test app against my local netcoreapp ref pack and native aot publish it with my local native AOT pack:

  <ItemGroup>
    <KnownFrameworkReference Update="Microsoft.NETCore.App">
      <TargetingPackVersion>8.0.0-dev</TargetingPackVersion>
    </KnownFrameworkReference>
  </ItemGroup>
  <ItemGroup>
    <KnownILCompilerPack Update="Microsoft.DotNet.ILCompiler">
      <ILCompilerPackVersion>8.0.0-dev</ILCompilerPackVersion>
    </KnownILCompilerPack>
  </ItemGroup>

eerhardt · 2023-05-05T15:04:31Z

It's explicitly not just netcore app though -- it's also the host, and the Microsoft.DotNet.ILCompiler package.

To a "normal" dev (someone outside of dotnet/runtime), all of those things are part of Microsoft.NETCore.App, i.e. the runtime's shared framework. They are all built in the dotnet/runtime's official build.

Maybe this doesn't need to be an "officially" supported property, it really is for daily builds, which I don't think normal customers need to worry about.

So maybe calling it something that is tied to the repo's name would work.

Instead of or in addition to creating new properties, we may want to document how to use the existing mechanisms to override default packs versions:

I think documenting is a good idea. But I don't think it solves the problem because it is error prone. I need to know what kind of project is being built to know which snippet I need. For example, if I PublishSingleFile=true, I need a different snippet than above. And if I PublishTrimmed=true, I need yet another snippet. It makes it hard for a tool (like dotnet/crank) to figure out what to inject into the project. Where if we just had a single property, it makes it really hard to get it wrong.

jkotas · 2023-05-05T15:36:26Z

it really is for daily builds

The daily build problem is going to be solved by switching to unified build in .NET 9. There is going to be official daily build from dotnet/dotnet that has everything (runtime, ASP.NET, SDK) with all same versions.

eerhardt · 2023-05-05T17:02:58Z

How are tests going to work in that world? We will still have the same problem - there will be an SDK (with a runtime version) used for building ASP.NET. And there will be a separate runtime that ASP.NET is building against. When we run our tests, we will need our tests to run with the runtime that ASP.NET is built against, and not the runtime that came with the SDK.

jkotas · 2023-05-05T17:31:18Z

I would expect that you will set RuntimeFrameworkVersion to the latest daily build version (the daily build is going to have all packs with given version available so they will restore fine) and then you add the local ASP.NET projects or packages that you want to test.

eerhardt · 2023-05-05T17:38:46Z

So we couldn't run these ASP.NET tests until after the full daily build (including Windows.Desktop, SDK, etc) is done?

jkotas · 2023-05-05T18:02:49Z

In the unified build plan, there is just one official build that lives in dotnet/dotnet.

If you want to run the tests against official build, you need to wait for dotnet/dotnet build. There is no other official build.
If you want to run the tests against official build + locally built ASP.NET bits replaced, you will add your own locally built ASP.NET projects or packages. For example, this will be the flow for ASP.NET CI.
If you want to run the tests against locally built runtime + locally build ASP.NET + ..., I expect that the preferred workflow for that will be to apply everything onto dotnet/dotnet, create a local build of dotnet/dotnet, and run the tests against that.

agocke · 2023-05-05T18:41:05Z

I agree with Jan, that seems like a simpler model. In particular,

To a "normal" dev (someone outside of dotnet/runtime), all of those things are part of Microsoft.NETCore.App,

I think that's incorrect -- to a "normal" dev, I think all these things are part of the .NET SDK that they download. They have no idea about our internal package divisions. Using a "nightly" build of the SDK, or a property that we tell them is equivalent to using a "nightly" build of the SDK, is a simple concept that most developers will probably understand and be able to use easily.

ghost · 2023-07-17T20:15:32Z

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

Issue Details

I'm seeing the following exception from the ASP.NET benchmarks for PublishTrimmed/ReadyToRun/SingleFile:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.RuntimeTypeHandle.RegisterCollectibleTypeDependency(System.RuntimeType, System.Reflection.RuntimeAssembly)
   at System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute(System.String, System.Reflection.RuntimeModule)
   at System.Reflection.CustomAttributeTypedArgument..ctor(System.Reflection.RuntimeModule, System.Reflection.CustomAttributeEncodedArgument)
   at System.Reflection.RuntimeCustomAttributeData.get_ConstructorArguments()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.GetDynamicallyAccessedMemberTypes(System.Type)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations(System.Type, System.Type[], System.Type, System.Type[])
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(System.Collections.Generic.ICollection`1<Microsoft.Extensions.DependencyInjection.ServiceDescriptor>, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection, Microsoft.Extensions.DependencyInjection.ServiceProviderOptions)
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
   at Program.<Main>$(System.String[])

Minimal Repro instructions

Using a recent .NET 8 SDK
dotnet publish the following app:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishSingleFile>true</PublishSingleFile>
  </PropertyGroup>

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>
</Project>

using System.Diagnostics.CodeAnalysis;
using System.Reflection;

Console.WriteLine(GetDynamicallyAccessedMemberTypes(typeof(MyGenericType<>).GetGenericArguments()[0]));

static DynamicallyAccessedMemberTypes GetDynamicallyAccessedMemberTypes(Type serviceGenericType)
{
    foreach (CustomAttributeData attributeData in serviceGenericType.GetCustomAttributesData())
    {
        if (attributeData.AttributeType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMembersAttribute" &&
            attributeData.ConstructorArguments.Count == 1 &&
            attributeData.ConstructorArguments[0].ArgumentType.FullName == "System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes")
        {
            return (DynamicallyAccessedMemberTypes)(int)attributeData.ConstructorArguments[0].Value!;
        }
    }

    return DynamicallyAccessedMemberTypes.None;
}

internal class MyGenericType<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] T1>
{
}

.\bin\Release\net8.0\win-x64\publish\Net8Console.exe

Original Repro instructions

Using a recent .NET 8 SDK
git clone https://github.com/aspnet/Benchmarks
cd benchmarks\src\BenchmarksApps\BasicMinimalApi
Edit the BasicMinimalApi.csproj to ensure you are using a recent runtime version (I know that recent SDKs don't have the latest runtime currently):

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-preview.4.23181.16" />
  </ItemGroup>

dotnet publish /p:PublishTrimmed=true /p:PublishReadyToRun=true /p:PublishSingleFile=true /p:TrimMode=full /p:EnableRequestDelegateGenerator=true
bin\Release\net8.0\win-x64\publish\BasicMinimalApi.exe

Expected result

The app should run successfully

Actual result

The above exception crashes the app

Notes

From looking at the last passing run to the first failing run, this appears to start occurring between 60b4804...390c2d5.

Looking through the commit list above I believe this is caused by #84159, since that change deleted the unmanged TypeNameParser and the exception stacktrace contains System.Reflection.TypeNameParser.GetTypeReferencedByCustomAttribute. But I haven't verified that is the reason for this failure.

cc @jkotas @AaronRobinsonMSFT

Author:	eerhardt
Assignees:	-
Labels:	`area-NativeAOT-coreclr`
Milestone:	9.0.0

dotnet-policy-service · 2024-07-10T11:25:21Z

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

dotnet-issue-labeler bot added the area-Extensions-DependencyInjection label Apr 5, 2023

ghost added the untriaged New issue has not been triaged by the area owner label Apr 5, 2023

eerhardt added area-VM-coreclr and removed area-Extensions-DependencyInjection labels Apr 5, 2023

eerhardt mentioned this issue Apr 5, 2023

Failing pipeline, Native AOT Intel Windows aspnet/Benchmarks#1830

Closed

jkotas added the area-Host label Apr 5, 2023

jkotas removed the area-VM-coreclr label Apr 5, 2023

jkotas changed the title ~~AccessViolationException from RegisterCollectibleTypeDependency~~ How to publish an app using daily runtime packages? Apr 5, 2023

eerhardt mentioned this issue Apr 26, 2023

Add OptimizationPreference=Speed NativeAOT runs aspnet/Benchmarks#1840

Merged

sbomer mentioned this issue May 2, 2023

Clean up dead code in ILCompiler targets #85618

Merged

eerhardt mentioned this issue May 4, 2023

[main] Update dependencies from dotnet/runtime dotnet/efcore dotnet/aspnetcore#48014

Merged

jkotas mentioned this issue May 27, 2023

[NativeAOT] Improving HelloiOS sample for NativeAOT to be testable with runtime packs #86652

Merged

4 tasks

eerhardt mentioned this issue Jun 26, 2023

Update SDK dotnet/aspnetcore#48908

Merged

eerhardt mentioned this issue Jul 17, 2023

PublishAot with a specific Runtime version is broken #89040

Closed

agocke added this to the 9.0.0 milestone Jul 17, 2023

ghost removed the untriaged New issue has not been triaged by the area owner label Jul 17, 2023

agocke added area-NativeAOT-coreclr and removed area-Host labels Jul 17, 2023

MichalStrehovsky added area-Single-File and removed area-NativeAOT-coreclr labels Jul 10, 2024

agocke modified the milestones: 9.0.0, Future Jul 29, 2024

How to publish an app using daily runtime packages? #84372

How to publish an app using daily runtime packages? #84372

Comments

eerhardt commented Apr 5, 2023 • edited Loading

Minimal Repro instructions

Original Repro instructions

Expected result

Actual result

Notes

ghost commented Apr 5, 2023

Repro instructions

Expected result

Actual result

Notes

eerhardt commented Apr 5, 2023 • edited Loading

jkotas commented Apr 5, 2023 • edited Loading

ghost commented Apr 5, 2023

Minimal Repro instructions

Original Repro instructions

Expected result

Actual result

Notes

eerhardt commented Apr 5, 2023

jkotas commented Apr 5, 2023

agocke commented May 4, 2023

sbomer commented May 4, 2023

eerhardt commented May 5, 2023

agocke commented May 5, 2023

lewing commented May 5, 2023

jkotas commented May 5, 2023

eerhardt commented May 5, 2023

jkotas commented May 5, 2023

eerhardt commented May 5, 2023

jkotas commented May 5, 2023 • edited Loading

eerhardt commented May 5, 2023

jkotas commented May 5, 2023

agocke commented May 5, 2023

ghost commented Jul 17, 2023

Minimal Repro instructions

Original Repro instructions

Expected result

Actual result

Notes

dotnet-policy-service bot commented Jul 10, 2024

eerhardt commented Apr 5, 2023 •

edited

Loading

eerhardt commented Apr 5, 2023 •

edited

Loading

jkotas commented Apr 5, 2023 •

edited

Loading

jkotas commented May 5, 2023 •

edited

Loading