To support local servers, use .exe files from dependent projects as Implementation in Microsoft.Windows.CppWinRT.targets - #860
Conversation
Johan Laanstra (jlaanstra)
left a comment
There was a problem hiding this comment.
Kenny has indicated that he wants build changes to be validated on the OS, WinUI and Terminal before taking them.
| <TargetPath>$([System.IO.Path]::GetFileName('$(CppWinRTProjectWinMD)'))</TargetPath> | ||
| <Primary>true</Primary> | ||
| <Implementation Condition="'$(TargetExt)' == '.dll'">$(WinMDImplementationPath)$(TargetName)$(TargetExt)</Implementation> | ||
| <Implementation Condition="'$(TargetExt)' == '.dll' or '$(TargetExt)' == '.exe'">$(WinMDImplementationPath)$(TargetName)$(TargetExt)</Implementation> |
There was a problem hiding this comment.
VS never supported this for CX and so when support for WinRT was added we added the same limitation. We could possibly remove the TargetExt check alltogether. Not sure if you would run into any other roadblocks with that. If this should be a supported scenario, we can add support. A reference to an exe seems weird though.
There was a problem hiding this comment.
local servers are commonly implemented as a .exe (Win32 service is the other option).
There was a problem hiding this comment.
Johan Laanstra (@jlaanstra) and Kenny Kerr (@kennykerr) do you have advice on doing an OS and terminal build? Given this did not work before perhaps this is safe enough to not require that (me trying to shirk this work), let me know if you think so.
There was a problem hiding this comment.
😉 I do like the fact that it is a small and targeted change. We've just had a lot of problems with seemingly innocuous changes to the msbuild support that have had surprising compatibility issues in different environments. Johan Laanstra (@jlaanstra) has done this validation a few times - he may have some tips to quickly smoke out any issues.
There was a problem hiding this comment.
Chris Guzak (@ChrisGuzak) the way I generally go about this is to replace the CppWinRT props/targets used by a project and then do a full build. For the OS this means replacing the files under tools\cppwinrt (I can share a script I use to build a few known WinRT directories) and for terminal it means replacing the files in the expanded NuGet package under the packages folder and building terminal per instructions in their repo.
There was a problem hiding this comment.
Terminal has been validated. working on os.2020 next.
|
Terminal confirms success. |
Chris Guzak (ChrisGuzak)
left a comment
There was a problem hiding this comment.
merging into this branch so I can create a C++ WinRT package for testing
I found that if I create a WinRT local server project, a dependent app project won't build due to a missing file referenced in the .appxmanifest (the WinRT local server registration information that I added). The error lead me to this line in the build system that supports
.dlldependents, but not.exes. Adding the.exetest fixes this problem and seems appropriate (experts please advise).With this change a warning is still produced, it seems to to missing support in the .appxmanifest generation support.
This can be ignored.