Summary
After upgrading to PostSharp 2026.0.11, a .NET Framework project that previously failed with the "Loop when loading Windows.winmd" error (#21) now fails during the build with a different error:
error: Cannot find the assembly 'system.runtime.windowsruntime, version=0.0.0.0, culture=neutral, publickeytoken=null'.
Environment
- PostSharp 2026.0.11
- .NET Framework project (e.g.
net48)
- The project consumes Windows Runtime (WinRT) types, and a
Windows.winmd file is present in the PostSharp search path.
What happens
The fix for #21 (shipped in 2026.0.10/2026.0.11) resolved the infinite loop that occurred while PostSharp read the Windows Runtime metadata (Windows.winmd). Now that the loop is gone, PostSharp reads the metadata further and tries to translate certain built-in Windows Runtime types (such as Windows.Foundation.Point, Rect, Size, and Windows.UI.Color) to their managed equivalents, which live in the System.Runtime.WindowsRuntime assembly.
If that assembly is not among the project references or PostSharp's search path, the build now stops with the error above instead of continuing.
Stack trace (reported by a customer)
Cannot find the assembly 'system.runtime.windowsruntime, version=0.0.0.0, culture=neutral, publickeytoken=null'.
at PostSharp.Sdk.CodeModel.Domain.GetAssembly(...)
at PostSharp.Sdk.CodeModel.Collections.TypeRefDeclarationCollection.FindType(...)
at PostSharp.Sdk.CodeModel.AssemblyRefDeclaration.FindType(...)
at PostSharp.Sdk.CodeModel.ModuleDeclaration.FindNamedType(...)
at PostSharp.Sdk.CodeModel.ModuleDeclaration.FindType(...)
at PostSharp.Sdk.Binary.ModuleReader.ApplyProjectionsToTypeRefs()
at PostSharp.Sdk.Binary.ModuleReader.ReadModule(...)
...
at PostSharp.Sdk.Extensibility.Project.Initialize()
Expected behavior
PostSharp should not fail the build when one of these projected Windows Runtime types cannot be mapped because its companion assembly is unavailable. It should leave the type unprojected and continue, exactly as it already does for Windows Runtime types that have no managed mapping.
Workaround
Add a reference to System.Runtime.WindowsRuntime (and, depending on the types used, System.Runtime.WindowsRuntime.UI.Xaml) to the project, or place these assemblies in the PostSharp search path.
Related
Follow-up to #21.
Summary
After upgrading to PostSharp 2026.0.11, a .NET Framework project that previously failed with the "Loop when loading Windows.winmd" error (#21) now fails during the build with a different error:
Environment
net48)Windows.winmdfile is present in the PostSharp search path.What happens
The fix for #21 (shipped in 2026.0.10/2026.0.11) resolved the infinite loop that occurred while PostSharp read the Windows Runtime metadata (
Windows.winmd). Now that the loop is gone, PostSharp reads the metadata further and tries to translate certain built-in Windows Runtime types (such asWindows.Foundation.Point,Rect,Size, andWindows.UI.Color) to their managed equivalents, which live in theSystem.Runtime.WindowsRuntimeassembly.If that assembly is not among the project references or PostSharp's search path, the build now stops with the error above instead of continuing.
Stack trace (reported by a customer)
Expected behavior
PostSharp should not fail the build when one of these projected Windows Runtime types cannot be mapped because its companion assembly is unavailable. It should leave the type unprojected and continue, exactly as it already does for Windows Runtime types that have no managed mapping.
Workaround
Add a reference to
System.Runtime.WindowsRuntime(and, depending on the types used,System.Runtime.WindowsRuntime.UI.Xaml) to the project, or place these assemblies in the PostSharp search path.Related
Follow-up to #21.