Assets not found when running bundled application

[SpikeHD]

Problem

When running my app with dx serve, or the binary from dx build, the application works just fine, however, when I bundle the application and run it, the GUI is unstyled and the images are missing.

While my app requires sudo, I have tested with and without (the second screenshot is run without sudo), so it shouldn't be a sudo problem. My application also belongs in a Cargo workspace, but bundling via cd gui && dx bundle and dx bundle --package gui both output the same result.

Project source in case configuration, etc. is of any interest: https://github.com/SpikeHD/GlacierDiskInfo

Steps To Reproduce

Steps to reproduce the behavior:

• Write app to include CSS like the following:

const MAIN_CSS: Asset = asset!("/assets/main.css");
fn App() {

  rsx! {
      document::Link { rel: "stylesheet", href: MAIN_CSS }

      // ...
  }
}

• Bundle app (.deb in my case) withdx bundle
• Install bundle
• Run it and see the unstyled application

Expected behavior

Assets load properly

Screenshots

dx serve:

Bundled app:

Environment:

• Dioxus version: 0.6.3
• Rust version: 1.84.0
• OS info: PopOS 22.04
• App platform: Desktop

[purplesyringa]

It looks to me like tauri-bundler puts the executable into /usr/bin/<binname> and the assets into /usr/lib/<packagename>/assets, while Dioxus assumes that the binary and the assets directory are siblings. Presumably the right fix is to use resource_dir from tauri-utils, but I don't know if that's correct because I have no idea why the current approach has ever worked.

[Kbz-8]

did you find any solution ?

[purplesyringa]

You should be able to set the correct resource directory by hand with Config::with_resource_directory.

[Kbz-8]

You should be able to set the correct resource directory by hand with Config::with_resource_directory.

but how can I manage to set it to the good directory whether I serve or bundle to an Appimage, raw executable or .deb ?

[Kbz-8]

You should be able to set the correct resource directory by hand with Config::with_resource_directory.

I've tried it and it simply does not work. There is absolutely no change with it or without :/

[NiceneNerd]

I have precisely the same issue. Any leads here?

[Kbz-8]

I have precisely the same issue. Any leads here?

I've made an asset loader just for desktop

pub fn setup_assets_loader() {
    pub use dioxus::desktop::wry::http::Response;
    dioxus::desktop::use_asset_handler("assets", |request, response| {
        response.respond(match request.uri().path() {
            asset if asset.contains("tailwind") => {
                Response::new(include_bytes!("../../assets/tailwind.css").to_vec())
            }
            asset if asset.contains("background-light") => {
                Response::new(include_bytes!("../../assets/background-light.svg").to_vec())
            }
            asset if asset.contains("background-dark") => {
                Response::new(include_bytes!("../../assets/background-dark.svg").to_vec())
            }

            ...

            _ => return,
        });
    });
}

[keiko37]

Also have this problem with AppImage bundle. I'm on Arch and found the problem in resolving file path in bundle(path are different in dev and bundled app). Here is my wrapper:

#[macro_export]
macro_rules! get_asset {
    ($x:expr) => {
        {
        let prefix = if cfg!(not(debug_assertions)) {
            let current_dir_buffer = std::env::current_dir().unwrap();
            let current_dir = current_dir_buffer.to_str().expect("Can't take a current path.");
            &format!("{}/lib/<YourAppName>", current_dir)
        } else {
            ""
        };

        let asset = dioxus::prelude::asset!($x);
        format!("{}{}", prefix, asset)
        }
    };
}

[DougAnderson444]

This worked for me:

dx bundle --features desktop --platform desktop --release --package-types "deb" --package-types "appimage"

target/dx/desktop/release/linux/app/desktop
# assets are in
# target/dx/desktop/release/linux/app/desktop/assets

[Distortedlogic]

idk if this is the thing but u are using const instead of static .. if u are on the 0.7.0-alpha.1 I ran into the compiler optimizing out the the asset when bundling .. my understanding wrestling with this is that dioxus patches the binary from rustc and a release bundle will optimize out unused code .. so the assets are not available in the rustc binary during patching for dx to act as a linker for the asset

[ronnybremer]

There is an older issue which highlights exactly this problem: https://github.com/DioxusLabs/dioxus/issues/3075

When opening the console of the bundled app, the assets are requested via dioxus:///assets/xxx.css. I don't know where this resolves to at the end, but on Debian (deb package) the assets are indeed installed in /usr/lib/appname/assets and have a hashed name. The app itself is installed in /usr/bin/appname and this code ties all this together: https://github.com/DioxusLabs/dioxus/blob/6919f72abc0fac2c69f0e16d9edeaf0cd293e88f/packages/asset-resolver/src/lib.rs#L86-L116

When running a strace the actual path requested for an asset file is /usr/bin/assets/xxx.css, so I assume the above code path is never executed and uses the default asset path, which expects it right next to the app's location.

[ronnybremer]

Should have added some more info. Distribution is Debian Bookworm, building as a desktop release deb package. Installing the package on a test machine.

To confirm my suspicions, I created a symbolic link ln -s /usr/lib/appname/assets/ /usr/bin/ and the assets are now found.

[ealmloff]

That sounds similar to the issue that was fixed by https://github.com/DioxusLabs/dioxus/pull/4460. Can you try with the git version of dioxus?

[ronnybremer]

I did, running on 0.7.0-alpha.3. Unless those changes have been merged after.

[ronnybremer]

LOL. of course they were ... I will switch to the main path and try with that. Thanks @ealmloff!