Enable faster dev cycle in Visual Studio

[jonwis]

Added a custom build projection step to the test_component.vcxproj that consumes the just-built cppwinrt.exe for single-pass "build solution" dev inner loop.

The previous instructions said to build the cppwinrt.exe tool then run the build_projections.cmd. This way I can make a change to a base_foo.h strings file, hit "build solution", come back, and run tests directly.

I'm amenable to adding a specific new target that does projection into the root "targets" file. There's already build order dependencies between test components, so this isn't too much worse, but it does mean that "test_component.vcxproj" becomes a bottleneck. Could also have the cppwinrt project have a post-build step that does the projection, since all the test projects rely on it anyhow.

(Note that ARM64 and ARM targeting are still not directly supported for this; build the x86 configuration first, then ARM64 or ARM.)

[kennykerr]

The only reason for the somewhat contrived build process today is that release builds of cppwinrt are many many times faster than the debug builds. So I tended to run cppwinrt in release while building everything else in debug for testing and experimentation.

[jonwis]

The only reason for the somewhat contrived build process today is that release builds of cppwinrt are many many times faster than the debug builds. So I tended to run cppwinrt in release while building everything else in debug for testing and experimentation.

Sure - building debug on this system was a little slower, but the e2e cycle time of "touch base_string.h, debug test" is much nicer in a single IDE.

Are you suggesting that we not have this and retain the "touch base_string.h, switch to release, build just the main project, switch to debug, debug test" flow?

It's also reasonable to have the cppwinrt debug build enable some low-level optimization so it's still debuggable if necessary but faster than "no opt."

[kennykerr]

I'm just making sure you know where the unorthodox behavior originated. Maybe also chat with @oldnewthing who's also very familiar with this dance. I'm all for you improving the inner loop, I'm just not sure how much closer to release you can get with debug and debug is just really slow.

[jonwis]

Filed #1341 to track the failed linux builds for now.

[kennykerr]

Do you want to just update the windows-rs URLs in the short term to fix the build? I have no plans to move these any time soon:

https://github.com/microsoft/windows-rs/raw/master/crates/libs/bindgen/default/Windows.winmd