We have an existing c# library that we would like to re-use in an IOS application. It looks like this is easily done using monotouch IF we are willing to use monotouch for the entire application. However, we would like to use xcode as the primary tool (and thereby obj-c) since we feel that it for our purposes is more 'clean'.
Looking at stackoverflow and xamarin.com, it looks like it was possible in 2009 using 'monotouch --xcode'. Later posts by Miguel indicates that this is no longer supported even though it is still available in monotouch.
I have tried to make a very simple c# assembly and run 'monotouch --xcode=/projectpath myassembly.dll. I can open the project in xcode 4.2, but any attempts to build it fails with 200+ errors "Apple LLVM compiler 3., Invalid instruction mnemonic 'bl'"
Has anyone made this work recently using xcode 4.* and monotouch 5.*?
Related
I have developed a .NET 4.5 application using WinForms. I want my application to run not only on Windows, but also on Linux, so I decided to port it to Mono.
However, I can't find any information on how to use Visual Studio for Mono. I don't want to switch to MonoDevelop, since VS provides much of the functionality I want and I am already familiar with it.
There apparently used to be something called Mono Tools for Visual Studio, which David Lively insists works on current VS editions, but I don't want to run an extension that was deprecated 3 years ago. I don't even know where to download the extension - it redirects to Xamarin, and Xamarin seems like not what I want because while it mentions VS integration, it forces me to install a bunch of Android and Java SDKs (why?).
As far as I can see, .NET and Mono code looks fairly similar, and there are 3 main concerns:
Making VS use the Mono compiler instead of the C# compiler, so I can tell if non-Windows users can compile my source, and also get notified about missing libraries
Making IntelliSense suggest only Mono-supported things
Making the "Run" command run the application using Mono, not .NET, so I can test it correctly
Is there really no easy way of accomplishing these?
Note: I want to develop Windows and Linux desktop apps, with a WinForms GUI or equivalent only. I am not interested in mobile.
In general, you can just target .NET 4.5 and compile with Visual Studio and the resulting assembly works as-is on Mono (assuming you don't use platform-specific stuff via p/invoke, etc).
Mono's WinForms support isn't perfect though (and nobody actively works on it), so you still need to test by running the app directly on Mono. Missing APIs aren't usually the problem, it's more that the Mono implementation has different behavior/bugs.
Another alternative to WinForms might be Xwt.
Developping an MvvmCross application targeting Android and iOS (Xamarin/Mono) and Windows Store (because it's so easy/fast to debug compared to iOS/Android).
The Core of the app is PCL based.
Is it possible to use Async/Await in the Core library?
Xamarin mono supports Async/Await, and Windows Store supports it.
However, when selecting only Net4.5, Windows Store, Mono Android and MonoTouch as the PCL targets, SL4 and WP7.5 get automatically selected and Async/Await is not availlable anymore.
The latest I have is: TPL on PCL of mvvmcross
But PCL support from Xamarin has officially launched in the last week - so the latest I have is be out of date. Miguel has promised a blog post on the current status when he returns from Build.
Also, I have seen user comments like "I'm using asyncbridge and profile47 with heavily usage of async inside PCL. Works perfect on iOs and Android, with MvvmCross events it looks like a magic" from http://forums.xamarin.com/discussion/comment/18872/#Comment_18872 - would love to see this more fully blogged, explained, documented by those who have it working.
I am trying to compile the vNext branch of MvvmCross on a Mac to try & start doing some iOS development using PCL's & MvvMCross.
I have spent a couple of days on this now but appear to be going in circles... being somewhat new to both C# & the Mac.
I have installed MonoDevelop 3.1.1 as recently referred to on #slodge's blog.
I have updated the targets file as per this reference https://files.xamarin.com/~jeff/Microsoft.Portable.CSharp.targets
I have downloaded the vNext branch from GitHub.
I have loaded the mvvmcross_all.sln in MonoDevelop however building it using the Debug|iPhone Simulator profile gives me 3 errors.
I have not been able to work out how to fix the references errors as for example appear in CrossUI.Core, ie references to
System
System.Core
System.Net
etc
Each of these lines has an error of Assembly not available for .NetPortable 4.0 Profile1 Profile (in Mono 2.10.9)
I realise its all a moving target but its obviously possible to get it to compile.
Any suggestions as to what I may have missed would be appreciated.
TIA,
Andreas
Thanks Andreas
In the version referenced in the blog at http://slodge.blogspot.co.uk/2013/02/a-patched-monodevelop-for-pcls.html, it appears that MonoDevelop reports that CrossUI is missing its references - but it still compiles. See this screenshot from my Mac - solution explorer reports problems but 'rebuild all' on CrossUI succeeds.
If you get problems with building, please do report the build output and I'll try to help.
Note that the patched version of MonoDevelop also still has other problems - e.g. syntax highlighting and intellisense issues- MonoTouch: creating multiplatform apps using Portable Class Libraries
Alternatively, there are some iOS/Mac friendly binaries on SkyDrive - http://slodge.blogspot.co.uk/p/mvvmcross-binaries_7.html
The schedule for 'proper' support of Portable Class Libraries is aiming for a demonstrable version before Evolve (so less than 2 months away). Until then I'll personally continue to do most of my PCL work in VS, with the platform specific steps in MonoDevelop.
How would I go about using F# or J# for instance? I'm not sure what to get to grips with in the project's compiler settings.
Is there a sequence of command line steps I could follow to compile a MonoTouch project that I might interpret to replace the C# step but tell the other compiler to use the correct platform details etc?
Thank you.
Unfortunately, no. In the book "Developing C# Apps for iPhone and iPad using MonoTouch" you could see text (proof):
C# Is Currently the Only Language
Additionally, currently, the only .NET language available for writing MonoTouch applications is C#.
Nothing changed since that book publication.
Maxim Korobov is right, MonoDevelop only supports C# when writing for MonoTouch.
But this is not the whole truth: MonoDevelop also has (preliminary) support for Portable Library Projects (PLP). What this means is that you can create and compile PLP projects in Visual Studio (in any language Visual Studio supports for PLP projects), and then reference that library in MonoDevelop. Just have in mind that the PLP support is preliminary right now, and you might run into a few bumps on the way.
Monotouch compiles the app into the native code. How can Apple know that the app was built using MonoTouch? Does Monotouch leaves a signature in the application?
Does Monotouch has its own libraries which could be a trace of the origin or it compiles all the code and all its .NET libraries into native code?
The resulting .app package contains the application binary, your resources as well as the required additional libraries, such as:
montouch.dll;
System.dll;
System.Xml.dll and so on.
As such, it would be trivial for them to check if the application was built with monotouch or not - it is as simple as right clicking the package and then select "Show package contents" in Finder.
However, you need not worry about that, as Apple has just relaxed their License Agreement: http://daringfireball.net/2010/09/app_store_guidelines
And even if the assemblies containing metadata were not included in the app bundle (directory), I am quite sure it is relatively trivial to learn how to recognize from the patterns in the actual code in the app executable that it was produced by MonoTouch, if one would want to. So there is not reason for MonoTouch to try to "hide" that fact.