What is needed to make a file runnable?

I sent a published project to a friend who is using Mac OSX. Unfortunately the file would not run. A message pops up basically saying no executable file is found for the file to open it with.

Anybody here who knows what steps are needed to run a MonoGame application on Mac OSX?

Maybe it is a security thing because I am not a registered Apple dev?

Of its 3.8, dont they need .net core runtime installed? Then run dotnet youtassembly.dll

Yes itā€™s 3.8. I used dotnet publish to get executables for each target OS. So I thought installing dotnet core runtime would be the dependency which they need to install. But I assumed they can just start the executable files like any other app?

No experience for publishing to iOS, I pretty much build (in my day job) .NET Core for portable each time, and so have to execute via dotnet assemblyName.dll on my AWS insatance.

OK I read a bit more about the topic. I do a self-contained deployment. This SCD creates platform specific executables. E.g. an *.exe file for windows and files with no extension for Linux and Mac but using a file format matching these target OS. So in this case I think it should be fine to run the files directly / like any other application (ommiting the dotnet command).
For one test on a windows machine it worked. I think only the .NET Core Runtime needs to be installed on the target machine to provide the native dependencies of .NET Core.
For Mac OSX I will have to wait until I get some feedback. I expect it will work with SCD we will seeā€¦ :slight_smile:

1 Like

Just got the feedback and everything works :smile::partying_face:

Was not so easy to guide the test because the Mac is located on another continent and the friend had never used the terminal before.

So the required steps are:

  1. Self contained deployment
  2. Make file executable
  3. Allow the file being started
1 Like

This is certainly way less user-friendly in 3.8 than it was in 3.6!

Thanks for the info above it really helped me. A few more specifics if anyone needs them, the exact command I found to work isā€¦

dotnet publish --runtime osx-x64 -c Release -o Publish -p:PublishSingleFile=true

ā€¦when run from the project directory this creates a single file built from the ā€˜Releaseā€™ configuration and output to the directory called ā€˜Publishā€™.

Double-clicking on the resultant file did nothing until I renamed it with a ā€˜.appā€™ extension. I canā€™t see a way to do this from the command line, it just seems to use the project name for the name of the file.

Once renamed the file can be launched though for some reason it now has a duplicate extension of ā€˜.App.appā€™, though this can be renamed again.

The file is seen by the OS as a ā€˜unix executableā€™. It is not the normal app ā€˜packageā€™ Iā€™d expect on MacOS so I have no idea whether this can be uploaded to the AppStore (I doubt it) or even distributed via Steam as thereā€™s no info.plist, icon bundle and all the other things youā€™d expect.

If anyone knows how to turn this into something that resembles a ā€˜properā€™ Mac application Iā€™d be all ears!

1 Like

Has been a while since I fiddled with that. I remember that the friend also expected it to be in another ā€œformatā€ and I guess he meant the mentioned app package which I guess is the standard in the MacOS world? A lot of guessing here because I donā€™t own a Mac. I would also be interested to know if and how to publish to this format so that the published MonoGame app can be run conveniently without manual steps required by the end user. I remember vaguely that maybe it is required to register as a MacOS developer because of app packages require that they are signed? But not sure about thatā€¦

For the friend double clicking did also not work initially. The above mentioned manual steps were required. So that would be to make the produced file executable first using the command line. After that double clicking the file should work and the OS should come up with a message / warning were the user has to explicitly allow the file to be started. This message will only come up the first time I think.

Hope this helps! Some MacOS developers with more knowledge maybe can provide some more useful info here :slight_smile:

It is possible to package it as a standard app package, I did some messing around last night, but I would like to know of a way to automate this properly. There is some documentation in the packaging section of the MonoGame site but itā€™s sorely lacking. I would happily write some documentation if someone could give me a few more pointers!

An app package on Mac is basically just a folder with the suffix .App. I followed the directory structure outlined on the link above, put all the .dlls in the MacOS directory along with the executable. The thing thatā€™s missing is that you have to change the CFBundleExecutable property in info.plist to match the name of your executable (which will be the name of your project by default).

Anyway, it all works, but for some reason the icon isnā€™t showing up (even though I appear to have everything organised correctly) and there really needs to be some explanation of how to do this properly.

