dotnet tool install --global wix - Need for all users

[abskulkarni]

Hi @oleg-shilo
While compiling WixSharp v4 project, I need to run install dotnet tool install --global wix for wix.exe and extesion. However, it install Wix under %USERPROFILE%.dotnet folder.
It is creating a problem as we build same application on our build server where we need to use service account which cannot be used interactively and install Wix in its profile folder.

Question is, how we can install Wix.exe for all users? (dotnet tool install --global wix)
Like instead of %USERPROFILE%, it should install in some global folder & WixSharp still finds it.
By the way, I tried with using --tool-path option in dotnet tool install and installed wix.exe in custom path, added that path in PATH env variable. But still WixSharp project compilation failed saying it cannot find wix.exe.

Also another question : how does wix.exe is referred by WixSharp project while building MSI? Can we manipulate/change wix.exe path referenced by WixSharp project?

[oleg-shilo]

Question is, how we can install Wix.exe for all users? (dotnet tool install --global wix)
Like instead of %USERPROFILE%, it should install in some global folder & WixSharp still finds it.

This is completely outside of WixSharp control. I am not sure if .NET Tool manager allows that.
Adding the custom location to PATH is expected to solve the problem. See this lookup algorithm:
https://github.com/oleg-shilo/wixsharp/blob/wix-v4-master/Source/src/WixSharp/CommonTasks.cs#L2079

Though I cannot test this scenario right now.

You can also go with installing wix as a local tool. You create the tool-manifest file and indicate there that you need wix. Then during the build will will be downloaded and copied to the project dir without the need to use anything interactively.

[oleg-shilo]

Only one correction to my above suggestion about "local tool".
After creating the tool-manifest file you need to call "dotnet tool restore" from the proj folder. This will install the right version of the tool but, again, without any user interaction.

[smaudet]

Similar issue, I'm running into a problem on a build server that doesn't even have "dotnet" installed. I was somewhat surprised too, however you don't need "dotnet.exe" to have a working msbuild package.

For these issues I would propose the following:

You are likely being pulled in via nuget, so:

1. Create a package of wix, installing that separately via nuget (I am actually already doing this with a private package).
2. Don't rely on dotnet at all, instead invoke nuget to install required packages, or prompt them to be installed during development build.

There are a number of issues here, however the biggest is that you have (a ton of) "hidden" dependencies - things that work as an accident of something else being installed, that only show up when run in a (properly) constrained environment. Not only with dotnet, but with wix too - I am also trying to work around a shortcoming in wix that assumes extensions are either referenced by wixproj or installed into a .wix directory.

I suspect others would prefer to remove the hidden dependencies and rather have the dependencies listed directly, as needed.

[smaudet]

        string userProfilePath = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
        string wixDirsPath = Path.Combine(userProfilePath, ".wix");
        string wixExtPath = Path.Combine(wixDirsPath, "extensions");
        string wixSharpPath = Path.Combine(wixDirsPath,".wixsharp");
        string wixSharpToolsPath = Path.Combine(wixSharpPath, "wix.tools");
        string wixPublishDir = Path.Combine(wixSharpToolsPath, "publish");
        Directory.CreateDirectory(wixPublishDir);

E.g. now I have something like this in my setup code, specifically to stop WixSharp.CommonTasks.WixTools.EnsureDtfTool from running, which fails because dotnet is not present. Instead I pull in the WixToolset.Dtf.CustomAction, WixToolset.Dtf.WindowsInstaller, WixToolset.Heat packages explicitly in my setup project before I run project.BuildMsi()

It would be nicer if I could just turn off this check, or even better yet if I could configure BuildMsi to yell at me if I'm missing dependencies, rather than running a tool silently in the background.

@oleg-shilo Perhaps this is a new feature, maybe I'll create a PR?

[oleg-shilo]

Interesting...
WiX team expects that the WiX tools are always deployed on the build via dotnet. If you do not have it then ... you are not deviating from what they documented as the way to deploy WiX tools.

It is OK, after all, it's your decision. However, I am so puzzled about the CI that has no .NET installed. How does the project compile? MSBuild comes with .NET SDK, which also contains dotnet.exe. Does it mean that you are compiling against the .NET Framework? The only SDK that does not have dotnet.exe included.

