I am getting this exception when I process a WCF request from my Xamarin.Forms app:
"Attempting to JIT compile method '(wrapper runtime-invoke) :runtime_invoke_bool_Nullable`1 (object,intptr,intptr,intptr)' while running with --aot-only.
See http://docs.xamarin.com/ios/about/limitations for more information.\n"
Please, how could I fix this? I have checked the server side but it seems ok.
The rest of WCF requests are working fine and this only happens in devices (not in simulator).
This is happening only in iOS, in Android it works fine.
Thanks.
iOS does not allow dynamic code generation / JIT'ing, everything must be AOT compiled... An Apple security restriction for all apps, JIT'ing within their own Nitro JavaScript engine is an exception to that rule.
Xamarin explains it very well in the link that is provided via the exception:
No Dynamic Code Generation
Since the iPhone's kernel prevents an
application from generating code dynamically Mono on the iPhone does
not support any form of dynamic code generation. These include:
The System.Reflection.Emit is not available.
No support for System.Runtime.Remoting.
No support for creating types dynamically (no
Type.GetType ("MyType`1")), although looking up existing types
(Type.GetType ("System.String") for example, works just fine).
Reverse callbacks must be registered with the runtime at compile time.
Ref: http://developer.xamarin.com/guides/ios/advanced_topics/limitations/#No_Dynamic_Code_Generation
Related
As far as I understand, applications built with Xamarin deploy in every application a mono runtime that works beside the ART, communicating between each other.
Knowing the current android limitations that starting API-28 you cannot start binaries, I was wondering how actually the runtime gets started?
This is briefly described in the Xamarin docs here: https://learn.microsoft.com/en-us/xamarin/android/internals/architecture#application-startup
If you take a look at the build output of your app in obj/Debug/android/src/mono you will notice a couple of java files.
MonoRuntimeProvider.java
This creates a ContentProvider, which is responsible for launching the mono runtime and starting your App.
MonoPackageManager_Resources.java
This class is called by the MonoRuntimeProvider, which is a helper class to find the Assembly containing your App.
The MonoRuntimeProvider is registered in the AndroidManifest.xml in the Application tag. Which means that when your App starts, the Content provider will also start, and in turn starts the Mono Runtime.
At build time Android Callable Wrappers (ACW) are generated for your Activities (and many other types as well). This is a way to invoke managed (C# code) from the Android world.
If you try to decompile your App, you will see that in the constructor of such ACW's there is a call to the mono runtime register and activate the managed type.
As for the limitations in API-28, I don't see anywhere in the docs where they mention anything about not being able to start binaries.
There are some Restrictions on non-SDK interfaces. If it was the case that you were not able to consume binaries in your Android App it would mean that all Apps consuming C/C++ NDK libraries would be broken.
There has been some limitations to where you can access such libraries. In the past you would be able to use some binaries outside of your Applications scope, which were bundled with Android, this is not allowed anymore and you need to bundle this with your App yourself.
The most fundamental feature of Nativescript is that it converts different platforms' languages and API:s into Javascript (or another given single language e.g. C#), e.g. for iPhone it's the Objective C language and the iOS API:s, and for Android phones it's the Java language and the Android API:s.
Nativescript's "build-time reflection to Javascript proxy" is central here.
Reading through various "Nativescript vs. whatever" pages online, it's clear to me that the authors of those pages not really discuss that exact aspect, so those articles cannot be used to get an overview of that situation at all.
Therefore I want to ask you here:
What projects out there are there that provide that fundamental feature - a language+API binding from different smartphone (and possibly desktop) platforms, to Javascript (or another single language such as C#)?
ALL WebView/HTML rendered UI-based solutions are DISQUALIFIED here. Only native UI component solutions qualify. Do feel free to list the DISQUALIFIED solutions also, for everyone's reference, and mark out carefully that it is disqualified.
Hence I understand that Apache Cordova (https://cordova.apache.org/docs/en/latest/guide/overview/) is DISQUALIFIED.
I prefer Javascript, however let's enumerate all projects independent of which language is used at the unification layer, therefore Xamarin is qualified in this thread.
Also for those respective qualified solutions, are they really as holistic / complete as Nativescript is, in support, or how do they compare?
For the respective solution, do they also provide an runtime that integrates the underlying different UI API:s into one single coherent UI API that spans the multiple platforms? (For Xamarin I understand the answer to this question is NO - different code is needed for the different platforms.)
Also what are their primary difference in approach?
Some names I picked up that could be qualified, are "React Native", "Appcelerator Titanium", and "Electron" (https://electron.atom.io/).
This question is important for any app creator or startup, like me, that will rely on the solution a lot, and also hopefully contribute a lot, so it's a long term choice.
So, for each relevant solution I want:
* NAME, URL: Its name, with URL
* DISQUALIFIED?: Disqualified or not
* AUTO-REFLECTION: Has automatic build-time reflection or not, any details
* LANGUAGE: Unifying language (e.g. Javascript)
* UNIFIED UI CODE: UI code same between platforms
* PLATFORMS: Platforms supported
* CODE TRANSFORMATIONS: Any notes about how the app sourcecode is managed, e.g. is it run as Javascript on the device, is any code transformation applied to the Javascript code (e.g. to parse out custom tags which are actually not in themselves valid Javascript), any kind of compilation applied on the Javascript, etc.
Please let me know.
This is extremely valuable for overview.
Thanks again to Telerik and the Nativescript team for making this fantastic tech!!
Mobile:
Cordova/PhoneGap/Ionic - https://cordova.apache.org/ - Disqualified - Unified UI - JS/HTML/CSS - Basically a wrapped webview with the ability to make native bindings that you can call from it. In once sense you access the native platform via plugins you create. In fact Microsoft has a project called Project Ace https://microsoft.github.io/ace/ which allows you access to the Native API inside your Cordova/Phonegap application. The application code is running inside a webview; and everything is thunked out to the OS and plugins that you build into your app. Despite the "marketing" speak (ionic is really bad about attempting to confuse the market here); Cordova/PhoneGap/Ionic is NOT truly a native application. It might use some native controls, but the engine is running in a webview.
Flutter - https://flutter.io/ - Disqualified - Unified UI - Dart - This is another interesting entry in the market; it is fully compiled code on all the platforms, so it is can be more performant than JS based engines. In addition it was written to be a very performant UI (separate thread for UI). To access the native api's on the platforms, you need to create plugins with the interface the compiled dart will be expecting and the iOS or Android API's.
Fuse - https://www.fusetools.com/ - Disqualified - Unified UI - JS - This is a interesting project; it actually compiles the markup into compiled code. I believe the JS engine is running on its own thread and the Fuse runtimes handle the GUI thread. To my knowledge all thunking/reflection has to be done via plugins.
NativeScript - https://www.nativescript.org - Qualified - Unified UI - JS/XML/CSS - Uses the same markup language for screen layout on both devices, has its own builtin system to marshal calls into the OS on both platforms. No extra plugins needed to access any API resource, everything on iOS and Android is accessible from plain JavaScript. Runs a Javascript engine on the Main thread of the Application, which can cause performance issues if you make the main thread busy. Because of its design it can re-use pretty much all Android AAR/JAR plugins and iOS cocoapod plugins unmodified, bringing a wealth of Native controls that you normally would only get to use if you were using ObjC/Swift/Java. It also is the only one that has zero day access to new API's because reflection is resolved at runtime.
React Native - http://www.reactnative.com/ - Disqualified - Unified UI - JS - It is also a JavaScript engine based system, but it has no built in reflection. Pretty much all access to the device API's needs to be ran through compiled plugins that give access to the native api's. One thing to note is that this JS engine runs on its own thread and the main thread is reserved for the GUI. This can make apps be more performant out of the box as anything blocking will occur on a separate thread, but makes GUI related plugins much harder to do.
Xamarin - https://www.xamarin.com/ - Qualified - ??? - C# - It has sorta built in reflection. When they release the new versions they basically create a thunking library with the current reflections. So when new versions of the OS comes out, they have to regenerate the C# thunkings before you can use it. Application is compiled on iOS, on Android I believe it is using Mono to run the app. So you cannot do certain things at runtime on iOS, like eval('console.log("hi"); /* even more JS code */') as you can on the JS based engines.
Desktop:
Electron - https://electron.atom.io/ - Unqualified - Unified UI - HTML/CSS/JS - This is a desktop based environment that merges node and chrome. So you can access any of the Node api (which is pretty large) and any of the chrome api and create an application. However, anything lower level you will need to create a plugin.
NW - https://nwjs.io/ - Unqualified - Unified UI - HTML/CSS/JS - Basically the same notes as Electron.
A couple notes:
All JavaScript based engines DO NOT compile the code; they all run the JavaScript code at runtime.
You can use Cordova/PhoneGap/ionic to share an app between desktop (using electron/nw), web and mobile fairly easily. But it is still a web app on all platforms.
You can also use NativeScript with Angular to create app that shares probably 98% of its code base between a mobile, web, and desktop(electron/nw) application. Basically the only differences in some applications is just the screen layout as you need div/input tags for Web, and StackLayout/TextInput for the Mobile side. But the rest of the code and logic can be generic and access the elements as normal.
I'm trying to rewrite IL code dynamically at runtime. While this is quite well documented for .NET framework applications by using the Profiling API I can't find anything similar for UWP applications.
Because I have a suite of automated function tests, I need to setup the profiling environment and start a sample app programmatically.
Attempt 1
This question explains how to enable a debugger (as far as I understand a profiler is essentially a debugger) and programmatically start a UWP app.
So from my bootstrapper I call IPackageDebugSettings::EnableDebugging followed by IApplicationActivationManager::ActivateApplication.
Anyway I can't figure out how to implement the debugger. The debugger (which is an executable) is called with the following arguments:
-p 3836 -tid 6180
Both numbers change on every run. While p seems to be the process id of the debugged process, I have no idea what tid could be or how I have to use the arguments to control the debugged app (register for module load events, trigger rejits etc.).
Attempt 2
I found this issue on the Core CLR repo which is about enabling the Profiling API for Core CLR apps. The issue contains a link to a sample profiler repo.
So profiling for Core CLR apps seems to basically work the same way as it does in .NET framework apps (with some restrictions). From my bootstrapper I tried to set the appropriate environment variables (i.e. CORECLR_ENABLE_PROFILING, CORECLR_PROFILER and CORECLR_PROFILER_PATH) followed by IApplicationActivationManager::ActivateApplication.
However the profiler doesn't attach.
I'm quite sure that in general it is possible to profile UWP applications because JetBrains' dotTrace can do it.
Any ideas?
I need to create a application which would take the preference of the user when starting the application for the first time and then the appropriate module would be downloaded for the application. Is it possible using xamarin.forms?
Currently we are using xamarin.forms PCL project and creating app for android and iOS using xamarin.forms.
I don't see why not, though you'd likely be tied to Android. Dynamic execution on iOS is not supported, and I'm not sure about Windows. It should be an easy enough test: click a button, download an assembly from somewhere, dynamically load it, then instantiate a class that implements an interface you're looking for. I've been wanting to do a blog post on this very thing, but alas...
Another option which may be iOS compatible is having some code in JavaScript, then download and run it in a WebView. Though that may be more trouble than it's worth.
I am talking about a small game engine using C# for game programming.
So, I have a C++ app embedding mono runtime (I call it 'launcher'). And I have an assembly written in C# which is my game engine class library. The launcher launches the assembly as it is suggested in Embedding Mono.
And now the interesting part!
The launcher implements in C++ miscelaneous functions which are exposed to the mono runtime as internal methods of my game engine classes. That is why my game engine assembly is nothing without the launcher which implements a huge part of the engine in C++.
The question: How am I supposed to debug my C# assembly? And what is more important, how am I supposed to debug a Game which I am going to write in C# ???
As you understand I cannot debug the assembly using MonoDevelop Debugger because it won't receive internal C++ implementations of some of its methods.
What I need is to run the Launcher. The launcher then will launch C# assembly using embedded mono runtime. And then I need something to connect to the launched assembly to allow its debugging.
Or any other way. Thank you!
I recommend using the Mono Soft Debugger. It's been included in the Mono runtime since Mono 2.6, and is more reliable than the old hard debugger, and also much more portable.
The Mono soft debugger can be started by passing options using the --debugger-agent commandline argument to the Mono runtime. This can be done from an embedding host by constructing a fake set of commandline arguments and passing it to mono_jit_parse_options. For example, the Moonlight browser plugin uses the debugger agent values from MOON_SOFT_DEBUG environment variable if it is set.
Typically debugger options are something like
--debugger-agent="transport=dt_socket,address=$ADDRESS:$PORT"
which will cause the app to try to connect to debugger listening on the given address, and pause until it establishes a connection. Note that the connection is established over TCP/IP, which means remote debugging is very easy to set up, and even on the local machine you would use localhost. Additional options are documented on Mono's man page.
The other piece you need is the debugger GUI/controller, to listen for the connection from your app, and handle stepping/visualizing, etc. I would suggest using MonoDevelop. There's a library for the debugger wire protocol called Mono.Debugger.Soft.dll, but it's fairly low-level, and although Mono Tools for Visual Studio supports connecting to the soft debugger, it's not yet extensible in a way that would allow debugging Mono embedding hosts.
Using MonoDevelop to accept debugger connections from embedding hosts currently requires creating an addin, but this is fairly straightforward. Take a look at the Moonlight debugger addin for an example. For simple use cases I would suggest that you don't define a whole new project type but just create a debug handler that handles existing DotNetExecutionCommand projects, so you can run->run with...->your custom debugger.
The monodevelop-list mailing list is a good resource if you have more questions.
Make use of network debugging.
You could use the Soft Debugger to debug the Mono parts, and then use remote debugging for the C++ parts.