Add logic to gather respective WinMDs of dependent projection DLLs. #855
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We don't have an easy way of determine the WinMDs for the projection DLLs or determining which binaries are projection DLLs. But we do need the WinMDs to pass to CsWinRT and there is an option for developers of authoring components to pass them via a property. But to bring close to parity to the previous experience, we should also try to automate that. This change automates it for package references by gathering all the nuget packages in use based on the runtime DLLs and then uses that to gather any WinMDs in those packages. In case there is any issues with this logic, there is a property which allows it to be disabled. We probably need to look at doing something similar for project references when we address the WinMD leak issue.
Also did some cleanup and moved some targets for authoring scenarios in the main CsWinRT targets to the authoring targets.
Fixes #656