Anyway, back to your point.
From the WixSharp point of view, the user could always indicate where the tools are in Wix3 stream:

        Compiler.WixLocation = @"..\..\Wix_bin\";
        Compiler.WixSdkLocation= @"..\..\Wix_bin\SDK\";

However, in Wix4 I removed this option because... I thought I could rely on the presence of dotnet.exe :)
Currently, only one tool can be configured by the user:

WixTools.SignTool = @"<your path>\signtool.exe";

But I just have changed the implementation and in the next release this approach will be extended to the rest of the dependencies:

        WixTools.SignTool = @".\signtool.exe";
        WixTools.MakeSfxCA = @".\WixToolset.Dtf.MakeSfxCA.exe";
        WixTools.Heat = @".\heat.exe";
        WixTools.DtfWindowsInstaller = @".\WixToolset.Dtf.WindowsInstaller.dll";
        WixTools.WixToolsetMbaCore = @".\WixToolset.Mba.Core.dll";
        WixTools.SfxCAx64 = @".\x64\SfxCA.dll";
        WixTools.SfxCAx86 = @".\x86\SfxCA.dll";

[smaudet]

Does it mean that you are compiling against the .NET Framework? The only SDK that does not have dotnet.exe included.

Yes indeed it does. Wix4 still supports .net framework, as does Microsoft: https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework, and likely this will continue to be used even when the official lifecycle has ended :)

But I just have changed the implementation and in the next release this approach will be extended to the rest of the dependencies

I think this approach is better. I am not using any of those tools currently - but why not make it such that all tools are attempted to be found and then if not, prompted? As I said, maybe if I have some time I will work on this.

I thought I could rely on the presence of dotnet.exe :)

With builds I do not think it is ever good to rely on anything - you are building, not executing programs within frameworks. Every thing you rely on is something you can't control that will break at some point. Only the things you can control you can fix, which for building is very important. :)

[oleg-shilo]

I think there is something lost in our communication.

All the frameworks you named (WixSharp, MS, and WiX4) can indeed build artifacts targeting the .NET Framework. However, WiX4 needs the .NET SDK(core family, not a framework) to be present on the build system (e.g. CI). The WiX team has decided to distribute their tools via the .NET Tools package manager, which is not available in the .NET Framework SDK but only .NET SDK.

This means that because you do not have .NET SDK installed, your environment is not compatible with the WiX4+ toolset.
Yes you can trick the system by manually bringing wix tools and WixSharp from the next release will be able to help you with that. Good. But there should be no confusion. WiX3 works with .NET Framework SDK and WiX4 with .NET SDK.

With builds I do not think it is ever good to rely on anything - you are building, not executing programs within frameworks.

Not sure I align with that.
This thread started with describing the problem on the environment with .NET SDK. You stated that you have a similar problem. This made me think that you also have .NET SDK installed so assuming the presence of dotnet.exe is justified as it is a vital part of .NET build toolchain.

It just happens that you have non-standard environment and you need to use non-standard approaches to make it work. So your problem is not that similar after all :)

Anyway, with the next release you will be able to manually configure the location of all WiX tools from the WixSharp project. The feature is implemented and only waiting for the release.

[smaudet]

This made me think that you also have .NET SDK installed so assuming the presence of dotnet.exe is justified as it is a vital part of .NET build toolchain.

This is not actually true, though, at least not on the CI (I have many toolchains installed locally). I can confirm that dotnet is not present on those machines.

However, WiX4 needs the .NET SDK(core family, not a framework) to be present on the build system

This is not true either. Yes, the publicly available distribution is via dotnet tools, however nothing about their toolset is actually reliant on net sdk.

so assuming the presence of dotnet.exe is justified as it is a vital part of .NET build toolchain.

Maybe this should be in a "discussion" not a "bug" but, I strongly disagree. What Microsoft considers to be "vital" changes from day to day with release to release. I think it is a very poor design decision to depend on a particular executable at a particular location. I think it is better, rather, to only explicitly depend on what you actually must use, not some "assumed" part of a system that may or many not look the same in future, or (in my case) in the past.

[oleg-shilo]

This is not actually true, though, at least not on the CI

Are you saying that you have install .NET 8 SDK and you do not have dotnet.exe available?

If this is the case, then you should report it as a .NET SDK bug as the very first thing that the documentation says: "create a new project by executing dotnet" (https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-new). So MS explicitly expects dotnet.exe to be present. MSBuild.exe also calls it under the hood.

