TypeDescriptor.GetConverter call always uses AssemblyLoadContext.Default

[AndreyTretyak]

Description

From the assembly loaded into Custom AssemblyLoadContext we are calling TypeDescriptor.GetConverter(Type) method. This method is defined in System.ComponentModel.TypeConverter.dll that is part of .NET 6 runtime, so it’s loaded into AssemblyLoadContext.Default.
Inside of the the TypeDescriptor.GetConverter(Type) there is a call to Type.GetType(string) for the type from the assembly that is loaded in Custom AssemblyLoadContext. So, unfortunately, it fails to get this type.
Calling Type.GetType(string) without TypeDescriptor.GetConverter(Type) in the same place from the assembly loaded in from the Custom AssemblyLoadContext returns type properly.

Reproduction Steps

To simplify repro I'll also add link to zip file with the sample solution.

Below is the description of the process to create this solution:

You need two projects to reproduce the issue. The first one will create an assembly (the TestAssembly) and the second one will run it in the Custom AssemblyLoadContext (the AssemblyLoadContextRepro).

TestAssembly code:

using System;
using System.ComponentModel;

namespace TestAssembly
{
  public class Test
  {
    public static void Run()
    {
      // Returns type from the Current AssemblyLoadContext properly.
      var type = Type.GetType("TestAssembly.MyClassConverter, TestAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");

      // Tries to get type from AssemblyLoadContext.Default and fails because of it.
      var fromConverter = TypeDescriptor.GetConverter(typeof(MyClass));
    }
  }

  [TypeConverter(typeof(MyClassConverter))]
  public class MyClass { }

  public class MyClassConverter : TypeConverter { }
}

AssemblyLoadContextRepro that would load assembly:

using System.Runtime.Loader;
using System.Reflection;
using System;
using System.IO;

namespace AssemblyLoadContextRepro
{
  internal class Program
  {
    static void Main(string[] args)
    {
      var context = new TestAssemblyLoadContext();
      var assembly = context.LoadFromAssemblyName(new AssemblyName("TestAssembly"));
      var type = assembly.GetType("TestAssembly.Test");
      var method = type.GetMethod("Run");
      method.Invoke(null, Array.Empty<object>());
    }
  }

  internal class TestAssemblyLoadContext : AssemblyLoadContext
  {
    private string assembliesLocation;

