How to support the "Open With" option on Windows for file types that don't specified in file associations?

[niusia-ua]

How can I allow users to open files with my app via "Open With" on Windows?

I have configured a single file association, and it works well. I can open the file with both a double click and the "Open With" menu.
However, it doesn't work with other file extensions that I actually support. The application doesn't start. I only see a console window for a moment, but it closes very quickly.
I don't include them in my file associations because I don't want to overwrite user-specific file associations (e.g. from another application).

[CaseSens]

I'm not sure I understand your question exactly, so I can propose 2 things.

• If you just want to give the option to the user to open something with a desired application, why not just use Tauri's "Open" dialog plugin? That will open the default Windows explorer window at the location you want and let the user make the choice.

• If your goal is to open unspecified file associations with some application, you can maybe have a default fallback that will check the file's MIME type and launch some default application to view it. For this you could look into the std::process::Command("cmd /c '<application> <path\to\file>'") although this is a hacky workaround.

With more context, it may be easier to answer.

[niusia-ua]

Thank you for your reply!

I already use the dialog plugin to open files from my app. What I was talking about is the ability to handle other file associations that are not actually specified in my tauri.conf.json.

For example, consider the following files: .embproj, .xsd, .oxs. I have a file association for only .embproj files. And this file association works fine. I also can process .xsd and .oxs files. However, they are "owned" by other applications. So I want to be able to process these files with the same approach as the file associations do but without file associations, because it will overwrite existing file association of those apps.

Now, if I try to open them via RMB -> Open With -> My App, I can't do that due to a strange issue. I don't know why it doesn't work. I expect that it will work in any case because it is just a file path. To handle it or not I decide in my application.

[CaseSens]

So if I understood correctly, you want it so that, for example, if you have test.xsd in your file explorer, you can right click that and Open With your own Tauri app?

The reason why your app "Starts" and then closes suddenly is because it doesn't know how to handle the arguments passed to it from using "Open With".

When using "Open With", Windows passes the opened file as a command-line argument to your app. Even if .xsd or .oxs isn’t associated with your app, you should still be able to process it using std::env::args(). Without seeing your codebase, it's hard to know exactly what could be causing the error, so here's an extremely simple example you can use to figure out why your app crashes on startup:

fn main() {
    let args: Vec<String> = std::env::args().collect();
    // Print them so you can see exactly what is being passed, and how to process them.
    // I would strongly suggest logging this to some text file as well
    println!("Args: {:?}", args);
    // This may print something like: "["C:\\Path\\To\\Your\\App.exe", "C:\\Users\\You\\test.xsd"]"

    if let Err(e) = tauri::Builder::default().run(tauri::generate_context!()) {
        // Write the error to a file
        if let Ok(mut file) = File::create("error_log.txt") {
            let _ = writeln!(file, "Startup Error: {}", e);
        }

        // Quit the app with an error code
        exit(1);
    }
}

I suspect your app is erroring out and instantly closing, making it impossible to read the error. This way, you'll have a text log you can use to trace the error. If you can get this to run on your own code, feel free to paste here what kind of error you're getting when trying to run your app using "Open With". It'll be easier to debug this way.

[niusia-ua]

Even if I register my logger, which also intercepts and logs panics, I don't see any logs...

  builder = builder
    .setup(|app| {
      let app_handle = app.handle();

      // Register the logger before everything else.
      // I'm sure it registers successfully, because in a normal run, there are no issues with it.
      app_handle.plugin(logger::init())?;

      #[cfg(any(target_os = "windows", target_os = "linux"))]
      {
        let files = collect_files_from_args();
        handle_file_associations(app_handle, files)?;
      }

      #[cfg(not(debug_assertions))]
      copy_sample_patterns(app_handle)?;

      run_auto_save_background_process(app_handle);

      Ok(())
    })

[CaseSens]

So at a glance, your builder code looks fine. I'm curious about the error Failed to create webview: IO Error: The system cannot find the path specified.. This indicates the error happens upon creation of the webview.

My initial thought was, maybe your frontend could be bubbling up some dramatic uncaught error causing the program to crash upon building the app or some seperate window as well. I haven't checked your frontend code, but if somewhere in your frontend it expects a .embproj and receives something unexpected, that could be it.

Another thing, I notice you have a create_webview_window() fn, where inside you do this:

    let mut webview_window_builder = tauri::WebviewWindowBuilder::new(app, "main", tauri::WebviewUrl::default())
      .title(app.package_info().name.clone())
      .min_inner_size(640.0, 480.0)
      .maximized(true)
      .decorations(false)
      .additional_browser_args("--disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection,ElasticOverscroll");

Now, I'm not too familiar with the ins-and-outs of WebviewWindowBuilder, but the source code for it specifies this, saying that WebviewWindowBuilder on Windows can deadlock the program if it's run synchronously. They provide this example as a workaround:

     std::thread::spawn(move || {
       let webview_window = tauri::WebviewWindowBuilder::new(&handle, "label", tauri::WebviewUrl::App("index.html".into()))
         .build()
        .unwrap();
     });

I also noticed they seem to use WebviewUrl::App() instead of WebviewUrl::Default(). Sincerely doubt that would cause the issue but that could be worth looking into as well.

Lastly, if above doesn't lead to anything, it could be worth looking into edge cases where maybe the file name of the .xsd or .osx you're testing with has some niche lettering that won't work (or maybe even their location on your disk is weird). I think I remember FFmpeg having an issue with that years ago on Windows systems, where things placed on the C:\ drive mixed with capital letters led to the program misbehaving because of some internationalizing of titles. I doubt it but maybe there's something there. I'd recommend naming it the exact same as your working .embproj and putting it in the same location, if not already done.

If you find more clues, or figure it out, let us know here . I'm curious :)

[niusia-ua]

I've tried every possible approach, but none work for me.
However, now I know that my app works correctly if I run it from the command line with the file path specified.

I will try to investigate the issue further.
Thank you for your assistance!

[niusia-ua]

OMG, the issue was completely unrelated to Tauri and was really dumb...
For some reason, the "Open With" menu option with my app was pointed to src-tauri/target/... and not to the C:/Users/user/.... That is why I have been getting those errors.

I cleaned up my project, reset file associations, restarted the OS, and now everything works just fine.
Sorry for the confusion.

[CaseSens]

Glad it was something benign! For context, how did you fix where the Open With pointed to? Just to make it clearer in the future for anyone who experiences this.

Happy coding :)

[niusia-ua]

I decided to track what commands Windows execute when I open my application via the "Open With" menu. I used Process Monitor from Sysinternals.
When I started watching for my application, I investigated that for some files it was pointed to the src-tauri/target for some reason. Probably, it was my mistake, I don't remember. After resetting default apps in Windows Settings, uninstalling the application, clearing project's cache and rebooting, everything worked fine.