microsoft / win32metadata

Tooling to generate metadata for Win32 APIs in the Windows SDK.
Other
1.32k stars 113 forks source link

Building metadata projects outside vscmd results in failure to find cl.exe #1854

Open riverar opened 6 months ago

riverar commented 6 months ago

Just creating an official issue to track fixing a long time annoyance. dotnet build in a vanilla Terminal session results in midl.exe/cl.exe failures due to tooling paths not getting wired up correctly.

ChrisDenton commented 6 months ago

Should be possible to use vswhere to find the exes for us?

riverar commented 6 months ago

The Microsoft.Windows.WinmdGenerator SDK already pulls in Microsoft.Windows.SDK.CPP, i.e.:

https://github.com/microsoft/win32metadata/blob/9d6d88a6322f18672a1c9dacb70a641d85e28735/sources/GeneratorSdk/sdk/sdk.props#L48-L51

Which sets a bunch of properties, some of which we rely upon (e.g. WindowsSDKVersionedBinRoot to find midl.exe):

https://github.com/microsoft/win32metadata/blob/9d6d88a6322f18672a1c9dacb70a641d85e28735/sources/GeneratorSdk/sdk/sdk.targets#L124-L133

But then we also have these properties to contend with:

https://github.com/microsoft/win32metadata/blob/9d6d88a6322f18672a1c9dacb70a641d85e28735/sources/GeneratorSdk/sdk/sdk.props#L24-L31

And... that's as far as I've gotten at the moment. We just need to spend a bit more time following all the wires around, see what we've got, determine what *.SDK.CPP offers, and hopefully clean things up a bit so that we're working with a properly hydrated build environment.