I recently started using the protobuf-net library as a way to get around the lack of binary serialization in .Net Core on Windows Phone 8.1 for a port of an existing game.
So far protobuf-net has been working great for me. However when I came to submit the app it is failing the certification tests. The report lists various methods and classes belonging in the protobuf-net dll as being unsupported APIs.
An example from this report is:
This API is not supported for this application type - Api=System.Reflection.Emit.Label. Module=MSCORLIB, PUBLICKEYTOKEN=7CEC85D7BEA7798E. File=protobuf-net.dll.
This API is not supported for this application type - Api=System.Reflection.Emit.DynamicMethod. Module=MSCORLIB, PUBLICKEYTOKEN=7CEC85D7BEA7798E. File=protobuf-net.dll.
This API is not supported for this application type - Api=System.Reflection.Emit.ILGenerator. Module=MSCORLIB, PUBLICKEYTOKEN=7CEC85D7BEA7798E. File=protobuf-net.dll.
This API is not supported for this application type - Api=System.Reflection.Emit.LocalBuilder. Module=MSCORLIB, PUBLICKEYTOKEN=7CEC85D7BEA7798E. File=protobuf-net.dll.
This API is not supported for this application type - Api=System.Reflection.MemberTypes. Module=MSCORLIB, PUBLICKEYTOKEN=7CEC85D7BEA7798E. File=protobuf-net.dll.
There are many more but I have left them out for brevity. However as far as I can tell the MSDN documentation states that each of these APIs ARE supported on Windows Phone 8.1. Certainly in my own tests the library has been working correctly on device for some weeks when deploying from Visual Studio.
Is anyone aware of any steps that I could be missing here, some flag that needs setting in the package manifest or something like that? Or could I be using an incorrect version of protobuf-net (I built the dll from the WindowsPhone8.0 project)?
Thanks
Tom
As you're doing this as a Universal app, you're restricting yourself to the APIs that will also be available to desktop apps, and whilst part of the System.Reflection.Emit namespace is there, it does not include those classes that your error message refers.
Related
Attempting to submit a Windows Phone Silverlight 8.1 app to the store. Solution has several projects, including a Models, Contracts and a Shared DLL. These 3 projects/dlls are failing the Windows App Certification Kit tests with:
File XXX.Shared.dll has failed the NXCheck check
File XXX.Contracts.dll has failed the NXCheck check
File XXX.Models.dll has failed the NXCheck check
Microsoft say the problem is a Security threat issue, because these dlls are running code that is stored in a data segment.
The suggested resolution from Microsoft is to add the /NXCOMPAT switch to the Linker options, however, I do not have a Linker page in the properties in any of the 3 offending projects. I've tried adding this to the compilation symbols, but no change.
These DLLs are low payload - they contain not much more than POCO data objects, interfaces and a few static methods. I've built a new default blank Windows Phone app and added these projects to the Solution. If I reference any one of these projects in the main phone app project, the certification fails with the same result.
So the problem is definitely isolated to these 3 projects. There are other projects of the same type included in the solution, but these do not exhibit the same problem.
Does anyone have any ideas as to what these DLLs could contain which causes this Binary Analyzer failure?
I've compared compiler / build options and checked the project properties etc, but can't see any obvious differences.
This was due to a post-compile Build Event referencing an obfuscation library in each of these projects. Solution was to remove it as the library was third party.
Recently I began working in WinRT for Windows Store Apps (and the upcoming Windows 10 Universal Apps) using C#. After working in .NET for awhile previously, I was excited to work with .NET on mobile devices, only to find that WinRT did not feel like home at all.
Constantly I find myself having to search for alternatives to certain classes that I'm familiar with in .NET since often they're not the same or even implemented in WinRT. I figure that the lack of implementation derives from the fact that WinRT at its core is unmanaged, even though the CLR binds to it from managed code.
My question is: What is stopping Microsoft from allowing developers to import and use all of the familiar .NET classes from managed code, even with WinRT running from behind? I know it's not a limitation of the device because my Surface Pro can run desktop .NET apps just fine and the Mono project has succeeded in porting almost the entire .NET API to devices of every kind.
Thanks for your input!
This is a big topic but there are three basic reasons why you don't get the full .NET API from a Windows Store app.
The APIs don't fit on smaller devices like phones. Since the purpose of the Universal Windows Platform is to have apps that can run everywhere, it can't include APIs that are too resource-intensive (disk, memory, CPU, etc.) to run on smaller devices. (Note that even if the managed API appears to be small, it might have a dependency on a large underlying Win32 API).
The APIs aren't compatible with the Store app model. Many APIs that require permissions not granted to Store apps fall into this category, as do APIs that would enable apps to do "unwanted" things to your machine (the degree of "unwantedness" is subjective).
The APIs are deprecated or there are newer alternatives. This was the case with a lot of APIs in Windows 8, where things like file-system access and network sockets were blocked from Store apps because there were newer WinRT equivalents.
Note that Microsoft is always open to re-evaluating whether a specific API should be included or not. For example, Windows 10 brings back many APIs that were banned from Windows 8.1 (such as System.IO and System.Net.Sockets) and has expanded the capabilities granted to apps. You can file feedback via the Windows Feedback app or on UserVoice if you want additional APIs brought back (adding detailed justification never hurts).
Reading this today, and probably embarking on a Xamarin solution very soon (the other possibility is "going native" with just Android, using Android Studio), I got to wondering:
Can ELMAH be used in Xamarin solutions?
And, in fact, if the road less taken (Android Studio) is chosen, what tool is there for Android/Java projects that that most closely resembles ELMAH's advantages?
It does:
Although the Elmah.IO NuGet's latest release doesn't support
Xamarin.Forms cross-platform logging, I have used it in my
Android/iOS/UWP projects' exception handling separately by following instructions here.
Here you can find out descriptions about the
pre-release elmah.io for Xamarin and Xamarin.Forms.
No. ELMAH is very specifically targeted for ASP.NET.
Error/crash logging solutions for Xamarin include Raygun, Crashlytics, and TestFlight.
In my Windows Store Application, I am getting the error:
Cannot find type System.Windows.Media.AudioSink in module System.Windows.dll
I tried to add a reference to it, but I can't find an assembly list in my project's references.
My system:
OS - Windows 8.1
IDE - Visual studio 2013
The .NET Core for Windows Store Applications does not include all of .NET 4.5 (nor 4.5.1). It is a subset of it, meaning that not all classes are included. It also has some classes specific to it.
If you want to do audio, you should look into the Getting Started with Audio and Video tutorial that Microsoft created for this very purpose.
Also, in the future you should probably include what language you are using. There are multiple languages that Windows Store Apps can be created in (C#,C++/XAML, Javascript/HTML), and it helps to know that.
I'm developing a WindowsPhone8 application on Visual Studio 2012.3. (on Windows8 x64, ARM project) Application works fine on emulator, but when I tried to deploy it onto real phone I have got:
Windows Phone: Deployment of application to device failed.
It is a common question. I think that it will be helpful:
"The current implementation of strong names in Windows Phone 8 does
not support the RSA-SHA256, RSA-SHA384, or RSA-SHA512 (collectively
known as RSA-SHA2) signature algorithms. The current implementation
supports only the RSA-SHA1 signature algorithm. Therefore, developers
should use the RSA-SHA1 signature algorithm. Developers who write
Portable Class Library projects that include Windows Phone 8 as one of
the target platforms should consider this support if they decide to
sign their projects. "