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.
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/
What's the best way to build a c# solution made with Visual Studio on Ubuntu? Is there a way to convert the .sln file to a makefile? Should I use Mono?
The first thing I would do would be to use Moma to check to see if your program will run under Mono as is. You can also use MonoDevelop which can use Visual Studio Projects.
From their faq: In fact, since MonoDevelop 2.0 the default project format has been VS2008-style MSBuild projects, but VS2005 and VS2010 formats are also handled.
C# is a .NET language, .NET is a Windows-based framework. It has been ported to Linux operating systems (Ubuntu included) via the Mono Project. So yes, you need to use Mono.
Mono is the best I've tried. It says on their homepage that they are binary compatible between each other, so if it's already built, you could just run it on Mono. No need to recompile.
Your best bet is to use Mono if you want to use a process like MsBuild. Mono has xBuild that is similar. This SO question has some information about using Mono.
I have a dll. and visual C++ source for it. (my dll is visual c++ wraper around some ffmpeg av* libs - another precompiled dll's) while in the same solution (.sln) I have C# project that uses my dll.
what are general steps for me to port my project to mono?
Mono does not support mixed-mode assemblies on non-Windows operating systems.
Remove your C++ wrapper and rewrite your application to only use P/Invoke to call into native code.
See also: www.mono-project.com/CPlusPlus
Compile your project in Visual Studio, but enable the following compiler options:
/clr:pure: This will make a pure CLR assembly (without any x86/x86-64 asm), that should run on mono, unless you use some C runtime calls (CRT).
/clr:safe: The same as pure, but you can't have CRT references, so your project might not compile. If it doesn't, replace those function calls with other portable calls.
The resulting assembly should be pure CLR and will work with Mono.
This page contains everything you might encounter when compiling a version that works on Mono.
I would suggest also take a look at this -
http://mono-tools.com/store/
There are various tools available to help you port to Mono - you can even debug within visual studio and package it for deployment on Linux.
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.
There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.