---

This is not true either. (about WiX4)

It is in fact true. This is the evidence (WiX documentation): https://wixtoolset.org/docs/intro/
So they expect you to install .NET SDK if you want to use WiX compiler.

---

I think it is a very poor design decision to depend on a particular executable at a particular location.

Not at all. This is a dependency on the compiler that is the heart of the SDK. And not "at a particular location". It is executed without path so the shell always finds based on PATH updated during the SDK installation.

The important point is that we are not discussing some sort of a second-class citizen utility but the very essence of SDK - the compiler.

It's like to say that after installing Python, you should not assume the presence of a Python compiler. After installing Node you should not expect node.exe, Java, Ruby, VSCode .....

---

Anyway, I think this discussion is not going anywhere. I found it non-productive, neither in essence nor in style.

[smaudet]

Are you saying that you have install .NET 8 SDK and you do not have dotnet.exe available?

No. I have not installed .net 8 sdk. In fact I haven't installed any net sdk, I think our ops installed .net framework. I could get you a specific version number but I don't think it relevant or that we really care...and this is a working framework, been producing builds for 4+ years. I assure you we have .net without any "net sdk".

It is in fact true. This is the evidence (WiX documentation)

Nah, false. The documentation shows the public installation of wix. You can still obtain a bundle for usage, i.e. via an offline build. Don't assume the documentation is always 100% correct :)

The important point is that we are not discussing some sort of a second-class citizen utility but the very essence of SDK - the compiler.

I think maybe you should go work for Microsoft and champion that they never change their tooling again! Maybe you just aren't familiar with .net history or software dev history or something, there are multiple changes over 5, 10, 20 years to components, names, functioning, etc. I wouldn't presume "dotnet" remains the way to build .net executables.

It's like to say that after installing Python

Actually, again you maybe betray a lack of familiarity with the tools, etc. E.g. now there is a "py" executable, and "python" actually is not really "python" on some platforms (e.g. Apple, maybe windows too now?). This is a very common thing,...

Anyway, I think this discussion is not going anywhere. I found it non-productive, neither in essence nor in style.

I think you are perhaps just unwilling to accept that you might not be correct...

[oleg-shilo]

Mate, I'm not interested in continuing this conversation. You are not really reading my responses.
This is despite my efforts to stay calm in my responses and have a graceful disagreement.

Your enthusiasm in defending your misinterpretations deserves a better use.

I have a few recommendations for you without trying to offend you. I am only giving you an alternative perspective on how your conversation style may appear to others.

During a debate, try to learn to stay focused on the matter and stick to the facts, never make personal comments (re-read your post; you will see them), don't let emotions guide you, and show respect to your audience.

Anyway, I am removing myself from this conversation. Other users also need my attention.

The next release will have the functionality that you need.

[oleg-shilo]

I am locking this conversation as "too heated", with the trajectory of becoming even more heated.

It is the first time I am locking any GitHub conversation. I wondered if I should do this, but a very quick check with ChatGPT confirmed the rightfulness of my decision. This is how ChatGPT qualified the tone of the comments that I consider inappropriate:

1. "I think maybe you should go work for Microsoft and champion that they never change their tooling again!"

   • Unfriendly: This statement comes off as sarcastic and dismissive. It suggests that the other person's opinions are not valuable and mocks their perspective.

2. "Maybe you just aren't familiar with .net history or software dev history or something, there are multiple changes over 5, 10, 20 years to components, names, functioning, etc."

   • Unfriendly: This can be seen as condescending. It implies that the other person is ignorant or lacks knowledge about the subject.

3. "I wouldn't presume 'dotnet' remains the way to build .net executables."

   • Unfriendly: The tone here is dismissive and could be interpreted as belittling the other person's knowledge or assumptions.

4. "Actually, again you maybe betray a lack of familiarity with the tools, etc."

   • Unfriendly: This is another condescending remark that suggests the other person is not knowledgeable or experienced.

5. "E.g. now there is a 'py' executable, and 'python' actually is not really 'python' on some platforms (e.g. Apple, maybe windows too now?). This is a very common thing,..."

   • Neutral to Slightly Unfriendly: While this part is more factual and informative, the preceding comments set a tone that makes this also come across as patronizing.

The overall tone of the fragments is condescending and dismissive, which makes them unfriendly.