I hear the mono project (for allowing .net apps to run on many O/Ss) has come a long way (Winforms support, etc.)
Does it (or are there plans for it to) support porting to the iPad?
Yes, but it does not appear to be free (or cheap): MonoTouch
Related
We are using some old open-source .Net Framework libraries that depend on things that are not in .Net Core. Can Mono be used to fill in the rest of .Net Framework?
Specifically I'm thinking of creating a Universal Windows class library that includes everything in Mono (excluding some of the System namespace) that changes the namespaces from System.* to MonoSupport.System.*.
Of course, better approaches would be to re-write the library's code, use a different library, or be more selective in taking things from Mono. I was hoping to do this as a temporary measure.
(I want to use iTextSharpLGPL but it uses XmlTextReader, streams with .Close(), System.Security.Cryptography, etc.. The pay version of the library does not support UWP either.)
Edit: I gave up on this and rewrote my app to use Apitron. That worked great until I tried to deploy and found out they don't support .NET Native. I'm now waiting for some library to support PDF generation on UWP.
I do not think so. The following immediate reasons
Mono is a clone of the .NET Framework and therefore based on mscorlib ideas, while UWP is based on System.Runtime. Would require significant extra effort.
UWP apps - when released - are based on the .NET Native runtime. This runtime enforces some patterns in the library implementations (e.g. no reflection, no C++ implementation of types etc). Mono is also strong in AOT, but I think there are dragons.
Mono is a bad choice. Better is the microsoft referencesource for the .NET Framework as published on github.
The time you will invest in your plan will be so significant high, it is much better invested fixing it in corefx directly and wait for the next release of UWP to contain your fixes.
For your problem I would urgently recommend you to fix the problem as a submission upstream at iTextSharpLGPL by surfacing new methods and removing of close or maybe by just copying the MIT licensed XmlTtextReader. But I highly recommend you, not to mess around with crypto ;)
I am upgrading a Win8 application to UWP. .NET Native is causing a huge amount of issues, and a lot of WCF features that the application uses aren't supported.
Is .NET Native required for UWP applications? Can I just disable .NET Native in the Release build? Apart from some potential .NET Native performance improvements, will I lose anything?
The point is you are migrating to the .NETCore for the UWP, the subset of the .net framework, that leads to lots of your original codes can't fit into.
Are you migrating from a winRT store application or full .net framework based desktop app?
So far as I know the .NET CORE really cut-off lots of stuff from the Full. So if migrating from a Full .net desktop, that's really suffer.
.NET is supposed to increase performance, however it may create serious troubles, in some cases, e.g. if application extensively uses marshalling.
You can disable .NET native for Release in project properties.
Open Project Properties and select Build tab.
Set
Configuration: Release
Platform: All platforms
Untick box 'Compile with .NET native tool chain'
After you build the project, allow to run Certification Kit (WACK), and if is passes, take my congratulations. (I am not that lucky!)
Perhaps my question is totally naiive and this is the reason why I couldn't find any information with Google or something else - but nonetheless, I think it is worth asking here.
I want to develop a C# application which behaves naturally in Mac and Windows (Linux would also be nice, but is not directly needed). My main operating system for development should be Mac OS X and therefore I want to go with MonoDevelop.
I can setup a project for MonoMac - works fine.
I can setup a different project for GTK# - works fine.
My question is now, what I have to do to get a project with a possibility for a MonoMac and a GTK#-frontend. So I will go with the MVC pattern and want to work in one project. As a result, building my project would result in a Mac executable (based on the MonoMac stuff) and one windows executable (based on GTK#).
Am I completely wrong with my approach?
What do I have to do to achieve my goal?
Yes, for a multi-platform app with the best possible look-n-feel on each platform, you would need one executable per platform. Using an MVC approach is the best way to do this - you can have a solution containing a library project with all the shared code - models, processing code, business logic, etc - and a project for each "frontend" executable containing the platform-specific views and shell.
If a really good native experience on Windows is higher priority than Linux support, I'd recommend using WPF or Windows Forms instead of GTK#. This would mean you'd have to split development between Windows and MacOS - you would need to open the same project in Visual Studio, SharpDevelop or MonoDevelop on Windows, and edit the WPF/WinForms project and the shared library there.
OTOH, GTK# has the advantage you could start off writing a single frontend that would work on all three platforms, and then write the platform-specific ones afterwards.
I originally assumed that Metro style apps were managed (.NET) assemblies whether they are written in C# or C++ and I thought C++ for Metro style apps would be similar in concept to C++/CLI.
However, I now heard on a DotNet Rocks podcast that Metro style apps written in C++ are native. Nevertheless I understand that Metro style apps run on all three CPU architectures Metro is available for. How is this accomplished? Do Metro style apps come with different binaries and only one is chosen/downloaded? Or is it like on Mac OS X where one binary can contain code for different CPUs?
Code that uses only system or OS services from WinRT can be used
within an app and distributed through the Windows Store for both WOA
and x86/64.
from this MSDN blog page
If you go watch this BUILD video things should start to clear up -- http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C (A .NET developer's view of Windows 8 app development)
Basically there is a CLR (.NET 4.5) running. I didn't say a full CLR. WinRT from a .NET perspective is just a .NET Profile (sort of a way that they can layout the API differently exposing or hiding things). The new WinRT APIs use a new version of [gulp] COM, but it is optimized for use with .NET. I'm not 100% sure on the C++ angle. I suspect with C++, you have a few options. Compile for each platform (arm and x86) or compile to IL. Not sure if this helps you at all (I hope so).
Is there any way to develop for MonoTouch using VB.NET, rather than C#?
Currently Visual Basic is not supported in MonoTouch, but we plan on adding this to the mix in the future, as well as expanding our language support.
The reason for our lack of support is that in addition to shipping the VB compiler, we have to ship templates and we have to port the VB runtime which currently has many dependencies on desktop features of .NET and Mono.
Currently, C# is the only supported language in Monotouch. Also, Monotouch apps are not your average managed .net assemblies. Monotouch C# code is compiled to native code (similar to Vala)
I don't expect to see VB.Net in Monotouch in the near future - as of now, Miguel and his gang is busy with Monodroid & the Mono framework proper. According to their roadmap, they do have plans to support VB.net in the future. No time-frame has been mentioned.