In the past, I’ve helped customers run native Windows applications using emulation (wine) and/or virtualization, and in few cases, native support for C# by open source projects such as Mono. But, as it’s been said, there are great benefits of having source code, and I recently worked around an issue in Mono by recompiling a whole .NET project in Debian.
So here’s a brief guide reviewing the issues that I found and how I solved each one of them leading to a natively-compiled C# application that runs seamlessly in Debian and Windows, and please remember I’m not a C#/.NET/Mono developer:
- Missing assemblies: sometimes gmcs (which is the Mono compiler) will complain about missing assemblies, that is, libraries that are requested by the C# source code (files that end with .cs) hopefully because some methods are being used in that specific file. I know they’re, but I still haven’t found a .NET class that is not supported in Mono. So, first and foremost, you need to actually have that library installed in your system, if you’re using a Debian based system run aptitude search libmono.* or the packages.debian.org site to find which package has the library file (ends in .dll) and then, when you’re calling gmcs, remember to use the –r: flag, for example –r:System.Drawing.dll
- Missing resource indicators: apparently .NET projects consume stuff from resource files which also seem to be XML files. Since I don’t know how to handle this situation, I resorted to the fine MonoDevelop IDE, since I had a .csproj file (a Visual Studio Project file) in place which hopefully could join the dots. So just use MonoDevelop (you need to install it separately) and then open the .csproj file and rebuild the entire project (F8) which in my case just left 2 errors to go
- Issues with configuration management: it seems that the .NET Framework has some classes that help with application configuration via generic XML configuration files, and the project that I was trying to compile used that indeed, so there were some tags in the configuration file that weren’t properly handled by Mono, e.g., the default system proxy configuration parameter, so I just deleted it from the XML. Be also advised that you do need to have the .config XML file in place together with the resulting .exe file if your application access configuration parameters in runtime.
- SSL- and TLS certificate-related issues: finally, if your application uses an SSL or TLS Web Service (or any other SSL/TLS application FWIW) you might get some errors like “authorization or decryption failed” which are basically related to non-existent certificate handling in the application. The easiest way to solve it is to download and import the CA Certificate Files from Mozilla and also download the certificate for the site you’re trying to access; you can run (as the user that will run the application):
- mozroots –import –ask-remove
- certmgr –ssl https://your.site/
That said, I had a great time fiddling with this C# application and Mono on my Debian Sid laptop. I was able to properly compile without errors nor framework-related waings, using an IDE such as MonoDevelop, and have a full-featured native binary that’s interoperable.