File Browser - Native file browser

Asset validation failed
Invalid Code Signature Identifier. The identifier "com.crosstales.procstart" in your code signature for "ProcessStart" must match its Bundle Identifier "com.crosstales.procstart.20230807121606" (ID: 143ef7be-9990-4fc3-9ddb-cbf0d3538087)

I'm having this same problem.
When I upload to the store and do a test flight, the file browser stops working.
Have you resolved this?

 

Hi

You either have to disable "Modify Bundle" in the configuration of the asset or sign the application as described in Chapter 8.2 of the documentation: https://www.crosstales.com/media/data/assets/FileBrowser/FileBrowser-doc.pdf


Cheers
Stefan

 

Within xcode you can just add --deep to the signing process for above, ideally such options are set from Unity one-time but not sure we got there yet...

 

Thanks for the answer.
But I have already done this work, I turned off [Modify Bindle ] in MacOS.
The "com.crosstales.procstart" problem is now resolved, but when I run a test flight, the file browser is not working.
codesign --deep --force --verify --verbose --timestamp --sign "3rd Party Mac Developer Application: XXX(XXXX)" "XXXXXXX/PlugIns/FileBrowser. bundle"
I also signed the file with
in the entertainment file.
<key>com.apple.security.cs.disable-library-validation</key><true/>
<key>com.apple.security.files.user-selected.read-write</key
<true/>
also adds

But it doesn't work on test flight.
I have exported the xcode project and uploaded it from xcode.
Should I not do so?

 

Hello again

I would not recommend doing all steps together.

Please start with building with "Modify Bundle" set to disabled - no code signing and additional keys etc.
If that fails, enable "Modify Bundle" and do a build with signing (I recommend --deep from @andyz post above).

I hope this helps you further.


Cheers
Stefan

 

Thanks again for your kind response.

Resolved!
I have a report.

I tried everything, but it didn't work, and I thought maybe it didn't work well locally either.
So I exported it to an xcode project, built it and tested it, and it did not work!
Furthermore, when I built the app directly in UNITY, it did not work.
It was working before, but now it was not working.
I tried everything, including deleting and reinserting File Browser Pro, but it didn't work.
Then, I tried to install the old File Browser Pro from a backup, and it worked fine.

The work I did this time is as follows. 1.

1. exported the xcode project to the Mac App Store, modified the signature and entertainment, and uploaded it. 2.

2. The upload failed with an error, so I unchecked Modify Bundle, rebuilt and uploaded.
It succeeded, but the file browser does not work.

3. Thought it was a bug, so updated File Browser Pro to the latest 2023.2.3.
(The actual cause was a misconfiguration in Entertainment.) 4.

4. After that, no matter how many times I exported the file, the upload succeeded but the file browser did not work.

5. So I asked a question on this forum.

6. Based on your answers, I tested locally again, and the problem was solved by making the version older.

7. I tried uploading to the latest 2023.2.3 again and it did not work.



I will use "2023.2.0" for the time being, so no problem, but I would appreciate it if you could check the latest version "2023.2.3" just in case there are any bugs.
My environment is as follows

MacBook Pro 13-inch, M1, 2020
Mac OS 13.1 (22C65)
UNITY 2020.3.17f1

 

Thank you very much for your great report!

Just a question: are you using the synchronous or asynchronus methods of FB?

Edit:
I assume you are using the synchronous calls, like "OpenFiles", which were disabled for macOS in FB 2022.2.1. But you can change the variable "MAC_SYNC_CALLS_DISABLED" in Constants.cs to false. The upcoming version has a nice flag for that in the FileBrowser-gameobject

 

Code (CSharp):

1.       string  title = "Opne Sound File";
2. string[] extensions = { "mp3", "wav" };
3.      string path = Crosstales.FB.FileBrowser.Instance.OpenSingleFile(  title , "", "", extensions);
4.             if (path != "")
5.             {
6.                 wavURL = path;
7.             }
8.             else
9.             {
10.  
11.             }

The program is roughly like this.
I'm doing it synchronously.

 

