[v2] Why Doesn't tauri build Output a Dynamic Library? How to Configure It?

[zhironghsu]

Background

I'm working on a Tauri v2 project where I need to create a dynamic library (DLL) with an additional C API that invokes run(). My goal is to allow external applications to call this DLL and initialize the Tauri app from within the library.

Problem

When I use tauri build, the build process doesn’t produce a .dll file, only an .exe. However, if I use cargo build --release, it does generate the .dll as expected. The issue is that when I run the .exe generated from this build, I encounter an ERR_CONNECTION_REFUSED error.

Example Setup

Here’s a simplified version of my project structure and code:

# src-tauri/Cargo.toml
[lib]
name = "my_app_lib"
crate-type = ["lib", "cdylib", "staticlib"]

// src-tauri/src/lib.rs
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! You've been greeted from Rust!", name)
}

#[no_mangle]
pub extern "C" fn initialize() {
    run();
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_shell::init())
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

[FabianLars]

Try cargo build --release --features tauri/custom-protocol - this will be equivalent to tauri build == using the distDir/frontendDist instead of devPath/devUrl which i assume was what caused ERR_CONNECTION_REFUSED

[zhironghsu]

Thank you for the suggestion! Running cargo build --release --features tauri/custom-protocol does indeed solve the (localhost refused to connect.) ERR_CONNECTION_REFUSED.

However, this approach does not address the separate issue of needing to embed a manifest specifically in the cdylib to enable certain Windows API features (like TaskDialogIndirect) by loading the correct version of Comctl32.dll.

When I build with cargo build --release --features tauri/custom-protocol, the manifest doesn’t get embedded in the cdylib, which causes the DLL to fail when certain functions require the embedded manifest.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        processorArchitecture="*"
        publicKeyToken="6595b64144ccf1df"
        language="*"
      />
    </dependentAssembly>
  </dependency>
</assembly>

[FabianLars]

are you still building an exe at the same time? iirc the winres crate can't handle multiple targets at once, so maybe try the --lib flag or temporarily remove the main.rs file.

[zhironghsu]

Thank you for your suggestion and explanation. Yes, in my case, I am building both an exe and a dll simultaneously, which seems to be causing the issue with the manifest not being embedded correctly in the DLL.

Based on your advice, I will modify my build process to build the .dll separately using the --lib flag.

[zhironghsu]

I found that the embedded manifest was still not automatically included. To resolve this, I added specific linker arguments in build.rs to ensure the manifest is embedded when building the cdylib. Here's the approach I used:

// build.rs
use std::{env, path::Path};

fn main() {
    tauri_build::build();

    if env::var("TARGET")
        .expect("target")
        .ends_with("windows-msvc")
    {
        // Path to the manifest file
        let manifest = Path::new("dll_manifest.xml").canonicalize().unwrap();

        // Pass linker arguments specifically for embedding the manifest in the `cdylib`
        println!("cargo:rustc-cdylib-link-arg=/MANIFEST:EMBED");
        println!(
            "cargo:rustc-cdylib-link-arg=/MANIFESTINPUT:{}",
            manifest.display()
        );

        // Ensure the manifest file change triggers a rebuild
        println!("cargo:rerun-if-changed=dll_manifest.xml");
    }

    // Ensure that the build script re-runs if `build.rs` changes
    println!("cargo:rerun-if-changed=build.rs");
}