[wix-devs] WIP: Command-line Extension Acquisition and Cache

Sean Hall r.sean.hall at gmail.com
Mon Jun 1 16:59:29 PDT 2020

Based on "dotnet.exe tool", I think "wix.exe extension" makes sense.

Are we going to be implementing the nuget functionality ourselves or will
we build on top of it? Basically I'm wondering how wix.exe knows where the
feeds are.

I would vote to avoid having a local option. If we do have it, I would
recommend keeping the same structure (.wix folder in the current
directory). If we have a local option, then people are going to expect that
we have a packages.config/dotnet-tools.json equivalent where there's have a
manifest of all the extensions that the project needs with a corresponding
restore command. But then again maybe we need that anyway? How does wix.exe
pick which version to use?

For the MSBuild/dotnet build consideration (I would probably say dotnet
msbuild by the way, dotnet build is mostly an alias for dotnet msbuild
-restore), I agree. We should just rely on the underlying nuget
functionality there.

I also agree on requiring the .wixext.

On Tue, Jun 2, 2020 at 3:25 AM Rob Mensching via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> Last meeting WiX Extension availability for WiX v4 the first preview was
> raised as an issue. In particular, since we are starting the preview with
> only the command-line tools, the acquisition of extensions from NuGet is a
> pretty poor experience. Over the weekend I put together a proposal how to
> address that. I'm looking for feedback:
> https://wixtoolset.org/development/wips/6184-command-line-extension-acquisition-and-cache/
> Regards,
>   Rob Mensching
>   CEO
>   FireGiant
> _______________________________________________________________
> FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/

More information about the wix-devs mailing list