There has been a fair amount of mention of the Mono utility mkbundle which is supposed to (among other things) allow you to create a bundle (standalone .exe) with a C# project compiled with Mono. This works when I run it in Cygwin, however what I really would like to do is use the --deps option and --static option to pull in all of the dependencies and libraries so that it really is a standalone. While running the command in Cygwin, it claims that --static is unsupported under the current platform (I assume it is referring to windows). The question, then is :
Is there any way around this dilemma?
If not, what specific .dlls am I now required to carry along with my executable in order to get the thing running? It doesn't seem to be listed anywhere on the mono site.
Thanks!
http://linux.die.net/man/1/mkbundle:
On Windows systems, it it necessary to
have Unix-like toolchain to be
installed for mkbundle to work. You
can use cygwin's and install gcc,
gcc-mingw and as packages.
(sic)
There are no way to make a crossplatform app in mono with all necessary libraries included because these libraries will rely on some specific non-managed libraries.
The right way here is to create an installer (using wix for example) for your application and include a mono installer in it. So when you'll install your app the mono will be installed too. For linux you'll need to create an installer too.
Related
I have a GTK# project that has been developed using C#, on Xamarin Studio, on Windows.
I can generate an .exe file for my application but I can't run this on a Mac. Is there a way for me to convert this .exe file to a .dmg / .app OR to run this .exe on a Mac without using Windows (Bootcamp)?
Note: WineBottler has not worked for my project.
You should use macpack to package the application for execution on OS X. Take a look at the manual here: http://manpages.ubuntu.com/manpages/zesty/en/man1/macpack.1.html
Here's an excerpt from that page:
macpack is a tool used to package managed assemblies
(like System.Windows.Forms or Cocoa#) that require gui
availability for deployment on Mac OS X.
macpack will prepare a OS X compatible bundle from the
provided assembly and resources. The bundle will include the
specified assembly as well as any of the provided resources (specified
with the -resource: switch).
If you have Mono installed on your Mac then the .exe compiled on Windows should run unless you've got a dependency on something that is specific to windows. Some Windows libraries have not been ported to Mono for Mac or Linux, and if you are using ILMerge (windows) or ILRepack (*nix) then you will also potentially run into issues.
You don't need to use MacPack to build an app file, you can do it manually fairly simply as long as Mono is installed on your target Mac machine. There is a structure to an .app package folder which you can build manually.
Let me know if you need any more help, Cheers, M.
You don't need anything special, provided both Gtk# and mono are installed. That said, there are not ports for many 32bits libraries, so you need to specify the architecture to use.
$ mono --arch:32 program.exe
Refer to this document:
http://www.mono-project.com/docs/about-mono/supported-platforms/osx/
I have an application that uses a third party DLL. Is there a way in Visual Studio for Mac to write an application to access it the same way as I can on windows?
It depends:
Managed .NET DLL:
Can be imported and used the same way as in VS on Windows
Native DLL: can't be used directly. You'll need to build it for your target system, OSX in your case.
If you have C/C++ code you should be able to build it for OSX (with GCC for example) if it doesn't have some foreign (Windows) platform specific code. Then you can use the compiled *.so / *.dylib file directly. But you'll need to tell the .NET Runtime (Mono for example on OSX) to use the different file using a DllMap configuration file (see http://www.mono-project.com/docs/advanced/pinvoke/dllmap/ for examples).
The sources you've linked look like they're for Unix, so the chance to be able to build them on OSX are pretty good (there's a Makefile and the resulting binary would be libswe.so on Unix). You could try to pass the -dynamiclib parameter to GCC to get a OSX specific libswe.dylib (What are the differences between .so and .dylib on osx? seems to be a good answer about dylib)
If you have the binary of your DLL for OSX, you just need a configuration file for your .NET application, which could look like this:
<configuration>
<dllmap os="osx" dll="libswe.dll" target="libswe.dylib"/>
<configuration/>
It tells the .NET Runtime to import the symbols from libswe.dylib instead of libswe.dll if the current OS is OSX.
No.
Although you might think that because you have an IDE with the same name as the Windows counterpart the binaries it produces are not transferable.
An answer on Super User gives some more information:
There's no real DLLs in OS X, Linux, or any POSIX for that matter.
They don't make the differentiation.
Why?
A lot of Mac stuff, for one, is self-contained (.app's are really just
folders after all).
Although...
Another queston on SO asks the same thing, and an answer says:
Finally Microsoft released .NET Core which is completely platform
independent.
... now .NET applications can be developed on Mac or Linux machine
using the lightweight IDE Visual Studio Code and Visual Studio for Mac
IDE has been released where Mono on MacOS X is integrated.
So if the supplier of the library (DLL) you want to use has created a version of it with the .NET Core framework, you might be in luck.
I've got a C# Application that is 32-bit with a target x86 Installer. This application can be installed an run on x64 machine no problem. However, a third party piece of hardware from a vendor (which is integrated into the software) now requires the use of a 64bit DLL whenever we install on x64 systems.
Currently I have placed both the 32bit DLL and 64bit DLL in my project. However the target x86 Installer obviously doesn't like the 64bit DLL.
Is it possible for me to create a solution whereby I can deploy the 64bit DLL and/or 32bit DLL and still only have one installer project? (I've looked at third party software called Advanced Installer but I do not know for sure if this will help me achieve the solution I need)
Or is it possible to create a generic Installer project?
Note: Two installer (x86 vs x64) deployments aren't feasible because we have a process for automatic updates I do not want to redefine. Maintaining one MSI file is important to me.
Advice is much appreciated.
Installing the file from a x86 MSI is not a problem with Advanced Installer, the following article explains how to do it:
http://www.advancedinstaller.com/user-guide/qa-OS-dependent-install.html
Also, if you have two versions of the DLL with the same name that need to be placed in the folder you should look here: http://www.advancedinstaller.com/user-guide/qa-install-file-with-same-name.html
However, you should first check if your application can correctly load the x64 DLL, as the guys mentioned in their comments.
I am working on a Mono GTK# desktop app written in C#. I have developed my app using the MonoDevelop IDE (v2.4.2) on a Mac (OS X v10.6.7). My app depends on the GTK# library (obviously) as well as the Mono.WebServer2 library for running a local ASP.NET server.
I have tested my app on my own Mac as well as other Macs. Everything is working out great. Now, I am interested in porting my app to other platforms (specifically, Windows 7 and Ubuntu v11.04). I have been playing around with the mkbundle command but I haven't had any luck in creating a working bundle for other platforms than Mac OS X.
Since I have tried a number of different solutions without success, I would like to hear from the Mono developers out there. What do you do to port your app to other platforms?
I have been developing C# using Visual Studio for a long time but I am new to the Mono development environment. Therefore, I would very much appreciate a detailed explanation.
Thank you very much!
It doesn't really sound like you're talking about porting, rather packaging. MonoDevelop's "Project/Create Package" function can create simple binary packages (zips etc) or source packages (source plus makefiles) but these are not the ideal form to distribute to most end-users. Some additional work is required to make a polished installer for each platform.
mkbundle bundles the Mono runtime into your app, therefore it creates binaries that are 100% platform-specific.
For Mac, the usual way to distribute an app is as an app bundle. MonoDevelop doesn't automate this for GTK# projects, but I explained how to do it on my blog.
For Ubuntu, you can distribute a zip of binaries and require that your users install Mono, GTK# and xsp. If you create a .deb package, you can embed these dependencies into the package manifest. MonoDevelop doesn't have any tools for creating deb/rpm linux packages, and I'm not familiar with the process myself.
For Windows, you can provide a zip of binaries and require that your users install .NET and GTK# for .NET. You could also create a msi installer and have it check for these prerequisites.
It sounds like you have already solved the problem of packaging for Mac.
On Ubuntu, you would want to create a .deb package that contains your app and requires other packages as dependencies (Mono, Mono.WebServer2, GTK#, GTK+, etc). The following link should get you started on building Ubuntu packages:
https://wiki.ubuntu.com/UbuntuDevelopment
For Windows, you probably already know how to build an installer if you have .NET experience. I would say that you would want to run your app on top of .NET instead of Mono. That is what the Mono team do themselves (for MonoDevelop as an example). Bring in the Mono specific bits like Mono.WebServer2 as part of your application.
Your biggest issue here will be that GTK# requires the GTK+ C libraries to be installed. Probably the easiest thing is to detect if GTK# is installed as part of the installer and ask your users to install GTK# if they need it. You are going to have to do the same detection for the .NET version you require anyway. You can get GTK# for Windows here.
I do not have great instructions for doing this but both the Banshee and MonoDevelop projects do it well. I would take a look at those projects as they will show you exactly what needs to be done.
https://github.com/mono/monodevelop
http://git.gnome.org/browse/banshee
EDIT:
I just recently realized that the code for the GTK# installer is on GitHub here.
There are is also packaging projects available in Monodevelop. you can use them.
I'm doubtful that mkbundle work well other than Linux.
Another option that open your project on other plateform (you can use Monodevelop) and build the project and use some other app to build package.
I just recently created deb package of my own .Net project written in MonoDevelop. From MonoDevelop I created a package with sources and makefiles (makefiles also generated by MonoDevelop) and then i used this guide>
http://www.webupd8.org/2010/01/how-to-create-deb-package-ubuntu-debian.html
to create deb package. Dependencies were mono-runtime and gtk-sharp2.
Can someone help/guide me with using SQLite lib on Linux (MONO) and Windows (.NET)
On linux i use native mono sqlite client, and on windows i use http://sqlite.phxsoftware.com/
is there a way to define 'using' directives like this :
#if (linux)
using Mono.Data.Sqlite;
#else
using System.Data.SQLite;
Another problem is small differencies on both implementations, like :
cmd = new SqliteCommand(); // mono
cmd = new SQLiteCommand(); // sqlite.phxsoftware.com
Waiting for any help
If you know better or simplier way to do this it'll very thankfull for info.
Thanks
You can use csharp-sqlite which is a port to C# of Sql-Lite. It is very active and based on 3.6.22 version of SqlLite. See Miguel's comments on attempts to try to speed it up.
I've recently come across the issue too: building an application that uses Sqlite on Windows with Visual Studio and deploying it on an Ubuntu Server box for production.
The simplest solution I've found is using the Mono driver for Sqlite: Mono.Data.Sqlite.
Things could have been a little simpler but there is a bug with .Net 4.0 that is not yet packaged in the official Mono releases.
So you'll have to compile Mono from source (the general instructions are here):
first compile the whole Mono stuff
you do not need to install it if you want to keep your current Mono setup
copy the Mono.Data.Sqlite.dll library
Of course you can "cross-compile": I've built Mono on Ubuntu Server and used the dll in a Windows .Net project.
Then ensure you have the native Sqlite library (sqlite3.dll for Windows and sqlite3.so for Linux) in your library path: for Windows I simply copied the sqlite3.dll next to the Mono.Data.Sqlite.dll assembly, for Linux it should work out of the box.
You project should then work seamlessly in both Windows/.Net and Linux/Mono environments.
You can solve the naming differences using alias
#if (linux)
using SqlCommand = Mono.Data.Sqlite.SqliteCommand;
#else
using SqlCommand = System.Data.SQLite;
Using different assemblies for different builds is a more complex task i think.. you can have a look at the MSBuild documentation
There is a fully managed SQLite translation. If you use that, then you could use the same DLL on Mono and Windows.
Another way to solve your issue is to create your own database-interface and then implement that interface once for Mono and one for Microsoft .NET in separate DLLs. (Basically the same way you create code that runs against different databases)
You can just use the mono implementation of SQLite for both, Windows and Linux versions of your software. Just include the mono assembly for SQLite in your software package and refer to it locally.
As you can read here in the last post, you can use the managed way of mono solely in your code and need just to redistribute the native part for windows differently. But you do not have to mess with to managed implementations and redundand code through that.
The open-source Vici CoolStorage ORM library works on Windows (.NET), Mono (Mac,Linux and Windows) and MonoTouch (iPhone) using that platform's SQLite driver.
To use it on these different platforms, you don't have to change anything to your source code. Just recompile, and it should work.
IMO you should first try to find an implementation that works in both Windows and Linux. If that doesn't work, create an assembly that defines a common interface for SQLite and put all you "#if LINUX" code in that assembly. Then use that assembly in the main application to avoid cluttering the main app with all the # defines.
The SQLite ADO.NET provider is actually a mixed-mode assembly, which contains the native SQLite library. This native library is not the same on Windows and Linux of course, so this provider doesn't work on Linux. However, there is a managed-only version of the provider (SQLite-1.0.65.0-managedonly-binaries.zip on the download page). So I think you just need to use this version of the provider, and provide the adequate native SQLite dynamic library along with it (.dll on Windows, .so on Linux)
Some answers suggest the fully-managed C# port of SQLite3. But, unfortunately, no release to date supports Linux or Mac OS X despite being compilable with the Mono C# compiler.
A future release will correctly run on those non-Windows platforms with the Mono runtime. WIth some caveats, the source repository contains code that works.
Having said that, the System.Data.SQLite implementation available from sqlite.org works with both .Net and Mono, on Windows and non-Windows platforms. You just need to ensure that the app.config used by Mono at runtime maps the (C++) SQLite3 dll to the appropriate .so or .dylib library. If you choose the "mixed-mode" version, then it should just work and you don't need to worry about separate dlls.