I build a lot of packages that have cross-platform targeting. I like using NuGet as a deployment for all of the obvious reasons, but I'm having difficulty understanding how I target a specific binary for Mono on Linux.
As an example I have a library that, in the Mono for Linux version, references `Mono.Posix.Helper.dll. This is very specific to Mono on Linux. It's not for the desktop. It's not for Mono on Android or Mono on iOS. The same library has different implementations for .NET of the desktop, .NET on Windows CE, Mono on Android and Mono on iOS.
It seems that I need two things, neither of which I can seem to find:
A way to tell NuGet that a specific set of binaries targets Mono on Linux. I see nothing in the official documentation of the NuGet schema target frameworks.
A way to tell Visual Studio that my project that will consume those binaries targets Mono on Linux. I've found this nice list of project GUIDs but, of course, there's nothing in there for Mono that isn't targeting Android or iOS.
Right now I'm solving this with a less-than-friendly post-build task, but that's really not fun when I need to create a new project that uses one of these packages.
I know Microsoft has been trying to get more Linux-friendly over the past few years, but this seems like a pretty big hole. I can't be the only person out here that's building code for Mono on Linux, can I? What's the solution here?
Currently, this isn't possible.
NuGet (3.*, 4) does have a concept of "runtimes" but those are referring to the operating system that the "runtime" runs on. So while you can have a specific asset for linux-x64, this cannot tell if you are on mono or .net core. In fact, even when you use a net461 target framework with a runtimes/linux-x64/lib/net461/linux-specific.dll file, this may even be used in a .NET Core 2.0 app since .NET Core 2.0 can use net461+ libraries.
The only way this is currently possible is to have managed shim that resolves the right assembly on runtime. This would also make the consuming project "portable" - meaning it can be run on windows directly and on linux through mono, assuming all libraries can be loaded dynamically.
Related
I have a Xamarin Forms application that uses shared code. It has three projects, shared, iOS and Android. These are very similar to those which are created when I create a sample application from the Xamarin new project menu.
I am looking to have the application updated and published by a company that has experience in doing this but I am not sure I understand a couple of the work items that have been suggested to me:
Currently, architecture is PCL which is becoming
obsolete.
Move to .NET standards
Could someone explain to me what these work items might mean?
Yes, it will become obsolete at some point. .NET Standard is the evolvement of the PCL libraries.
With PCL libraries you could target a number of platforms and only the functionality that was supported for all targeted platforms were available to you. Associated with each combination of platforms were the profiles. A profile was identified by two or three digits. Notable ones for Xamarin were 111 or 259. Read more on PCLs here: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/pcl
.NET Standard is a specification of the APIs associated to it. If a platform supports a certain version of the .NET Standard, you are guaranteed that all APIs are available. This way, you can simply target a specific .NET Standard version and each platform that supports it will support your application. The .NET Standard specification has gained a lot of traction and is already more cross-platform than a PCL ever was. Most of the creators of NuGet packages are supporting it already and also Xamarin/Microsoft has replaced the PCL with a .NET Standard library in their templates. Read more on .NET Standard as a concept here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
So, if you have the possibility it might be wise to start moving to the .NET Standard library. That is, if you want to keep supporting your app and need new libraries coming in. If your app is fine the way it is, you can probably keep going with the PCL for a while. Converting is basically: change the csproj structure to the new structure. Retarget your library to netstandard and reinstall all the libraries you have installed, this time to download the .NET Standard compatible version. The last step might be a bit of a pain.
A good resource on converting might be this by Adam Pedley: https://xamarinhelp.com/upgrade-pcl-net-standard-class-library/
There is also a solution to do it automatically: https://smellyc0de.wordpress.com/2018/03/23/automatically-converting-pcl-to-net-standard-2-0-project/
.Net Standard is a specification for a set of APIs. and is the way things are going. With it, comes a higher level of range of .Net SDK APIs you can use, plus most 3rd party Nuget packages will support it. They can support a wider range of platforms. by targeting .Net Standard. Thus you will get access to a larger number of nuget packages. See https://learn.microsoft.com/en-us/dotnet/standard/net-standard
I put my Forms Apps into a .Net Standard library, because it easier to unit test. There is a Xamarin Forms nuget package you can use for testing, which means a lot of UI paths can be verified in code, where previously you had to do it on a device, perhaps with automated testing. https://github.com/jonathanpeppers/Xamarin.Forms.Mocks
Upgrading an existing PCL project to .net standard is a pain. Any more, I just create a new Xamarin Forms solution with the same name/root namespace, with the app as .Net Standard, then copy files over.
I have a SDK written in C# targeting Win10 UWP apps.
It uses SQLite and works perfectly on C# client apps.
But can a C++/javascript app use my SDK with the SQLite dependency?
A winmd (windows runtime component build) would be required in case the SDK has to be UWP compatible since a UWP app can be in C#/C++/javascript/Visual basic.
I have posted this in msdn forums and they say i would need a windows runtime component for all the 3rd party dependencies for it to work.
Have already tried wrapper projects and wrapper winmd build, it does not work.
I am unable to find any winmd build for SQLite library.
Please advise on what can be done here.
Any help is really appreciated.
But can a C++/javascript app use my SDK with the SQLite dependency?
Yes, as in msdn forums said, you will need to wrapper in WinRT component universal apps.
Have already tried wrapper projects and wrapper winmd build, it does not work.
I don't know what blocks you, but you can refer to Writing a SQLite wrapper component for universal Windows apps, there are detailed steps you will need to follow, and samples you may have a look.
I tried various approaches to make this project work and found some success in the following:
Following is the project structure I made along with dependencies :
Client Application (in C++):
Wrapper winmd library.
Wrapper winmd library (in C#): (I generate a winmd component from this project)
My SDK project
My SDK project (in C#):
SQLite Net.
SQLite Net Async.
Newtonsoft JSON.
When I build the client application, I get the wrapperlibrary.winmd file but I dont get the corresponding dlls from the 3rd party dependencies in the output directory (SQLite and Newtonsoft). So i manually copied the required dlls to the output directory of the C++ application. Now it seems to work correctly, I can verify correct usage of the 3rd party libraries and my C# code. Presently I am just trying to make the setup work as a poc and worry about the packaging later.
The issue I now face is that my SDK also has some UI elements, so essentially compiled .xbf files for the "XAML" I have.
I have asked this question in another thread to not go off main topic here.
I've been reading a lot into this and MonoMac/Mono seemed to be the best if not one of the only ways to go about it. I do have a MacBook Pro and it seems Xamarin bought Mono and wants something like $800 for a business edition to be able to load in Visual Studio projects. I only downloaded the free version so when I tried to load in my VS project on my Mac into Xamarin it said it didn't recognize it and that's when I discovered it seemed I needed a business edition.
A lot of what my search found was stuff that was 1-2 years old and even older. Things seemed to have changed a bit since then and with the Xamarin integrating Mono sort of thing. I've been working on an XNA 4.0 game for PC for over 7 months now and I'd like to have a Mac version. Apparently games like Magicka have figured it out and were made in XNA. I plan to release on Steam so I suppose I need to find a way to try and make it work with Steam if that's possible too. I don't really use my MacBook that often and I don't have Steam on it so I'm not really sure how to go about this.
I guess it comes down to this. I don't understand the current situation of MonoMac and Xamarin and did they aquire Mono? Do I need that expensive business edition? Are there alternatives? How does this tie in to being able to release a Mac version on Steam?
Most of the information I can find is a few years ago now and a lot has changed it seems.
MonoGame is a re-implementation of the XNA API for various platforms, including Mac.
It depends on Mono to provide a C# runtime across different platforms. And on platform specific versions of Mono (such as MonoMac, MonoTouch, etc, from Xamarin) to provide the API bindings and other features specific to those platforms.
You don't so much "load" an existing Visual Studio project as create a new project - either in Visual Studio (if the tools are available and you've bought them - but I don't think this is the case for Mac) or MonoDevelop or Xamarin studio.
To your new project, you would add your existing source files and add a reference to the MonoGame library for that platform. That MonoGame library will provide versions of the classes in the Microsoft.Xna.Framework namespace that work on that platform. Your code gets compiled against these alternate classes, creating a new binary specific for that platform.
(MonoGame will probably have more in-depth documentation of the process on their website, including how to deal with game content.)
Put simply: Use MonoGame. It is an alternate version of the XNA library, not a conversion tool.
What difficulty would be encountered in deploying a Mono-based application to Windows?
Does the Mono runtime have to be installed along with the application? Would this be an inconvenience for the end user?
Edit: The idea is to deploy a cross-platform application, thus Mono as a choice.
Mono is an implementation of .NET. As long as you don't use Mono-specific APIs, it should be 100% compatible.
As #duffymo said you are probably better off requiring .NET vs requiring Mono. However, there are some scenarios where using Mono makes sense. In particular, if you use mkbundle to create an assembly without a requirement that Mono is installed. There is even a way to statically link the runtime into the exe although this brings along some licensing requirements that need to be considered.
As long as you're sticking to managed code in your application and the there is either .NET or Mono installed, you should be fine.
If Mono is a Linux version of .NET, wouldn't deploying an app developed on Linux with Mono on Windows simply mean taking your source/package and deploying it on Windows? Shouldn't the .NET pieces that need to be common already be available on Windows?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I started trying to play with Mono, mostly for fun at the moment. I first tried to use the Visual Studio plugin that will convert a csproj into a makefile, but there seemed to be no version available for Visual Studio 2005. I also read about the MonoDevelop IDE, which sounded nice. Unfortunately, there's no pre-fab Windows package for it. I tried to follow some instructions to build it by combining dependencies from other semi-related installs. It didn't work, but that's probably because I'm a Windows-oriented guy and can barely spell "makefile".
So, my question is this: What's the lowest-energy way to get up and running to try some Mono-based development on Windows?
I'd recommend getting VMWare Player and using the free Mono development platform image that is provided on the website.
Download Mono
Setup time for this will be minimal, and it will also allow you to get your code working in .NET and then focus on porting issues without a massive hassle of switching machines and the like. the VMWare Player tools will allow you to simply drag and drop the files over to copy them.
I'm looking to take a couple of my .NET apps and make them Mono compliant, and this is the path I'm going to take here shortly.
A year later and the answer to this has change greatly. You can now use MonoDevelop on Windows, or if you are more comfortable in Visual Studio you can use the Visual Studio Tools to write everything and then debug on in VM to make sure it is working on Linux.
#Chris I have found that Visual Studio is the best IDE for developing against .NET -- I think the best way to target Mono is really just to develop and build in Visual Studio under Windows then just run those binaries directly on Linux (or whatever other Mono platform you are using). There are free versions of Visual Studio if licensing is a concern. If you are developing under Linux, the best software is probably Eclipse with a Mono plugin (see The Mono Handbook - Eclipse for installation instructions) but keep in mind it doesn't have near the amount of features or language integration Visual Studio has.
#modesty Mono is a 3rd party open source implementation of the .NET framework which allows you to run .NET applications on platforms other than Windows.
One of the best things you can do if developing with Visual Studio for Mono is to get MoMA http://www.mono-project.com/MoMA. This will inspect any number of assemblies that you build and generate a report showing potential Mono problems (e.g., methods not implemented in the mono library). It can be run from a GUI or the command line for use in automated builds.
Miguel had a post about debugging Mono running on linux with remote debugging on Visual Studio. This may be something you want to look into... Using Visual Studio to debug Mono. There is also a new project called CloverLeaf whose goal is enabling debugging Mono on Windows in Visual Studio.
There's just no reason to build your app using Mono; the whole point of the .Net CLR is that the compiled output is cross-platform.
So you can simply build it using your favourite IDE (and if you like IDEs, Microsoft's is the best one to use) and then test it on Mono. Even if you get Mono working on Windows, it wouldn't be a very good test of your app's portability: what if your app does silly things like assuming filenames have backslashes in them, or that there's something special about a folder called Program Files? The best way to do portability testing is to actually test your app on the target platform.
And that's pretty easy to do with a Linux VMware player like the one at http://www.go-mono.com/mono-downloads/download.html.
Personally, I'm just compiling in Visual Studio 2008 as if it were for .Net 2.0 and then running in Mono (VS2008 on Windows in a VirtualBox, Mono on OSX). All the problems come up at runtime, anyway, so the system works perfectly.
I just found this very new link, which is amazing and shows you how to set up Visual Studio 2008 for Mono.
At the same time, setting up Mono on OpenSuse or Ubuntu inside a VirtualBox (Sun's product) is easy, painless, and doesn't force you to abandon whatever platform you normally live in.
This is not relevant to your question, but I might note that I just got into Mono and I'm amazed at how much of .Net is implemented, including much of the Winforms stuff.
My first instinct would be the rather unhelpful "Install Linux". You are somewhat swimming against the current to try and develop in mono under windows. Installing GTK and everything is a bit of a bother in my experience.
If you do feel like using linux, then you could Try Ubuntu
Otherwise:
There's some information here: http://www.mono-project.com/Mono:Windows and it seems the cygwin toolchain might be your best bet. I don't think you're going to be able to avoid makefiles, sadly. I found a slightly more explicit tutorial from O'Reilly.
#modesty: Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. -- From the Mono site.
Eclipse plugin for Mono is dead. On Linux use MonoDevelop or X-Develop if you like good commercial support (although MonoDevelop is closing on them fast feature-wise). On Windows SharpDevelop has custom MSBuild targets for compiling the code against Mono.
As Mono and MonoDevelop are changing fast, be sure to use the latest released versions, even if they are not marked as stable yet (e.g. versions shipped with stock Ubuntu are terribly outdated).
The VMWare image is a great way to start testing Windows-developed code on Linux. Don't touch cygwin unless you are already very conformable with it.
I liked the idea of trying to use MonoDevelop mostly just to make sure my stuff would work against the Mono runtimes. I guess it would also be possible to get crazy with msbuild and write some custom targets that tried to build against Mono, but that's basically emulating the now-defunct plug-in's functionality which I assume was non-trivial to build. I do have minor experience with cygwin, and I am happy typing "configure" and "make" all day long, but when a problem occurs in that process, I'm virtually screwed. I'll probably try to play with all this again, but if it takes me more than a couple hours to come up with a way to build comfortably against the Mono runtimes, I'll probably just bail.
I will try the Eclipse idea. I use that for Java, so I might be able to get the c# stuff to work. We shall see...