Building & cross compiling experience

[Domarius]

Question: The "Platformer.exe" that I built sucessfully in Linux, should it run just fine in Windows? I tried, and it crashed with a "DllNotFound". I tried putting the TileEngine.dll from the newly downloaded Win32 build in the same folder, but that didn't solve the problem. Here's the crash details;

Code:

Problem signature:
  Problem Event Name:    CLR20r3
  Problem Signature 01:    Platformer.exe
  Problem Signature 02:    0.0.0.0
  Problem Signature 03:    5b449d42
  Problem Signature 04:    Platformer
  Problem Signature 05:    0.0.0.0
  Problem Signature 06:    5b449d42
  Problem Signature 07:    2d
  Problem Signature 08:    e
  Problem Signature 09:    System.DllNotFoundException
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    3081
  Additional Information 1:    407d
  Additional Information 2:    407d44cfad84bab60e2bab1da2aa3158
  Additional Information 3:    6bf4
  Additional Information 4:    6bf42ca98f725d93419edfced24dc524

I also tried "mono Platformer.exe" from the commandline, after installing Mono 32 bit for Windows and using its "Open Mono x86 Command Prompt" start menu entry, confirmed mono works from the commandline, but doing "mono Platformer.exe" as I did in Linux, didn't do anything in Windows. It just returned to the prompt immediately, no errors. Here's the evidence;

Code:

Mono version 5.12.0.226
Prepending 'C:\Program Files (x86)\Mono\bin\' to PATH

C:\Program Files (x86)\Mono>mono
Usage is: mono [options] program [program-options]

Development:
    --aot[=<options>]      Compiles the assembly to native code
    --debug[=<options>]    Enable debugging support, use --help-debug for detail
s
    --debugger-agent=options Enable the debugger agent
    --profile[=profiler]   Runs in profiling mode with the specified profiler mo
dule
    --trace[=EXPR]         Enable tracing, use --help-trace for details
    --jitmap               Output a jit method map to /tmp/perf-PID.map
    --help-devel           Shows more options available to developers

Runtime:
    --config FILE          Loads FILE as the Mono config
    --verbose, -v          Increases the verbosity level
    --help, -h             Show usage information
    --version, -V          Show version information
    --runtime=VERSION      Use the VERSION runtime, instead of autodetecting
    --optimize=OPT         Turns on or off a specific optimization
                           Use --list-opt to get a list of optimizations
    --security[=mode]      Turns on the unsupported security manager (off by def
ault)
                           mode is one of cas, core-clr, verifiable or validil
    --attach=OPTIONS       Pass OPTIONS to the attach agent in the runtime.
                           Currently the only supported option is 'disable'.
    --llvm, --nollvm       Controls whenever the runtime uses LLVM to compile co
de.
    --gc=[sgen,boehm]      Select SGen or Boehm GC (runs mono or mono-sgen)
    --mixed-mode           Enable mixed-mode image support.
    --handlers             Install custom handlers, use --help-handlers for deta
ils.
    --aot-path=PATH        List of additional directories to search for AOT imag
es.

C:\Program Files (x86)\Mono>d:

D:\>cd \Users\Clint\Documents\My Files\Game Development\Tilengine\Tilengine-mast
er\samples\csharp

D:\Users\Clint\Documents\My Files\Game Development\Tilengine\Tilengine-master\sa
mples\csharp>mono Platformer.exe

D:\Users\Clint\Documents\My Files\Game Development\Tilengine\Tilengine-master\sa
mples\csharp>mono Platformer.exe

D:\Users\Clint\Documents\My Files\Game Development\Tilengine\Tilengine-master\sa
mples\csharp>mono Platformer.exe

D:\Users\Clint\Documents\My Files\Game Development\Tilengine\Tilengine-master\sa
mples\csharp>

Oh, btw, don't try getting MonoDevelop on Windows. There is no Windows download, you have to build it, it has errors, and even when you get it running, the "File -> Open" menu item does nothing! You can make new projects just fine, but opening existing ones? Noo. And no forum to ask for help in, only an IRC channel that no one replies on. So I guess I can only use MonoDevelop under Linux. So much for MonoDevelop being "cross-platform".

[megamarc]

Regarding Ubuntu distros: Travis CI runs build tests under 14.04, so throw in another configuration... Do you know Travis? For building myself I use the 16.04 LTS branch and everything is ok. Debian Stretch (9.x) for Raspberry, and Mac OSX 10.11 "El Capitan" for Mac.

And yes, there are teams maintaining cross platform libraries, with people experienced on the quirks of each platform. Windows has its dose of bad reputation, but the fact is that its compatibility and stability on the long run is much higher than Linux or OSX. Nowadays you can build apps in a Windows XP machine with Visual Studio 2005 and run that produced binaries under Windows 10. Try to do that with a 14-year old linux or OSX version...

[megamarc]

