Adding a C# solution breaks the "Embed Pck" export option.

[FlooferLand]

Godot version

v3.4.stable.mono.official [206ba70]

System information

Windows 10 Home [19043] (64-bit)

Issue description

When exporting a project with Embed Pck turned on in the export options, the exported executable of the project displays the following message when it's ran:

^ This happens on a brand new project too.

I've had some other issues regarding Godot Mono, so it could be an issue on my side. (But i can't test that since Godot running in Virtual Box turns Godot's UI upside down for some reason)

Could be related, but I'm using Visual Studio 2019 (no separate build tools, just the base install with .NET stuff enabled and the official Godot C# extension)

EDIT: I've also discovered that this issue doesn't occur when the exported executable is inside the very root of the project (res://)

Steps to reproduce

1. Making a brand new project using Godot Mono v3.4.stable.mono.official (x64)
2. Making a new scene and setting it as the main scene.
3. Making a new C# script inside the project (the script can just be empty, there just needs to be a .sln file generated) and putting the script on a node in the main scene.
4. Going to export for Windows, turning on Embed Pck, turning off exporting with debug, then exporting in any place besides the very root of the project *(exporting into something like res://builds/ or somewhere outside the project would be fine)

Minimal reproduction project

MonoExportErrorTest.zip

[raulsntos]

The Minimal Reproduction Project has a script in the Main scene that is built-in, this should not be possible since that option is disabled for C# (since it's not compatible):

I wonder how you got to create a built-in C# script because that should not be allowed and is a bug.

C# scripts must have the same name as the class so since the class is named Test it should be in a Test.cs file.

With that fixed I couldn't reproduce this issue, just in case I'll mention that the data directory (data_MonoExportErrorTest) that gets created next to the executable is important since it contains the C# DLLs so if you are moving the executable you have to move that folder with it. If you are not moving it, the folder should be generated on export right next to the executable so there should be no issue.

[Calinou]

(But i can't test that since Godot running in Virtual Box turns Godot's UI upside down for some reason)

Disable VirtualBox's 3D acceleration and install mesa-dist-win in the VM to run Godot correctly (including GLES2 and GLES3 support).

[FlooferLand]

The Minimal Reproduction Project has a script in the Main scene that is built-in, this should not be possible since that option is disabled for C# (since it's not compatible):

I wonder how you got to create a built-in C# script because that should not be allowed and is a bug.

C# scripts must have the same name as the class so since the class is named Test it should be in a Test.cs file.

With that fixed I couldn't reproduce this issue, just in case I'll mention that the data directory (data_MonoExportErrorTest) that gets created next to the executable is important since it contains the C# DLLs so if you are moving the executable you have to move that folder with it. If you are not moving it, the folder should be generated on export right next to the executable so there should be no issue.

That's something i didn't notice at all making the project, it's most probably because i tried deleting the C# file to see if the error would still occur without it there (even tho I'm pretty confident i deleted it from the Godot editor, but i don't remember)
I've updated the minimal reproduction project and made it by exactly following the "Steps to reproduce".
The data folder does get generated and i do know that i have to move my game's executable with it. In the reproduction project i have it set to build into /builds, and just running that executable without moving it anywhere is enough to show the error.

[rick551a]

Can confirm this on godot 3.4mono win10x64.

The 'embed pck' exported .exe is missing it's icon & only works residing in the "res://" folder.

Unticking 'embed pck' works fine.

[raulsntos]

PCK embedding seems to be currently broken in many cases, I don't think this issue is specific to C#.

Some of the known limitations of PCK embedding:

• Changing the game icon is not supported (Export with embedded pck is broken when changing PE metadata with rcedit #33466)
  
• Signing the exported executable is not supported (Windows exports with embedded PCK stop working after signing. #32310)
• Other issues: https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+pck+embed

It seems the feature is pending a complete rewrite, for now you can avoid embedding the PCK.

[FlooferLand]

for now you can avoid embedding the PCK

Yep, will do. My game isn't even close to being finished but i was testing out some things and that's how i found this bug.

Kinda off-topic but for the rewrite it would also be really nice if there was also an option to pack all the mono stuff directly into the executable. It's the reason i wanted to use the Embed PCK option in the first place, as having one single executable is more convenient than having several files and folders.

[raulsntos]

I believe the intention is to support single-file executables eventually (probably not until 4.1), this is described in this proposal: godotengine/godot-proposals#2333

No more data folder on desktop platforms. .NET can publish self-contained single-file executables for Linux, Windows and macOS. Native libraries are not bundled by default though, so we would have libgodot.so/dll next to the executable. This is not worse than what we have now with the data folder next to the executable. Alternatively we can publish with the property -p:IncludeNativeLibrariesForSelfExtract=true to bundle native libraries, resulting now in a true single-file executable. Keep in mind native libraries bundled in the executable are extracted to a temp folder when running the app.

[raulsntos]

@FlooferLand Can you still reproduce in 3.5 beta 5? I think this might've been fixed by #60580

[akien-mga]

@FlooferLand Can you still reproduce in 3.5 beta 5? I think this might've been fixed by #60580

3.5 beta 5 actually has broken PCK export for C# projects due to the above PR: #60753

But it's fixed by #60752, and so the combined #60580 and #60752 might have indeed solved this issue. Should be tested in the next 3.5 build (beta 6 or RC 1, not sure which name it will have yet).

[FlooferLand]

Apologies for the very late response.
I haven't been able to reproduce the issue in the official 3.5.1 release, so it seems something along the way to 3.5.1 fixed it.
I've also tried my own minimal reproduction project in 3.5.1, and it worked just fine (besides the fact i had to re-select the default scene before exporting, which seems unrelated)

Going to be closing this issue as it appears solved!