System.Xaml FileNotFoundException when using XmlnsPrefix and .resx in a referenced assembly

[koyote]

Hi,

When a .Net Core project references a .Net Framework project which has "XmlnsPrefix" set in AssemblyInfo AND we call code that accesses a resource in a .resx file, we get the following exception:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
File name: 'System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(MetadataToken caCtorToken, MetadataImport& scope, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, ListBuilder1& derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg) at System.Reflection.CustomAttribute.AddCustomAttributes(ListBuilder1& attributes, RuntimeModule decoratedModule, Int32 decoratedMetadataToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, ListBuilder`1 derivedAttributes)
at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType)
at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType)
at System.Reflection.RuntimeAssembly.GetCustomAttributes(Type attributeType, Boolean inherit)
at System.Attribute.GetCustomAttributes(Assembly element, Type attributeType, Boolean inherit)
at System.Attribute.GetCustomAttribute(Assembly element, Type attributeType, Boolean inherit)
at System.Reflection.CustomAttributeExtensions.GetCustomAttribute[T](Assembly element)
at System.Resources.ManifestBasedResourceGroveler.GetNeutralResourcesLanguage(Assembly a, UltimateResourceFallbackLocation& fallbackLocation)
at System.Resources.ResourceManager.CommonAssemblyInit()
at System.Resources.ResourceManager..ctor(String baseName, Assembly assembly)
at ClassLibrary1.Strings.get_ResourceManager() in Strings.Designer.cs:line 42
at ClassLibrary1.Strings.get_XXX() in Strings.Designer.cs:line 68

See attached Project:
ConsoleApp2.zip

[danmoseley]

@ericstj do you know where this should go?

[ericstj]

a .Net Core project references a .Net Framework project

We do our best to make .NETCore work with .NETFramework libraries when the types exist, but in the case of this sample the type used by the .NETFramework library (System.Xaml) doesn't exist in the base shared framework.

You can change your .NETCore console project use the WindowsDesktop sdk instead, this contains WPF and will be able to resolve System.Xaml. That's probably the best workaround if you're compiling for windows.

There's not a great way to avoid this since reflection needs to be able to load assemblies in order to reflect.

One could argue that Assembly.GetCustomAttribute(type) shouldn't throw for other attribute types which cannot be resolved, since the caller passed in a resolved runtime type. This is probably correct most of the time, but it could be wrong in the case the type that wasn't resolved was actually forwarding to the type you were looking for. Perhaps FilterCustomAttributeRecord could be improved to only throw when it cannot resolve a type and that type has the same name as the one your filtering on. Otherwise it can ignore the unresolved type since it cannot possibly match the one its looking for (since it has a different name). That makes this a make reflection more resilient bug, so keeping this tagged as reflection.

[ericstj]

/cc @steveharter

[steveharter]

Per discussion with @GrabYourPitchforks the proposed work-around will not work in the general case because GetCustomAttributes(Type) will enumerate all attributes that are compatible with Type (checking base types). So just comparing the type name wouldn't work.

We could attempt to detect it the Type passed in is sealed, but then this becomes very specific.

A better work-around is to have System.Resources.ManifestBasedResourceGroveler use GetCustomAttributeData instead of GetCustomAttribute so no attribute is instantiated. So moving to System.Resources.

Is this issue blocking any key scenarios?

[GrabYourPitchforks]

@buyaa-n @tarekgh We think a better workaround would be to change ManifestBasedResourceGroveler. See above.