    public TestAssemblyLoadContext() : base("Custom")
    {
      // path to binaries of TestAssembly project.
      assembliesLocation = Path.Combine(Directory.GetCurrentDirectory(), @"..\..\..\..\TestAssembly\bin\Debug\net6.0\");
    }

    protected override Assembly Load(AssemblyName assemblyName)
    {
      var path = Path.Combine(assembliesLocation, assemblyName.Name + ".dll");
      if (File.Exists(path))
      {
        var assembly = this.LoadFromAssemblyPath(path);
        return assembly;
      }

      return null;
    }
  }
}

Expected behavior

I would prefer TypeDescriptor.GetConverter(Type) to behave in the same way as Type.GetType(string) and use AssemblyLoadContext of the code that calling it if possible. Because System.ComponentModel.TypeConverter.dll is distributed with .NET runtime and would be always loaded in AssemblyLoadContext.Default that makes it unusable for custom contexts.

Actual behavior

TypeDescriptor.GetConverter(Type) always use AssemblyLoadContext.Default and as a result unable to load converters from assemblies in Custom AssemblyLoadContext.

Regression?

No response

Known Workarounds

Wrapping call to into EnterContextualReflection allows it to work correctly:

using (AssemblyLoadContext.EnterContextualReflection(Assembly.GetExecutingAssembly())) 
{
 TypeDescriptor.GetConverter(type);
}

Not working workarounds:

• Loading assemblies into AssemblyLoadContext.Default defeats the purpose of having separate contexts.
• Loading System.ComponentModel.TypeConverter.dll into Custom AssemblyLoadContext allows Type.GetType(string) to get converter type, but we end up with the same assembly loaded into both contexts that make it unusable, for example, resulted type could not be assigned to ITypeConverter, because typeof(ITypeConverter) returns type from the System.ComponentModel.TypeConverter.dll in AssemblyLoadContext.Default. So TypeDescriptor.GetConverter(Type) fails to return converter in this case also.

Configuration

No response

Other information

No response

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

Issue Details

---

Description

From the assembly loaded into Custom AssemblyLoadContext we are calling TypeConverter.GetConverter(Type) method. This method is defined in System.ComponentModel.TypeConverter.dll that is part of .NET 6 runtime, so it’s loaded into AssemblyLoadContext.Default.
Inside of the the TypeConverter.GetConverter(Type) there is a call to Type.GetType(string) for the type from the assembly that is loaded in Custom AssemblyLoadContext. So, unfortunately, it fails to get this type.
Calling Type.GetType(string) without TypeConverter.GetConverter(Type) in the same place from the assembly loaded in from the Custom AssemblyLoadContext returns type properly.

Reproduction Steps

To simplify repro I'll also add link to zip file with the sample solution.

Below is the description of the process to create this solution:

You need two projects to reproduce the issue. The first one will create an assembly (the TestAssembly) and the second one will run it in the Custom AssemblyLoadContext (the AssemblyLoadContextRepro).

TestAssembly code:

using System;
using System.ComponentModel;
using Microsoft.VisualStudio.Services.Identity;

namespace TestAssembly
{
  public class Test
  {
    public static void Run()
    {
      // Returns type from the Current AssemblyLoadContext properly.
      var type = Type.GetType("Microsoft.VisualStudio.Services.Identity.IdentityDescriptorConverter, Microsoft.VisualStudio.Services.WebApi, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

      // Tries to get type from AssemblyLoadContext.Default and fails because of it.
      var fromConverter = TypeDescriptor.GetConverter(typeof(IdentityDescriptor));
    }
  }
}

TestAssembly.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> <!-- we need depdency dlls in bin folder to simplify loading -->
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.Services.InteractiveClient" Version="16.201.0-preview" />
  </ItemGroup>
</Project>

AssemblyLoadContextRepro that would load assembly:

using System.Runtime.Loader;
using System.Reflection;
using System;
using System.IO;

namespace AssemblyLoadContextRepro
{
  internal class Program
  {
    static void Main(string[] args)
    {
      var context = new TestAssemblyLoadContext();
      var assembly = context.LoadFromAssemblyName(new AssemblyName("TestAssembly"));
      var type = assembly.GetType("TestAssembly.Test");
      var method = type.GetMethod("Run");
      method.Invoke(null, Array.Empty<object>());
    }
  }

  internal class TestAssemblyLoadContext : AssemblyLoadContext
  {
    private string assembliesLocation;

