Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run tauri project as a windows service #11520

Open
davidklein147 opened this issue Oct 28, 2024 · 10 comments · May be fixed by #11521
Open

Run tauri project as a windows service #11520

davidklein147 opened this issue Oct 28, 2024 · 10 comments · May be fixed by #11521

Comments

@davidklein147
Copy link

Describe the problem

I aim to run my Tauri project as a Windows service. To achieve this, I need to use the WiX Util extension, which includes the ServiceInstall element necessary for setting up Windows services.

Here’s the code I am trying to use:

<DirectoryRef Id="INSTALLDIR">
...
 <Component Id="Path" Guid="{{path_component_guid}}" Win64="$(var.Win64)">
                <File Id="Path" Source="{{app_exe_source}}" KeyPath="yes" Checksum="yes"/>
                 <ServiceInstall Id="AgentUiServiceInstaller" Type="ownProcess" Vital="yes" Name="GetAppAgentUIService" DisplayName="GetAppAgentUIService" Description="GetApp's Agent UI is running here" Start="demand" Account="LocalSystem" ErrorControl="ignore" Interactive="no">
                    <util:ServiceConfig FirstFailureActionType='restart' SecondFailureActionType='restart' ThirdFailureActionType='restart' RestartServiceDelayInSeconds='60' ResetPeriodInDays='1'/>
                </ServiceInstall>

                <ServiceControl Id="AgentUiServiceControl" Name="GetAppAgentUIService" Stop="both" Remove="uninstall" Start="install" Wait="yes" />
            </Component>
...
</DirectoryRef>

The problem

The current Tauri template does not support adding the WiX Util extension in the main template, so I am attempting to use a custom fragment to include it. However, this workaround has significant limitations:

1. Installing the Full Component via Custom Fragment:

The .exe file cannot be installed directly through the custom fragment because there is no way to reference the app_exe_source variable within the fragment. The custom fragment does not support accessing bundler variables like {{app_exe_source}}, which limits its usability.

2. Installing the Service Without the File Element:

If I attempt to install the service without specifying the file element, there is no way to link the service to the executable file. As a result, the service configuration cannot specify which file to execute when starting the service.

Describe the solution you'd like

Ideally, there would be two potential solutions, both of which seem to be quite simple to implement::

  1. Enable support for the WiX Util extension directly in the main Tauri template, like you doing with the custom fragment.
  2. Allow custom fragments to access bundler variables like {{app_exe_source}}, enabling the fragment to correctly reference the .exe file and establish a link between the service and the executable.

Alternatives considered

No response

Additional context

No response

@amrbashir
Copy link
Member

I believe you can just use a custom template which would solve your problem.

  • Enable support for the WiX Util extension directly in the main Tauri template, like you doing with the custom fragment.

WixUIExtension.dll and WixUtilExtension.dll are loaded by default, and any extension specified in a fragment will be automatically discovered using this regex "http://schemas.microsoft.com/wix/(\\w+)"

  • Allow custom fragments to access bundler variables like {{app_exe_source}}, enabling the fragment to correctly reference the .exe file and establish a link between the service and the executable.

This we can do

@davidklein147
Copy link
Author

Hi!
First, thanks for your quick response.

I’m currently using a custom template, and the xmlns:util="http://schemas.microsoft.com/wix/WixUtilExtension" has been added to the head of the xml, However, I’m encountering the following error:

main.wxs
C:\Users\admin1\Desktop\workProjects\getApp\agant_zone\agent-ui-github\src-tauri\target\release\wix\x64\main.wxs(88) : error CNDL0200 : The ServiceInstall element contains an unhandled extension element 'util:ServiceConfig'.  Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/WixUtilExtension' namespace has been provided.
    Error [tauri_cli_node] failed to bundle project: error running candle.exe: `failed to run C:\Users\admin1\AppData\Local\tauri/WixTools\candle.exe`

