I heard about Mono project but only in regards to winforms. Will it work with WPF?
WPF under Mono does not exist.
At this point, no group in the Mono project has plans to implement Windows Presentation Foundation APIs as part of the project.
The mono team propose using Silverlight/Moonlight instead:
Silverlight implement a subset of the WPF APIs and is available on Windows, MacOS X and through our own open source effort Moonlight it is available on Linux and other Unix systems.
There is a library called Silverform SDK that aims to provide cross-platform WPF and Silverlight implementation.
The library is implemented in managed code and currently works with OpenTK and Unity3D as render backends. Major functionality, such as binding, layout, main controls and primitives, has already been implemented (check Unity web player demos here). Initially it has been focused on Unity3d render, while support for standalone Mono applications will be added as a separate build in the future.
Disclaimer: I am one of the developers of the library.
Related
I have an existing application written in C# for .NET 6 that renders OpenGL with the lightweight OpenTK (v4) OpenGL bindings, which support .NET 5+, Open GL 3+, and OpenGL ES 2+.
According to the OpenTK FAQ:
OpenTK runs on Windows, Linux, and MacOS X.
(Older versions of OpenTK supported Android and iOS as well; current OpenTK might work on these, but it’s untested.)
I am excited by .NET 6's promise of one unified platform, but I have only seen cross-platform mobile projects that use Microsoft's new .NET Multi-platform App UI (.NET MAUI) framework. MAUI appears to be a web view shell that contains a Blazor Web App. I found the code for this shell in the src/Core/AndroidNative folder of the repository, but it seems very bloated for my purposes. I want to be able to access Android-specific functions without the bloat of Blazor and a web view. According to this blog post, Xamarin.Android might be the answer, but I am not sure how to introduce it into my existing project.
All I need is a simple shell that:
Creates an Activity with a GLSurfaceView
Obtains an OpenGL ES 2 context
Runs my current C# code with that context
I would prefer the shell to be in C#, since introducing Java code would complicate my build process and fragment my code base.
How can I introduce the needed Android-specific code?
How will this change my build process?
I know that I need to write OpenGL ES-compatible shaders and that I probably need to change how I save files. What other changes will I need to make to my current code to ensure Android compatibility?
I've been 2 years with Xamarin Environment and mostly I used Xamarin.Forms. But yet, I have no idea what Xamarin Cross Platform is? Can anyone provide some structural differences?
When we talk about Xamarin there are two approaches in development of native apps:
Traditional Xamarin approach
Xamarin.Forms
There is a good quote from Xamarin web site
Share code everywhere. Use the same language, APIs and data structures
to share an average of 75% of app code across all mobile development
platforms. Build user interfaces with Xamarin.Forms and share nearly
100%.
Important note is that these numbers can vary from project to project so this is some assumption for general usage of Xamarin.
And as you can see from the image below about "differences" between these two approaches. Traditional Xamarin approach (Xamarin.iOS and Xamarin.Android) they’re both built on top of Mono, an open-source version of the .NET Framework. To develop those apps you use C# and there is an opportunity to share up to 75% of the codebase as you can see on the image bellow and from a quote from Xamarin.
Using Xamarin Traditional approach you can use a C# as a programming language to write your models, call web services, etc. So you are writing that code logic once and using/share it across the Xamarin.Android and Xamarin.iOS projects, and in those separate projects you are writing code that is specific for that platform and you have access to their APIs.
Also, there is a quote from Xamarin about the traditional approach:
Anything you can do in Objective-C, Swift, or Java can be done in C#
with Xamarin using Visual Studio.
And project structure with Xamarin traditional looks like this:
Shared code project: Codebase that is common and reusable for your other projects.
Xamarin.Android: Project for your Android app where you are writing code using Android-specific APIs, writing your UI code, etc.
Xamarin.iOS: Project for your iOS app where you are writing code
using iOS specific APIs, writing your UI code, etc.
More info about Xamarin traditional here.
Now about Xamarin.Forms, the best definition is quoted from the Xamarin website:
Xamarin.Forms is a framework that allows developers to rapidly create
cross-platform user interfaces. It provides it's own abstraction for
the user interface that will be rendered using native controls on iOS,
Android, Windows, or Windows Phone. This means that applications can
share a large portion of their user interface code and still retain
the native look and feel of the target platform.
As you can conclude from the text above, Xamarin.Forms is a framework that allows you to write your UI using C# or with XAML with the opportunity to use MVVM... With Xamarin.Forms you can write your codebase and your UI which will be shared across the platforms.
Note: this is a very simple project structure, of course, you can add more project for different layers
Shared code project: Holds your common code base and also because you are using Xamarin.Forms you can write code for your UI
Xamarin.iOS and Xamarin.Android: Code for that specific platform, and some advanced topics such as Custom renderers and Dependency services.
Of course, there is some of the limitations if you are using Xamarin.Forms for example out of the box you can only use UI controls that are common across all platforms. You can read my blog post about Xamarin.Forms pros and cons here.
More info about Xamarin.Forms here.
I hope that this answer is not confusing for you and as a conclusion in one or two sentences... Using Xamarin Traditional you can share your code logic between platform-specific projects, and using Xamarin.Forms you can share code logic and also code for UI across your projects.
Note: For shared project and code sharing strategy you can use "Shared Project" and "PCL" this is a topic for another question... so in this answer, I was simplifying this and use shared project term for that type of project in Xamarin app solution.
UPDATE, Summer of 2020:
.NET Maui is announced in May of 2020, the question about the difference between MAUI and Xamarin.Forms could be found in the StackOverflow thread here: What is MAUI? and what are differences between MAUI and Xamarin
If you're talking about the Xamarin.iOS and Xamarin.Android (Xamarin Native), I'd say the main difference is that in Xamarin Forms, you share NOT ONLY the business logic, but also the UI. In Xamarin forms, you'll use basic components on all platforms (Button, Label, etc). That's the reason why it's called Xamarin.Forms, because it's suitable for basic forms.
But for Xamarin Native, you'll create a UI per platform (One for iOS, one for Android). You can do much more with Xamarin Native, because you'll use native components.
Hope it helps!
Xamarin has two ways of building mobile applications, Xamarin.Forms and Xamarin.Native.
Both ways let you write code cross platform.
Cross platform is just a concept. It means the code you write once can run in multiple platforms. Xamarin is cross platform (mainly Xamarin.Forms) because it allows you to write code that runs on multiple (across) platforms.
I think Xamarin Cross Platform refers to the technology that compiles shared code (your PCL or Shared Project) such that it can be used by the different platforms such as Xamarin.Android or Xamarin.IOS before finally being compiled to the native platforms.
So I'd say in a way Xamarin.Forms is one of the tools you use to build cross platform compatible code that can then be put together using the Xamarin Cross Platform Technology, makes sense?
We're developing very similar applications for Windows and Android using Xamarin platform and C#. Both will incorporate some on-screen and off-screen 3D rendering, such as 3D mesh visualization.
We'd like to implement this as cross-platform as possible. How is this usually done in Xamarin? Is it better to do rendering in C++ code, or is there a C# wrapper with abstractions over platform-specific context creation etc.?
After some time I can answer my own question.
At least in my case it turned out to be more convenient to use OpenGL from C++. We just built a shared library from C++ code and link it to .NET dll's using DllImport.
Our tool for building C++ libraries is CMake, however you can use other build systems, such as new features of VS2015.
One particular benefit of this solution is that you can reuse this code anywhere else: in iOS application, desktop application for Windows, Mac, Linux, etc.
why can't I use regular class libraries in XBox360 games?
I have application logic which I want to keep independent from XNA and use in both WPF and XNA applications.
Does anyone know good practice to share code between XBox/Phone7 applications and "regular" windows applications?
Have a look at Portable Class Libraries: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Using the Portable Class Library
project, you can build portable
assemblies that work without
modification on the .NET Framework,
Silverlight, Windows Phone 7, or XNA
(Xbox) platforms. Without the Portable
Class Library project, you must target
a single platform and then manually
rework the class library for other
platforms. The Portable Class Library
project supports a subset of
assemblies from these platforms, and
provides a Visual Studio template that
makes it possible to build assemblies
that run without modification on these
platforms.
Edit: Check out JoDG's answer for a nicer solution.
You could try linked files...
In your Xbox project, right-click -> Add Existing File, then after selecting the file(s), click the little drop-down arrow on the "Add" button and click "Add As Link", as shown here:
This might not work if you need to share more than just files, but it's an easy way to share code.
JoDG's answer is probably the most practically useful. But just to provide additional information:
why can't I use regular class libraries in XBox360 games?
Because the different XNA platforms target different versions of the .NET framework.
XNA Game Studio itself provides a mechanism (documented here and more info here) for automatically mirroring the source files of a project between two projects. This mechanism can be used for creating copies of your library projects for each platform, as well as for your game projects.
For XNA-related work, this is the preferred method for creating cross-platform libraries. When you have to also make your library work on WPF you have to take additional steps:
On Windows, an XNA game is just like any other .NET application, and a XNA library for Windows is just like any other .NET library. Except for the fact that they reference XNA assemblies. So your WPF application can reference a Windows version of your XNA library. But if you want your application to work on systems without XNA installed, you need to remove the XNA assembly references from the Windows project for that XNA library.
XNA Game Studio will still mirror changes between the Windows library and the Xbox 360 library for you.
I know WPF libraries aren´t implemented by mono class library, however(as far as I know) the mono 2.6 runtime is fully compatible with the .NET 2.0/3.5 runtime, so if the WPF libraries only make PInvoke calls to windows api it is theoretically possible to run a wpf application on windows using the mono runtime.
The reason for wanting that is deploying a wpf application as a standalone executable for windows. Has anyone tried something like that before? If so, what were the results?
In short... No
At this point, the Mono project does not have plans to implement Windows Presentation Foundation APIs as part of the project
Mono will provide Moonlight support which, from what I understand, would also use a subset of XAML to create its UI (the same as Silverlight does) but there are legal complications involved. Such as, it's limited to non-microsoft and non-mac platforms.
If you want to find a list of open-source cross-platform alternatives to WPF/XAML I'm working to compile a list of viable alternatives.
Well I did give it a try with little success. I first checked with corflags if required dll-s are implemented in mixed mode (PresentationFramework, PresenationCore, WindowsBase, System.Xaml). They are all pure CIL implementations so that should work fine with mono. Next I installed mentioned DLLs into mono's GAC and tried running a very simple WPF application. This is what I got:
Assertion at mini-codegen.c:1186, condition `reginfo [sreg].born_in
0' not met
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
So although in theory this should all work, WPF is probably way to complex to run out of the box on mono, it would be cool if there was a pure CIL implementation of WPF that was compatabile with both mono and .NET Framework.
As much as I know, Mono does not support WPF.
Also, WPF uses graphics modules and interacts directly with the GPU. So I can't see how u can use WPF with no hidden pinvokes.
Sounds like you need to read about WPF architecture to better understand it.
http://msdn.microsoft.com/en-us/library/ms750441.aspx
Many pieces are missing in Mono and solely available in .NET. Therefore, your "theory" is not correct, and you cannot run WPF applications on Mono, even on Windows.
At MIX 2010 Miguel de Icaza said in his session that Mono isn't going to support WPF. Anything tangentially related to WPF-like support is only to provide what is needed for Moonlight.
Not fully, but..
You can use Moonlight 4 ( silverlight 4 ) in a desktop mode:-
https://github.com/inorton/MoonBase - MVVM helpers
https://github.com/inorton/XamlPreviewer - XamlPad clone