    public TestAssemblyLoadContext() : base("Custom")
    {
      // path to binaries of TestAssembly project.
      assembliesLocation = Path.Combine(Directory.GetCurrentDirectory(), @"..\..\..\..\TestAssembly\bin\Debug\net6.0\");
    }

    protected override Assembly Load(AssemblyName assemblyName)
    {
      var path = Path.Combine(assembliesLocation, assemblyName.Name + ".dll");
      if (File.Exists(path))
      {
        var assembly = this.LoadFromAssemblyPath(path);
        return assembly;
      }

      return null;
    }
  }
}

Expected behavior

I would prefer TypeConverter.GetConverter(Type) to behave in the same way as Type.GetType(string) and use AssemblyLoadContext of the code that calling it if possible. Because System.ComponentModel.TypeConverter.dll is distributed with .NET runtime and would be always loaded in AssemblyLoadContext.Default that makes it unusable for custom contexts.

Actual behavior

TypeConverter.GetConverter(Type) always use AssemblyLoadContext.Default and as a result unable to load converters from assemblies in Custom AssemblyLoadContext.

Regression?

No response

Known Workarounds

Wrapping call to into EnterContextualReflection allows it to work correctly:

using (AssemblyLoadContext.EnterContextualReflection(Assembly.GetExecutingAssembly())) 
{
 TypeConverter.GetConverter(type);
}

Not working workarounds:

• Loading assemblies into AssemblyLoadContext.Default defeats the purpose of having separate contexts.
• Loading System.ComponentModel.TypeConverter.dll into Custom AssemblyLoadContext allows Type.GetType(string) to get converter type, but we end up with the same assembly loaded into both contexts that make it unusable, for example, resulted type could not be assigned to ITypeConverter, because typeof(ITypeConverter) returns type from the System.ComponentModel.TypeConverter.dll in AssemblyLoadContext.Default. So TypeConverter.GetConverter(Type) fails to return converter in this case also.

Configuration

No response

Other information

No response

Author:	AndreyTretyak
Assignees:	-
Labels:	area-AssemblyLoader-coreclr, untriaged
Milestone:	-

[agocke]

Vitek and I discussed this briefly. I'll try to summarize, Vitek can correct me. :)

There are two changes that could happen here. The first is to make TypeDescriptor.GetConverter essentially "ALC-aware" and try to 1) find the ALC that the target type lives in and 2) load the converter into a target ALC.

The second change is more of a work-around, that I think may deserve more attention as a broader design pattern. AssemblyLoadContext.EnterContextualReflection allows you to change the current contextual load context to a new one, and change the existing resolvers to resolve in the new load context. This would effectively cause Type.GetType to use the scoped ALC instead of the default one. This might be "safer" than relying on the framework fix. I don't think here's anything wrong with the framework fix, but this could present an alternative for "non-ALC-aware codepaths."

[vitek-karas]

The core of the issue is that the TypeConverterAttribute even if called with a System.Type stores the type name by immediately calling Type.AssemblyQualifiedName on it.
This means that:

• We lost the information where the type came from - in theory it can be from any ACL, not just Default or the one from where the type in question is.
• We're loosing perf, since we're forcing a creation of fully qualified name and later on we will be calling Type.GetType with that name again - effectively expecting to get back the exact same type as we started with - which is not guaranteed by any means.

Note that the same problem applies to the TypeDescriptorProviderAttribute as well, since it uses the exact same mechanism.

I think we should make two changes here:

• When resolving the type name into a type (here), use the ALC for the type of the object we're reflecting on (in the above method that would be _type.Assembly).
  • This can be done either by wrapping the call to Type.GetType with the EnterContextualReflection or by using the overload of Type.GetType which takes an assembly resolver callback and in it call the respective ALC.LoadFromAssemblyName. The latter is probably a bit cleaner as it's not relying on "context" and is very explicit. (although perf is unknown right now)
  • Note that this is technically a breaking change as the behavioral difference is observable - but I would argue the current behavior with regard to ALCs is just plain broken.
• The TypeConverterAttribute (as well as TypeDescriptorProviderAttribute) should add a private field which stores the Type passed in (if any), while still offering the full type name via the ConverterTypeName property (should be changed to be backed by a field and computed lazily to avoid the unnecessary full name creation). Then in the ReflectTypeDescriptionProvider use the Type field if available over the full name to completely avoid type resolution.
  • This is probably doable in a non-breaking way

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

Issue Details

---

Description

From the assembly loaded into Custom AssemblyLoadContext we are calling TypeDescriptor.GetConverter(Type) method. This method is defined in System.ComponentModel.TypeConverter.dll that is part of .NET 6 runtime, so it’s loaded into AssemblyLoadContext.Default.
Inside of the the TypeDescriptor.GetConverter(Type) there is a call to Type.GetType(string) for the type from the assembly that is loaded in Custom AssemblyLoadContext. So, unfortunately, it fails to get this type.
Calling Type.GetType(string) without TypeDescriptor.GetConverter(Type) in the same place from the assembly loaded in from the Custom AssemblyLoadContext returns type properly.

Reproduction Steps

To simplify repro I'll also add link to zip file with the sample solution.

Below is the description of the process to create this solution:

You need two projects to reproduce the issue. The first one will create an assembly (the TestAssembly) and the second one will run it in the Custom AssemblyLoadContext (the AssemblyLoadContextRepro).

TestAssembly code:

using System;
using System.ComponentModel;

namespace TestAssembly
{
  public class Test
  {
    public static void Run()
    {
      // Returns type from the Current AssemblyLoadContext properly.
      var type = Type.GetType("TestAssembly.MyClassConverter, TestAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");

      // Tries to get type from AssemblyLoadContext.Default and fails because of it.
      var fromConverter = TypeDescriptor.GetConverter(typeof(MyClass));
    }
  }

