I currently have an cross platform Xamarin Forms (Android , iOS) and native UWP app , using .net standard 2 as my base line. I can no longer compile my UWP app in release mode as Servicestack uses Reflection.Emit and this is a known "new issue" in UWP compilation and throwing an error. Looking at the issue list in github I can see you guys are also not happy about it and I was hoping MS can roll out a fix in the past 2 months. However it does not look like the fix is forthcoming until .net standard VNext leaving me stranded with ServiceStack that can't compile. As SS and .net standard 2.0 are now fairly deeply rooted in my current platform I dont really want to go back to PCL implementation.
Any ideas ??
Removing the dependency to Reflection.Emit from ServiceStack.Text is not an option, but it wont be used at runtime if
Env.SupportsEmit=false; but we can't do anything if it's a compile-time error.
But compile time errors should be a bug as UWP is meant to support .NET Standard 2.0 and Reflection.Emit has a .NET Standard 1.1 build so there shouldn't be a compile-time error.
I've tried creating a new UWP App and added a reference to v5.1.0 ServiceStack.Client which works at as expected in Debug mode and it does build in Release mode unfortunately it fails at runtime with:
Method 'DynamicMethod..ctor(string, Type, Type, Module, bool)' from assembly 'System.Reflection.Emit.Lightweight' was not included in compilation, but was referenced in ReflectionExtensions.GetConstructorMethodToCache(Type). There may have been a missing assembly, or a dependency on a more recent Windows SDK release.
Which is surprising behavior as it the Exception sounds like the method doesn't exist even though it does and runs fine in
Debug mode. The effect of this looks like just having a method reference existing but not calling it will still cause a runtime exception which leaves very few options.
I've also tried adding rules in UWP's
Default.rd.xml file to avoid any optimizations with:
<Assembly Name="*ServiceStack.Text*" Dynamic="Required All" DoNotInline="true" DoNotOptimize="true"/>
<Assembly Name="*ServiceStack.Client*" Dynamic="Required All" DoNotInline="true" DoNotOptimize="true"/>
<Assembly Name="*ServiceStack.Interfaces*" Dynamic="Required All" DoNotInline="true" DoNotOptimize="true"/>
But that doesn't help either.
So I'm out of solutions. Creating fork of ServiceStack.Text without any references to Reflection.Emit could work but that's not an option for us so we're back to waiting for UWP to add better support for UWP, at least if it had empty stubs that throws a runtime
PlatformNotSupportedException will help as we can handle it at rutnime where it shouldn't fail if you're not calling unsupported methods.
Hi mythz ,
I was hoping mult-targing of .net standard libs were an option. Is this issue only related to .net standard or does it also include .net framework ?
I think its an issue with UWP's .NET Native AOT compiler, .NET Standard is just the API contract so the surface area should exist everywhere on all platforms, but for some reason the method reference seems to have gotten removed under UWP .NET Native.
Thanks, rather confusing. Reading the following thread I assumed it was working under .net core + .net framework.
Sorry for all the questions. If the problem is the AOT compiler , will older versions of UniversalWindows then work ? I'm trying to figure out if there is a point in time that I can reference.
Yeah should work before .NET Native since it works fine in
Debug mode and
Release is normally just an optimized build whereas AOT uses a different compiler / toolchain.
For me to continue with UWP I'm thinking about taking out SS altogether on all my clients and replacing it with https://flurl.io/
Server side will stay as is with SS running in .net core. I'm currently using JWT so it should work with generic rest client.
The only problem that I can see is Server Send Events where I don't have a client that will work.
Would appreciate your thoughts and suggestions on above.
The source code for the
ServerEventsClient is available in these 2 classes:
You can try taking a modified copy and changing it to use your different HTTP Client and JSON serializer you want to use.
Thanks @myth , I think easiest is probably just decoupling SSE on server and use SignalR for real-time data than me trying to hack together "custom code" for SSE ) damm MS
I've ended up refactoring out the Reflection.Emit dependencies from ServiceStack.Text's .NET Standard 2.0 build into platform-specific .NET Core 2.1 and .NET v4.5 builds in this commit.
This change is available from the latest v5.1.1 which is now available on MyGet.
With this change the Client.UWP App in HelloMobile project now works in Release build, but Xamarin iOS/Android/Forms has an issue with the new efficient
Span<T> types which has only been resolved from VS.NET 15.8 Preview 3+:
So you would need to wait for the next v15.8 release or use the latest VS.NET preview to use ServiceStack's Client v5.1.1 libraries with Xamarin.Forms.
Hi @myth, you are the man What can I say , thank you very much. I'm already on latest VS15.8 preview so that's not an issue. You just saved me a lot of pain, IMHO reading between the lines online, is that Reflection.Emit is not worth pursuing going forward and although they potentially planning to include it in .net standard Vnext it looks like it's going to come with special build config to make it work. Too much friction if you ask me.
I'm seeing the following error with V5.1.1 in release mode (UWP)
Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.1.8\tools\Microsoft.NetNative.targets(788,5): warning : MCG : warning MCG0007: Unresolved P/Invoke method 'kernel32.dll!GetCurrentPackageFullName' for method 'System.Int32 ServiceStack.Text.Env.GetCurrentPackageFullName(System.Int32, System.Text.StringBuilder)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisfy those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.1.8\tools\Microsoft.NetNative.targets(788,5): error MSB6006: "ilc.exe" exited with code -1073741819.
Sigh, looks like we're back to not being able to reliably determine at runtime if its running in UWP, I've refactored it to use some heuristics that should work with the latest version of UWP in this commit.
This change is available in the latest v5.1.1 on MyGet.