CsWinRT
CsWinRT copied to clipboard
Error MSB4018: The "GenerateDepsFile" task failed unexpectedly. when component is present.
Describe the bug When a CsWinRT component is referenced by an app and they both share a reference to ClassLibraryA, the build will fail with Error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
To Reproduce
- Create a WinAppSDK app or any other C# app.
- Create a CsWinRTComponent.
- Create a class library ClassLibraryA
- Reference the class library from both the app and the component.
Expected behavior Build and publishing of the app succeeds.
Version Info CsWinRT 1.5.0
Additional context The problem seems to be with https://github.com/microsoft/CsWinRT/blob/090a2796942eb5311598e16eb71a3d708eefffcf/nuget/Microsoft.Windows.CsWinRT.Authoring.targets#L164
@(TargetPathWithTargetPlatformMoniker) will contains not only the assembly for the current project, but also the assemblies from project references, which could by itself be WinMDs. The result is that TargetPathWithTargetPlatformMoniker is populated with broken values where the ManagedImplementation value point to another WinMD.

Do we have any workaround for this issue? @angelazhangmsft @j0shuams ? I have the exact same issue and it is very difficult for me to build the app :)
Hi! I have this same problem, I tried to investigate what could be happening and I found these conclusions:
-
The app doesn't need to reference the class library
-
It only happens if CsWinRT package is referenced in the CsWinRTComponent
-
If
<CsWinRTComponent>true</CsWinRTComponent>is removed, the whole project compiles, but doesn't work for what it was intended. -
This is the line where the compilation breaks: SingleProjectInfo.cs#L97
-
The build process throws the exception because CsWinRT makes the
sourceProjectFilefrom the class library point to the CsWinRTComponent. I set the following line right over the before the line I referenced above:Console.WriteLine("Source Project File: {0} Name: {1}, Version: {2}, OutputName: {3}", sourceProjectFile, name, version, outputName);And also a try-catch surrounding the addition. This is the output when building with the modified dotnet:
Source Project File: C:\path\to\solution\CsWinRTComponent.csproj Name: CsWinRTComponent, Version: , OutputName: CsWinRTComponent.dll Source Project File: C:\path\to\solution\CsWinRTComponent.csproj Name: ClassLibraryA, Version: , OutputName: ClassLibraryA.dllThen because both entries have the same source project file, and
sourceProjectFileis used as key when adding toprojectReferencesthe exception is launched.This is the output when CsWinRT is not referenced at CsWinRTComponent:
Source Project File: C:\path\to\solution\CsWinRTComponent.csproj Name: CsWinRTComponent, Version: , OutputName: CsWinRTComponent.dll Source Project File: C:\path\to\solution\ClassLibraryA.csproj Name: ClassLibraryA, Version: , OutputName: ClassLibraryA.dll -
For some reason, this issue can be workarounded in Visual Studio by first building the CsWinRTComponent project, and then the solution. I also tried with dotnet and msbuild, I could build the CsWinRTComponent project, but not the whole solution. EDIT: I found the way to perform this workaround with msbuild and dotnet: You need to build the CsWinRTComponent project, and then build the solution with the
BuildProjectReferencesproperty set to false (/p:BuildProjectReferences=false) and specifying as targets all the projects except CsWinRTComponent and the projects that CsWinRTComponent depends on (as they are already build).
I hope this info can help to solve this issue is solved as is a truly blocking problem for me.