You're using synchronous methods, please see my "Edit" above
We recommend switching to the async versions, since we had some weird UI issues.

 

Thank you very much.
I changed to ASync type and it works on 2023.2.3!

 

Hi, I have a problem like this;
I'm working on a project in which I need to export Android and UWP both
it's working fine with Android but for UWP even though I can see the file browser I can't allow the user to browse all files on device; if I remove 'broadFileSystemAccess' it's building but not letting the user browse for files. Here you can see the error ca nyou help

 

Hi! I've gotten some reports of crashing on Linux (Ubuntu) builds, when attempting to open file browser in my app. I'm using FileBrowser PRO 2023.2.0, all async calls. I was able to reproduce on one Linux (Ubuntu 22.04.2 LTS) machine. My app is normally mono, and the player crash log gives me this error:

Caught fatal signal - signo:11 code:1 errno:0 addr:0x6ed6f3a80

I Switched to IL2CPP to see if it could could help give more data. I still get an error in IL2CPP on Linux (Runtime error, not a player crash in this case):

Open file dialog threw an error: System.NotSupportedException: IL2CPP does not support marshaling delegates that point to instance methods to native code. The method we're attempting to marshal is: Crosstales.FB.Wrapper.FileBrowserLinux+<>c::<openFiles>b__19_0



  at Crosstales.FB.Wrapper.Linux.NativeMethods.DialogOpenFilePanelAsync (System.String title, System.String directory, System.String extension, System.Boolean multiselect, Crosstales.FB.Wrapper.Linux.NativeMethods+AsyncCallback callback) [0x00000] in <00000000000000000000000000000000>:0 



  at Crosstales.FB.Wrapper.FileBrowserLinux.openFiles (System.String title, System.String directory, System.String defaultName, System.Boolean multiselect, System.Boolean isAsync, Crosstales.FB.ExtensionFilter[] extensions) [0x00000] in <00000000000000000000000000000000>:0 



  at Crosstales.FB.Wrapper.FileBrowserLinux.OpenFilesAsync (System.String title, System.String directory, System.String defaultName, System.Boolean multiselect, Crosstales.FB.ExtensionFilter[] extensions, System.Action`1[T] cb) [0x00000] in <00000000000000000000000000000000>:0 



  at Crosstales.FB.FileBrowser.OpenSingleFileAsync (System.String title, System.String directory, System.String defaultName, Crosstales.FB.ExtensionFilter[] extensions) [0x00000] in <00000000000000000000000000000000>:0 

My next step was to attempt to recompile the .so file as recommended in the source on the crashing machine. I was able to build the library fine. However, running the example generated EXE file that I assume uses the .so library still returns a segmentation fault in the terminal. (Segmentation fault (core dumped))

Since I'm getting a segmentation fault on the rebuilt library, Unity removed entirely, on Ubuntu... this is where my ability to troubleshoot so far has reached an end. Any advice?

(And an additional follow up question, if I'm able to resolve this issue, and it involves recompiling the Linux sources to create distro specific .so files, do I have the license to distribute the Linux C source to my users for them to recompile and create a working .so file on their machine and swap out in their Unity build? Or do I need to have access to a matching machine/distro myself to make the .so file for them?)

 

I had the this same error. Here is how I fixed this:

In the file FileBrowserLinux.cs at line 142:

Code (CSharp):

1.  Linux.NativeMethods.DialogOpenFilePanelAsync(title, directory, getFilterFromFileExtensionList(extensions), multiselect, paths =>

Replace the "paths" lambda with a method reference like this:

Code (CSharp):

1. Linux.NativeMethods.DialogOpenFilePanelAsync(title, directory, getFilterFromFileExtensionList(extensions), multiselect, Callback);

And put the lambda contents in a method decorated like this:

Code (CSharp):

1. [MonoPInvokeCallback(typeof(Action))]
2. private static void Callback(string paths)
3. {
4.    ...
5. }

 

Thank you for that suggestion. Unfortunately, making that change doesn't resolve my issue or prevent the crash / seg fault.

However, I have a hint! One of my users discovered a workaround, which is to change the display server from Wayland to Xorg. My application will crash when invoking File Browser methods on Linux when using Wayland Display Server, but not Xorg. I have confirmed this to be the case myself as well. As a heads up Wayland is the default display server on Ubuntu currently.

 

Ah, I only tested it under KDE. It's good to know that the fix might not work under different display engines though.

 

Thank you very much for your heads-up, we wanted to do that for quite some time...
It's now fixed in the upcoming release 2023.2.4 of BWF.

 

Hi

Please see chapter 8.3 of the documentation.
As an alternative, use the directly supported and free Runtime File Browser under Linux.

Cheers
Stefan

 

Hi Stefan, I also had issues with macOS and changing the MAC_SYNC_CALLS_DISABLED also worked for me. You talk about switching to async versions, but I don't understand what you mean exactly. The methods described in the doc are all synchronous right? Those are the once I use in both Windows and macOS and they worked so far (with the edit above).

Regards Thomas

 

Hi Thomas

There are async-methods, they end with "Async", like "OpenFilesAsync". You could take a look at "Examples.cs" in the "Demos"-package.

I hope this helps you further.


Cheers
Stefan

 

Hi Stefan, recieving error when trying to build for Mac. Does this have to do with the entitlements issue noted in the documentation? Any help would be appreciated.

Building MacBuild.app\Contents\PlugIns\FileBrowser.bundle\Contents\Info.plist failed with output:
System.Exception: Could not find executable at 'C:\Users\MT-User\Documents\cs293-IAIA-Museum-Studies-Templates\IAIA_Museum_Studies_Templates\MacBuild.app\Contents\PlugIns\FileBrowser.bundle\Contents\MacOS\FileBrowser' inside a bundle.
at MacOSCodeSignBundleCopy.Run(CSharpActionContext ctx, Data data)

 

I've sent you an email.

 

Thank you Stefan, I will go through it and implement it across.

 

That's not in the docs (current version just purchased and installed). There's nothing at all in there about 'async', and the section on Mac doesn't mention this new requirement. The only time the text appears in the docs is inside the section on WSA-specific builds, without any explanation (not surprising, WSA is pretty niche as a target - but also: I doubt many people will ever read that section, let alone try to reverse-engineer the missing explanation of async usage).

 

Hi

Thank you for your input!
We will update the documentation to make it more clear for our users.
Maybe we will even deprecated the sync-calls entirely since it's recommended to use the async-solution.


Cheers
Stefan

 

I'm giving up on this asset. My experience:

1. Out of the box it's broken on OSX, this is 'known' but apparently not important enough to document, let alone fix.
2. The docs for OSX are also known to be broken, cannot possibly work (they require the undocumented async calls)
3. The scant docs for OSX say "you may have to do one of the following" -- having looked at the Apple docs that's a direct lie: there's no way this could ever build on Apple platforms without setting the required entitlements
4. Without setting the entitlements, this will always be unable to build on Mac. This is something the plugin should be doing itself - not relying on users to go and manually fix-up their xcode projects to make up for the untested, unworking, features.
5. Trying to debug the entitlements problems is taking almost as long as if I'd just gone and written something myself.

In a $10 asset - fine. But in a $50 asset - whose CORE PURPOSE as stated on the store - "native file browser for standalone" - this isn't acceptable: it literally is misconfigured for the one thing it's supposed to do.

The only thing it has done correctly - native file browsing on Windows - is available from free assets already (and it looks like this is in fact using one of the free assets to provide that feature). Huge disappointment.

 

Hello again

I apologize that our asset wasn't working for you!
Unfortunately, you never contacted us - we may could have helped.
You could e.g. have tried a build with the "Modify bundle"-option in configuration settings.

However, as already said in my last answer, we agree with you that the documentation should be clearer and we will fix that.
I disagree with your assessment under macOS - it's absolutely possible to get it working and it's not "broken". Our demo proves it and also the many happy customers that use our asset in actual applications.

We don't like any misinformation and want to clarify your statement about "Windows": the Windows implementation is 100% our work, and writing a working solution on your own is worth more than $50 if you value your time.

Please feel free to request a refund.


Regards,
Stefan