  [TypeConverter(typeof(MyClassConverter))]
  public class MyClass { }

  public class MyClassConverter : TypeConverter { }
}

AssemblyLoadContextRepro that would load assembly:

using System.Runtime.Loader;
using System.Reflection;
using System;
using System.IO;

namespace AssemblyLoadContextRepro
{
  internal class Program
  {
    static void Main(string[] args)
    {
      var context = new TestAssemblyLoadContext();
      var assembly = context.LoadFromAssemblyName(new AssemblyName("TestAssembly"));
      var type = assembly.GetType("TestAssembly.Test");
      var method = type.GetMethod("Run");
      method.Invoke(null, Array.Empty<object>());
    }
  }

  internal class TestAssemblyLoadContext : AssemblyLoadContext
  {
    private string assembliesLocation;

    public TestAssemblyLoadContext() : base("Custom")
    {
      // path to binaries of TestAssembly project.
      assembliesLocation = Path.Combine(Directory.GetCurrentDirectory(), @"..\..\..\..\TestAssembly\bin\Debug\net6.0\");
    }

    protected override Assembly Load(AssemblyName assemblyName)
    {
      var path = Path.Combine(assembliesLocation, assemblyName.Name + ".dll");
      if (File.Exists(path))
      {
        var assembly = this.LoadFromAssemblyPath(path);
        return assembly;
      }

      return null;
    }
  }
}

Expected behavior

I would prefer TypeDescriptor.GetConverter(Type) to behave in the same way as Type.GetType(string) and use AssemblyLoadContext of the code that calling it if possible. Because System.ComponentModel.TypeConverter.dll is distributed with .NET runtime and would be always loaded in AssemblyLoadContext.Default that makes it unusable for custom contexts.

Actual behavior

TypeDescriptor.GetConverter(Type) always use AssemblyLoadContext.Default and as a result unable to load converters from assemblies in Custom AssemblyLoadContext.

Regression?

No response

Known Workarounds

Wrapping call to into EnterContextualReflection allows it to work correctly:

using (AssemblyLoadContext.EnterContextualReflection(Assembly.GetExecutingAssembly())) 
{
 TypeDescriptor.GetConverter(type);
}

Not working workarounds:

• Loading assemblies into AssemblyLoadContext.Default defeats the purpose of having separate contexts.
• Loading System.ComponentModel.TypeConverter.dll into Custom AssemblyLoadContext allows Type.GetType(string) to get converter type, but we end up with the same assembly loaded into both contexts that make it unusable, for example, resulted type could not be assigned to ITypeConverter, because typeof(ITypeConverter) returns type from the System.ComponentModel.TypeConverter.dll in AssemblyLoadContext.Default. So TypeDescriptor.GetConverter(Type) fails to return converter in this case also.

Configuration

No response

Other information

No response

Author:	AndreyTretyak
Assignees:	-
Labels:	area-System.ComponentModel, area-AssemblyLoader-coreclr
Milestone:	7.0.0

[Floge123]

I tried the Workaround and while in one section it works by retrieving the converter from the correct ALC, in another section it does not:

It manages to load it from the Default ALC, because the Assembly containing the converter was loaded into the Default ALC, because it is referenced as a project in the project that creates the custom ALC and executes this code.