we're using https://github.com/firelyteam FHIR library in a Xamaring application.
When testing in iOS we discovered the PlatformNotSupportedException because of the use of Emit.
We then discovered we could use the Xamarin interpreter: https://devblogs.microsoft.com/xamarin/introducing-xamarin-ios-interpreter/
and it just works!
I have some questions/doubts:
is there any difference between the "Enable the mono interpreter" option or adding "--interpreter" to "Additional mtouch arguments"
is it possible to limit the interpreter to specific libraries? I'm under the impression is now globally enabled. I tried with "--interpreter=FHIR.HL7.Support" but I'm not sure it's working: inspecting the .ipa seems to containe .aotdata for everything. I was under the impression that aotdata was not produced when interpreted
can you suggest better solutions?
Thanks a lot
You can use --interpreter=assemblyname,.... to only allow the interpreter to work on just those assemblies, i.e. include the IL in only those assemblies.
Related
I searched through existing Stackoverflow questions related to this problem but didn't find any help to solve it.
So here's the problem:
I am trying to integrate .framework file into the project but it's giving me an error saying that module compiles with 4.0.3 can't be imported by swift 5.0 compiler.
I wanted to know how to compile that.framework file? so that it will become compilable to swift 5.0
Please help if you come across such a problem.
Note: .framework file is created by a third-party developer
If the framework you're trying to integrate is binary only, then your best option is to check with the 3rd party developer regarding their support for Swift 5.0.
In case there are sources available, you can try checking if there is any work being done in their repository (usually a separate branch), or you can try forking the sources yourself.
Note that with the source option, you'll have access to possibly unstable and untested code, and depending on the experience I'd be very careful in this case.
When I am trying to build my ios app in xcode, the build is failing due to lexical or preprocessor issue the error shows up like this
This was a problem specific to the react-native-device-info module.
For your specific case you may try v1.6.1 or higher (currently at 2.0 as of May 21, 2019) of the library and that should fix things for you.
For others interested more generally in the problem, this is a react-native library that uses native code, so it has an XCode project embedded within it for use in react-native after you run react-native link react-native-device-info. Unfortunately, the library was not including any directories in it's header search path, so it was of course unable to find the header files for the react-native objects it was using locally.
A library user proposed a change that fixed that problem for tvOS, and I extended the change to cover iOS as well, and now the library no longer generates errors like this for iOS or tvOS targets.
Perhaps someone with a similar issue may find the specific changes required for the fix useful in their projects
I'm trying to compile a dependent libraries from the source code and I've got this error:
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS9.0.sdk/usr/include/unistd.h:446:8:
note: 'fork' has been explicitly marked unavailable here pid_t
fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
Is there any way to resolve this issue?
The thing is that I don't actually even need this functionality. When I compile this code for iOS and run it under tvOS then it works.
But I can not submit the application because it contains code compiled for iOS.
What would be the good trick to substitute there a dummy fork() function so it compiles OK (believing that it is not actually used by my specific use-cases).
I don't believe there is a way round this. You cannot create processes under iOS and tvOS is 90% iOS, so the same restriction applies.
You'll have to conditionally compile-out that section of code for iOS/tvOS.
I am trying to use protobuf-net with the new xamarin ios pcl, and it's nuget packet doesn't appear to support the framework. Is there a way to import protobuf-net into the pcl?
Update:
I just found recompiling the PCL with the new Xamarin PCL definitions allowed the resulting library to be references. Nice work! Let me know when a new version is posted to Nuget.
The NuGet package includes PCL drops, but it is unclear to me what change you would have me make to the NuGet package here, as there is no specific "Xamarin" target that I know of; the example targets are described here; protobuf-net currently includes a broad target of portable-sl4+net40+wp7+windows8. If you know of a target (or indeed a PCL build combination) that works for Xamarin for iOS, please let me know.
I should also note that the NuGet drop is the "Full" implementation, where meta-programming is performed at runtime. Because of the limitations in iOS, you may find you get better performance by using the "CoreOnly" implementation combined with the "precompile" tool, available from the google-code drop. This is described here.
I was able to use NuGet version of protobuf-net by manually editing the .csproj file for my portable library and setting the target framework profile to match protobuf-net:
<TargetFrameworkProfile>Profile136</TargetFrameworkProfile>
The resulting portable library worked well with Xamarin.Android. According to this list, it should work with Xamarin.iOS as well.
Just curious if MonoTouch has support for "Module Initializers"?
http://blogs.msdn.com/b/junfeng/archive/2005/11/19/494914.aspx
Related question: Does Mono support "Module Initializers"?
Your first link answer, at least half, your own question. The Mono runtime supports Module Initializers and the test done (to prove this) was executed with Mono's JIT.
MonoTouch uses the JIT when executing on the iOS simulator, so there's no reason why it would not work there.
It likely works (or it's a bug) for devices too, i.e. where the AOT compiler is being used. As Jason said, it's a matter of testing it. If you cannot test it yourself simply fill a bug report and attach a (self-contained) test case to it and we'll confirm if it works (or keep the bug open until it does).
From the MSDN article you linked to
Since C# does not support global functions, C# does not support module
initializer.