MonoDevelop was acquired by Xamarin and turned into the commercial product Xamarin Studio, that in turn was acquired by Microsoft and integrated into the new VisualStudio 2017 as a plugin. That's why MonoDevelop is orphaned under Windows, because it would compete with their own commercial offerings.

Yes, your C# Platformer.exe built in one machine should run in another. The problem here is not the Mono/.NET binary itself, but the fact that it relies on native system libraries: Tilengine and SDL2.

Under linux that's easy because there's a common place where to put shared system libraries: /usr/lib everything you put there is accessible to everyone. Apt packages and the Tilengine install script put their binaries there.

But in under Windows there's no such place to put common shared libraries and you have three options:

1. Pollute \windows\system32 folder with SDL2.dll and Tilengine.dll. Ugly.
   
2. Pollute the already cluttered environment path variable with yet another custom folder. Ugly.
   
3. Put a copy of SDL2.dll and Tilengine.dll on each and every folder where you have a tilengine executable. Ugly, but what's the install.bat script does.
   

So in short, under Windows it's the end-user responsibility to make shared libraries widely accessible, or I must provide an installer. I don't know what should be my official solution for this matter.

[Domarius]

Ah, I see - I didn't try SDL2.dll as well.

I just experimented and from what I can tell, pretty sure the problem is I complied that example on 64bit Linux, so the 32 bit SDL2.dll I have is causing a "System.BadImageFormatException" error in Windows.

I stopped experimenting because I have to pack it in for tonight, so I thought I'd run this by you for now;

• I could continue to develop under Linux and produce a Linux 64 bit version of my game.
  
• Then under Windows, I can run csc or mono or whatever it is you do, from the commandline, to compile a 32 bit Windows version of the game, and throw in the 32 bit version of the Tilengine.dll and SDL2.dll.
  

Would that workflow work do you think?

[megamarc]

In .NET/Mono executables, you have to pair the version of the native shared library (SDL/Tilengine) with the architecture of the host OS that runs the program: If your OS is 32-bits, you must provide 32-bits dll/so, whereas in 64-bit OS, dll/so must be 64-bit. The architecture of the machine where you compile the .NET/Mono application is irrelevant, because they're platform agnostic. It's the architecture of the OS that loads and runs the executable the one that matters.

Keeping this in mind, I've built C# Platformer.exe with .NET Framework 4.0 under 64-bit Windows and executed that same binary on the Raspberry Pi (that is 32-bit ARM) running mono.

[Domarius]

Oh wow, ok. I still need to compile a 64 bit SDL2 then.

Regarding your concerns distributing the DLLs, wouldn't you just provide 32bit and 64bit downloads as you have, and just let the developer know they need to release a 32 bit and 64 bit version of their game, with the appropriate DLLs included?

[Domarius]

Forget I said compile - I can just download it, doh. Sometimes I have my head so far stuck in the details I forget the obvious things. Trying to get MonoDevelop working on Windows really did my head in. And that's sad, what you said about Microsoft buying out the Windows side of MonoDevelop. Just another thing they've bought up to extinguish the competition. A perfectly good free cross platform IDE for C# now doesn't have a working Windows version and you have to go back to MS Visual Studio.

Anyway, I'm thrilled - the same file ran on Windows just fine, with the 64bit versions of Tilengine.dll and SDL2.dll. And then I found https://github.com/MonoGame/MonoKickstart, once all the files were in the folder and renamed appropriately, I have a folder of a game that runs on 64bit versions of Windows, Linux, and MacOS (apparently, can't test the latter) depending which file you run, so I could just distribute the one folder instead of providing separate downloads. Kickstart can switch to the 32bit versions of its files automatically, so I guess if I wanted to distribute a Windows 32bit version I could provide a separate download.

This is new territory for me, have I got that right? Is there anything else I should be aware of?

[megamarc]

Visual Studio is an outsanding tool, I'm not affiliated to Microsoft but I'm using this tool for many years. Recent Community versions are free for personal use and include the complete Xamarin plugin, unlike the former Express versions that were heavily stripped-down.. So in some way Microsoft has returned it to the open community.

The problem is not C#/Mono, but the lack of a standard way in Windows to put common shared libraries. You can manage to have C# working with its correct set of libraries, but then you'll be in trouble again with Python, and with any native .exe you produce. That's a inherent problem in Windows to solve runtime dependences, other than providing an installer

[Domarius]

Oh don't get me wrong, VS is great.  It's just that they clearly couldn't stand another piece of software using C# that they didn't have control over... it would have been nice to just open the project in MonoDevelop on both Windows or Linux.  Not a huge issue, just a shame I think.

[Domarius]

Quick question - what is YOUR preferred workflow for building a Tilengine game?  Eg. which combination of Windows, Linux, SDL2, C, C#, Python, etc. etc.
And if it's primarily Windows, what workflow would you use for Linux?