It seems that the WixUtilExtension might not be included in the compilation process, even though the namespace is referenced. Any guidance on ensuring that WixUtilExtension is fully recognized and compiled with the project would be greatly appreciated!

@amrbashir
Copy link
Member

so apparently I was wrong, WixUtilExtension.dll is only included by default when running light.exe, the candle.exe part however tries to detect extensions from your fragments.

In your case, the url is wrong, it should be xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"

@davidklein147
Copy link
Author

Do you have any ideas for a workaround to ensure that WixUtilExtension.dll is linked during the candle.exe compilation? Alternatively, is there another approach you’d recommend for running the Tauri project as a Windows service?

If no workaround is available, are there plans to support one of the features mentioned above in the near future?

Any guidance or recommendations would be greatly appreciated!

@amrbashir
Copy link
Member

Do you have any ideas for a workaround to ensure that WixUtilExtension.dll is linked during the candle.exe compilation?

yes, just include xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" in your fragment, notice that it is different than the url your posted which ended in WixUtilExtension instead of just UtilExtension.

Alternatively, is there another approach you’d recommend for running the Tauri project as a Windows service?

I haven't implemented such a use-case with tauri unfortunately so I don't have any recommendation or articles to link to unfortunately.

If no workaround is available, are there plans to support one of the features mentioned above in the near future?

I already opened a PR to run the fragments through Handlebars in #11521 which will make {{ main_binary_path }} available to be used.

The other request is covered by the automatic detection of extension we already have, you just need to correctly specify the url as I explained earlier.

@davidklein147
Copy link
Author

yes, just include xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" in your fragment, notice that it is different than the url your posted which ended in WixUtilExtension instead of just UtilExtension.

As mentioned in my initial problem description, I did try adding xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" in the fragment. However, this approach introduces limitations:

  1. It either prevents the .exe file from being installed correctly.
  2. Or it results in no link between the .exe file and the service.

I already opened a PR to run the fragments through Handlebars in #11521 which will make {{ main_binary_path }} available to be used.

Thank you so much for your quick response and for implementing the feature that can help solve my problem!

Do you anticipate this PR being merged in the near future?

@amrbashir
Copy link
Member

As mentioned in my initial problem description, I did try adding xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" in the fragment. However, this approach introduces limitations:

  1. It either prevents the .exe file from being installed correctly.
  2. Or it results in no link between the .exe file and the service.

This is was not your question though, you asked Do you have any ideas for a workaround to ensure that WixUtilExtension.dll is linked during the candle.exe compilation? to which I responded, the limitations you mention doesn't seem related to whether WixUtilExtension.dll is loaded or not.

Do you anticipate this PR being merged in the near future?

should be included in the next release, but I have not ETA atm.

@davidklein147
Copy link
Author

Is there a way to use the changes before they’re merged and released?

I tried specifying the commit hash directly in my Cargo.toml like this:

[dependencies]
# tauri = { version = "2.0.6", features = [ "devtools", "tray-icon", "image-png"] }
tauri = { git = "https://github.com/tauri-apps/tauri", rev = "ae024b829972609ac565e54bf4b03d4e4b5e2524", features = [
  "devtools",
  "tray-icon",
  "image-png",
] }

But I still encounter the following error:

C:\Users\admin1\Desktop\workProjects\getApp\agant_zone\agent-ui-github\src-tauri\service-fragment.wxs(20) : error LGHT0103 : The system cannot find the file '{{app_exe_source}}'.
    Error [tauri_cli_node] failed to bundle project: error running light.exe: `failed to run C:\Users\admin1\AppData\Local\tauri/WixTools\light.exe`

@amrbashir
Copy link
Member

amrbashir commented Oct 29, 2024

the relevant changes is actually in the CLI, so you need to install the CLI using

cargo install tauri-cli --git https://github.com/tauri-apps/tauri --rev ae024b829972609ac565e54bf4b03d4e4b5e2524 

@davidklein147
Copy link
Author

I tried installing as you suggested,
…but I’m still encountering the same error

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants