Agreed, the old way was basically a hack because it was the only way to get it working.  But a vsix is the “proper” solution for having an extension.  It’s unfortunate that installing a toolchain with a vsix only became possible in 2017, but that’s out of our control.<br><br>Shipping the old install batch files as-is but not updated for 2017 I guess is an option <br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 9, 2018 at 8:12 AM Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Aug 9, 2018 at 6:52 AM, degski <<a href="mailto:degski@gmail.com" target="_blank">degski@gmail.com</a>> wrote:<br>
> On Wed, 8 Aug 2018 at 20:49, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> Unfortunately the new integration will *not* work in vs2015. I meant to<br>
>> fix this in the vsix (that was the other change I forgot to push). The<br>
>> reason is that the ability of an extension to properly install itself as a<br>
>> toolchain only became possible in 2017, so there’s no way that I’m aware to<br>
>> even do this in 2015 with a vsix.<br>
><br>
><br>
> There seem to be (not me) an awful lot of people that cannot/don't want to<br>
> move from VS15 (or even VS13/12), so the above is unfortunate as we seem to<br>
> have moved from one extreme to the other. If one assumes a standard<br>
> installation of VS17, changing the (old) installer batch file to also<br>
> install for VS17 is not too hard. There is also this utility<br>
> <a href="https://github.com/Microsoft/vswhere" rel="noreferrer" target="_blank">https://github.com/Microsoft/vswhere</a>, which can help, in case of<br>
> non-standard installations. I'm not sure whether dealing with those more<br>
> complex situations is desirable, though. The people with the more complex<br>
> installations are probably also capable enough to get things working<br>
> correctly and satisfactory "old school".<br>
<br>
I don't think we want to go back to the old integration though, even<br>
if it can be made to work with VS 2017.<br>
<br>
It's cool that developers made that work on their own, and unfortunate<br>
that we broke it by not installing a ms-build-bin\cl.exe file. I<br>
suppose we could put that file back, but it also seems like a pretty<br>
narrow use case. Perhaps users who have managed to make the old<br>
extension still work for them could do the copy themselves.<br>
<br>
I'm not sure what the best thing to do is here. Shipping the new<br>
integration breaks users who were relying on the old one, but that<br>
also seems inevitable, and maybe worth it for having a new extension<br>
that works well with VS 2017.<br>
<br>
 - Hans<br>
</blockquote></div>