Personally I preferred the way 3.6 worked with a native app build as I canā€™t seem to reference native MacOS APIs in the code either now. I see why itā€™s been done this way though, MacOS is very much a minority platform and a .Net core app is probably easier to maintain.

1 Like

But the folder is compressed somehow so that you have a single file I guess?

Would be helpful to have some verification system from Apple or does something like this exist? I mean for the app format they use which then tells you what needs to be done to make those Icons appear etc. and what if so does not satisfy the format.

Maybe the steps to automate the creation of the app package format can be scripted?

No, itā€™s just a standard folder. The OS presents it to the user as a single file but you can just browse as a standard folder if you click ā€˜Open Packageā€™ in the Finder.

If you browse via the terminal it comes up as a standard folder.

Iā€™m sure it would be possible to automate the build process but itā€™s beyond my current scope of knowledge and, unfortunately, I have more pressing tasks at the moment. : ) I will be looking into this some more at some point though.

1 Like

For the icons maybe you need to convert it to the icns format. I donā€™t know if this online converter works but you could try if you like:

I wonder if a bash script would work. If yes maybe it isnā€™t that difficult to make one to get it at least automate the steps for your specific project (avoiding variables for project name so it will just work for your project but should be easier and quicker to setup).

In case it helps - here is a .bat file for OSX that packages a MG3.0 DesktopGL project as a runnable app. Run this from your project folder after editing with the name of your game and paths to your Info.plist and Icon.icns files.

Iā€™d upload the actual file but it wonā€™t let me!

# Packages a dotnet core MonoGame Desktop GL project as a runnable OSX app in bin/Release/osx-64/
#
# Author: James Closs | james[at]bitbull.com
#
# Please also read the section on package apps for OSX here https://docs.monogame.net/articles/packaging_games.html
#
# Generally you can just replace 'JetboardJoust' with the name of your game
#
# Publish the project - files are output to bin/Release/netcoreapp3.1/$PLATFORM/publish/ 
dotnet publish -c Release -r osx-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained
# Remove output directory if it exists
rm -r bin/Release/osx-64/
# Create output directory
mkdir bin/Release/osx-64
# Create main app package folder
mkdir bin/Release/osx-64/JetboardJoust.app
# Create necessary subfolders
mkdir bin/Release/osx-64/JetboardJoust.app/Contents
mkdir bin/Release/osx-64/JetboardJoust.app/Contents/Resources
mkdir bin/Release/osx-64/JetboardJoust.app/Contents/MacOS
# Copy all MonoGame content files to the correct location
cp -r bin/Release/netcoreapp3.1/osx-x64/publish/Content bin/Release/osx-64/JetboardJoust.app/Contents/Resources
# Copy all .dlls etx to the correct location
cp -r bin/Release/netcoreapp3.1/osx-x64/publish/* bin/Release/osx-64/JetboardJoust.app/Contents/MacOS/
#
# NOTE If using additional native libs such as required for Steamworks.net these must be copied to Contents/MacOS
# If not using additional native libs you can ignore this line
#
cp bin/Release/netcoreapp3.1/osx-x64/publish/runtimes/osx/native/libsteam_api.dylib bin/Release/osx-64/JetboardJoust.app/Contents/MacOS/
# Remove the content directory from Contents/MacOS - it will have been copied with everything else and we don't need it there 
rm -r bin/Release/osx-64/JetboardJoust.app/Contents/MacOS/Content/
# Copy the Info.plist file to the correct place (you may have have it somewhere other than resources/osx/)
cp resources/osx/Info.plist bin/Release/osx-64/JetboardJoust.app/Contents/
# Copy the Icon file to the correct place (you may have have it somewhere other than resources/osx/)
cp resources/osx/Icon.icns bin/Release/osx-64/JetboardJoust.app/Contents/Resources/
# If debugging Steamworks APIs you may need this file, otherwise you can ignore this line
cp resources/osx/steam_appid.txt bin/Release/osx-64/JetboardJoust.app/Contents/MacOS/
4 Likes

Thanks, I changes rm -r to rm -rf to avoid error when folder doesnā€™t exist yet, and passed the app name as argument (instead of hardcoded JetboardJoust). The script would need extra adjustment per-project anyway (to use Steam or not, and indicate plist/icon path), but itā€™s a good base to work from!