You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Windows CSWinRT API targeting packs are going to be updating regularly. This means that libraries compiled with newer versions of the .NET SDK will have an assembly reference to higher versions of Microsoft.Windows.SDK.NET.dll. If a project that is using an older version of the .NET SDK consumes an updated library (ie via a NuGet package), then there will be an MSB3277 warning from ResolveAssemblyReferences, and a FileLoadException at runtime. (Depending on how types are shared, the build may also fail with a CS1705 compiler error.)
It would be better if an error would be consistently generated at build time that would be more helpful about what the problem is and how to resolve it (usually updating to a newer .NET SDK).
A way to support this could be to update the ResolveAssemblyReference task to optionally generate output items that describe the unresolved assembly conflicts. The .NET SDK would check for any such conflicts for the appropriate DLL and generate an appropriate error message.
Allow users to specify in OutputUnresolvedAssemblyConflicts (an optional parameter to RAR) that they want assembly conflicts provided in an output item and, if true, creates it.
Fixes#5934
The Windows CSWinRT API targeting packs are going to be updating regularly. This means that libraries compiled with newer versions of the .NET SDK will have an assembly reference to higher versions of Microsoft.Windows.SDK.NET.dll. If a project that is using an older version of the .NET SDK consumes an updated library (ie via a NuGet package), then there will be an MSB3277 warning from ResolveAssemblyReferences, and a FileLoadException at runtime. (Depending on how types are shared, the build may also fail with a CS1705 compiler error.)
It would be better if an error would be consistently generated at build time that would be more helpful about what the problem is and how to resolve it (usually updating to a newer .NET SDK).
A way to support this could be to update the ResolveAssemblyReference task to optionally generate output items that describe the unresolved assembly conflicts. The .NET SDK would check for any such conflicts for the appropriate DLL and generate an appropriate error message.
Related links:
The text was updated successfully, but these errors were encountered: