When we try to debug application on device (iPhone 5) get error
MT2002: Failed to resolve "System.Linq.Expressions.BlockExpression System.Linq.Expressions.Expression::Block(System.Type,System.Collections.Generic.IEnumerable`1)"
This bug marked as solved don't help us.
https://bugzilla.xamarin.com/show_bug.cgi?id=14765
There are a few things to consider if you use, even indirectly, System.Linq.Expressions (SLE).
This requires code generation and that's not something possible under iOS. This feature is not supported on Xamarin.iOS. SLE is part of the Dynamic Language Runtime (DLR);
There is partial support for SLE using an interpreter. That has been shipped with Xamarin.iOS for long time - but it only provide a subset of the features. Sadly the existing API is not 100% identical to the one used by MS and it can
cause issues when building (e.g. using PCL assemblies). This is why you're getting those MT2002 errors (your assembly tries to override an non-existing member).
A maintenance release of Xamarin.iOS (7.2.1+) includes a better (more features) and API-compatible SLE interpreter.
You need to change your Linq statement that is causing this. I faced this problem once (I was using a third party DB), Unfortunately the actual devices don't support JIT but the simulator does. Do your Linq statement differently.
Related
Following the instructions on the PlayN wiki I was able to get the "hello" PlayN sample running on the iOS simulator. However, when using MonoStudio, I was told that I need to upgrade to an Indie license or higher to compile the code. (Apparently I was using 33+ features which required it.) When I activated a trial edition, the sample compiled and ran fine on the simulator.
The PlayN wiki seems to indicate the you'd only need a license if you plan on testing on a real device. Is it wrong or am I missing something?
Also, I thought the idea behind PlayN was to build a free, open source game engine on top of free, open-source technology. Mono is both, but MonoTouch is neither. Is there another option or am I stuck with shelling out $1000/year to use iOS (which so far seems far from fully implemented on the PlayN side of things)?
Right now, there isn't. Sorry its disappointing, but its the nature of iOS. Its a very non-free platform.
Perhaps you can try your hands at writing a cross compiler, and release it under an opensource license? You can try basing it on http://gcc.gnu.org/java/.
I am trying to build a cross platform application. Currently I am setting up a project using Xamarin MonoDroid 4.7 and MVVMCross. I would like to be able to use INotifyDataErrorInfo but I get the following compilation error:
The type 'System.ComponentModel.INotifyDataErrorInfo' exists in both 'c:\Program Files(x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\System.dll' and 'c:\Users\MvvmCross.PortableSupport.3.0.6\lib\MonoAndroid16\System.Windows.dll
Has anyone come across this/developed a workaround or solution?
Thanks
We think Mono for Android/Xamarin.Android has recently added this support - but the situation isn't clear - see https://bugzilla.xamarin.com/show_bug.cgi?id=5340
When we get this confirmed and work out which versions do/don't have this - which is hopefully in the coming week or two - then MvvmCross will hopefully be able to remove its version.
Also, I hope but I don't know that the MvvmCross versions of System.Windows, System.Net, etc can be removed in the near future - see https://bugzilla.xamarin.com/show_bug.cgi?id=8035
This is not at all clear at present, and it's likely to be a source of issues while PCL support from Xamarin moves through none->alpha->beta->stable
I'm afraid those 'NEW' bugzilla issues above represent all the information I have on this at present.
In the meantime... if you need to resolve the INotifyDataErrorInfo within your own project and environment, then one route forwards is to branch the MvvmCross source and to change the MvvmCross shim System.Windows.dll to type forward instead of replacing this type - the code is in https://github.com/slodge/MvvmCross/tree/v3/PortableSupport/System.Windows
I am sorry about these problems... and I'm very much looking forwards to having official PCL support from Xamarin so I no longer have to work around them.
I have read an article from Xamarin, and came across a particular computer science word : Ahead of Time.
According to some google search result, this AOT does not allow for code generation during run time.
Does it mean, it does not support dynamic stuff?
I know this question may stupid and I have 0 knowledge in IOS, hopefully can get some answer from here. thanks
First, what is the definition of dynamic? For the general public, dynamic code mean the application can change functionality at run-time. For the iOS platform, the binaries are signed to prevent malware. And Apple don't like apps that can load functionality at run-time.
An ahead-of-time (AOT) compiler has nothing to do with dynamic code per se. It's has to do with intermediate language that are just-in-time compilation (JIT). The biggest example of intermediate language is Java bytecode; compile once, run anywhere. When a Java application is executing, the compiled code is JIT to native machine code. AOT compiler is just doing it ahead of time, to save time.
For the iOS platform, Xcode compiles Objective-C to a native binary for the device.
Another way of looking at this is with an example...
In .Net, you can use the Reflection.Emit namespace to generate and compile code at runtime.
Eg you could create an "IDE" with a textbox that accepts C#. When you click a button that C# could be compiled by the .Net framework into a custom library that's loaded dynamically or a fully-fledged executable which is launched as a new process.
This is insanely powerful when combined with the rest of the System.Reflection namespace. You can examine objects at runtime and compile custom code based on any criteria you like.
That said... The problems usually outweigh the benefits in most cases. Mainly, it's a massive security issue, especially when running on a consumer device.
It would be possible to create an app that wouldn't have anything close to malicious code, get it audited by apple, then have the app download code from your webserver, compile it, and execute it. This new code wouldn't be audited...
There really is no good reason to be doing this in a consumer app.
Is there any migration analysers available for MonoTouch ?
I have seen one for Mono, but not for MonoTouch.
Short answer: No, there is none at the moment.
Long answer
The situation is a bit different from Mono. In general you test a complete and compiled (against a specific version of the framework) .NET application with MoMA, to get a report of what pieces are missing (or incomplete) in Mono that could affect the execution of your application on other platforms (e.g. OSX and Linux).
Testing a complete applications for MonoTouch would reports tons of issues - since the UI toolkit is totally different. E.g. anything about System.Windows.Forms, WPF... would always missing.
However if your assemblies are already split into (something like) an MVC design it would be possible to test some (the non-UI parts) of them against definitions based on the MonoTouch base class library.
Finally if someone has an immediate need (or looking for a nice project) MoMA is available as open source and the evaluation versions of MonoTouch contains all the assemblies needed to build the definitions files. A bit of extra filtering could make this into a very nice tool.
Alternative
You can see a list of the assemblies that are part of MonoTouch and some platform restrictions (compared to .NET) you should be aware.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/