Our Xamarin app supports some device-specific hardware features for a specific Android device packing an RFID scanner. We don't like to clutter up our basic app with stuff related to this device, so we created a separate Xamarin library containing the logic for this device, which is built to be an Asset of the Droid project. During statup of the app, we check if we are on this specific device and if we are, we programmatically load the hardware specific Xamarin library using Assembly.Load(...) and activate it.
The problem we run into is that the manufacturer of the device provided us with some native android libraries (.so files) that must be used. Normally you would include those in the Droid project with build action AndroidNativeLibrary, but since we want to encapsulate all stuff related to this device in a separate project, we don't want to do this. We have tried the following:
To add them to the device specific Xamarin library with build action AndroidNativeLibrary, but then the app cannot find them. They are probably not saved to disk and therefore they cannot be found.
To add them to the device specific Xamarin library with build action Embedded Resource and save them to disk when the library is started, but none of the locations, where the app searches for native libraries it needs, is accessible. Therefore the app cannot find them and the library cannot work.
I am starting to think that Android has shielded this kind of behavior off, but I am still hoping for some of you to help me with a good trick. Thanks in advance.
Related
I need help with a change of perspective.
Recently, due to the company's business needs, it is necessary to migrate the existing Win32 software to the UWP platform. Because the software involves multiple devices, different devices have their own specific interfaces.
If the released software package directly includes all devices, the software package will be too large. Therefore, we want to enable the main software framework to support the operation of the corresponding device by downloading or additional installation when the user's related equipment is identified.
From the information found so far, this method is somewhat similar to the Optional Package. However, the actual experiment found that it can only support the separation of the back-end logic code, but not the XAML Page into the optional package.
Is there any way to separate the XAML Page and load it dynamically?
I'm also currently looking at solutions to load XAML Page dynamically in UWP. While I don't have a working solution yet it looks like I'm on the right track.
It seems Windows Community Toolkit Sample App is loading XAML dynamically so all you should need is in that code base.
I'm wondering if it's possible for a Xamarin application (all the platforms : Android, iOS, Windows Phone) to detect and load assemblies at runtime.
This is the kind of thing that I already did in WPF, and I'd like to use those modules (maybe with some modifications) in a Xamarin app.
I've spent yesterday looking for info online, and today I tried to implement a solution, but without success.
Prism seemed to be a way to do it, but it works only in WPF.
The restriction which makes this difficult is that I don't know at compile time any information about the assemblies. No names, no versions, no classes.
I can put the name and the version in the filename, and maybe find the classes by reflection. Using an interface as entry point (Prism use this), I should be able to do it.
Do you have any thoughts about this challenge ?
Thank you very much !
iOS: No
Apple does not allow code that was not bundled into the app at signing time to be executed, thus no on-the-fly Jit'ing of CIL allowed. The only exception to this is Javascript code that is run via their Nitro JavaScript Engine.
Android: Yes
Google allows just about anything you can think of, for better or worse ;-)
Windows Phone: No
All code must be signed as part of the Microsoft Store' App Ingestion process and thus you can not dynamically load assemblies later
Note: If this is a hard requirement for your app, you should look at hybrid mobile apps, like Cordova/Ionic, where you can perform a hot push to roll out new features, bugs fixes, etc... Besides self-hosting those hot pushes, various vendors support hosting of those, even Microsoft Azure has a full versioning publication system for this. Of course you would most likely be coding in JavaScript (or some trans-compiled variant).
It seems to be a deliberate security of Windows 10 Store apps that assemblies not be allowed to be loaded at runtime. I think that this feature is massive overkill and stops UWP development dead in its tracks. However, if it is a rock solid design decision by Microsoft, there is nothing we can do to argue with it.
Instead, I'd like to ask the question, assuming that you were not deploying your UWP app to the store, would it still be impossible to load an assembly dynamically? If it's possible, how?
Please see this feature request: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/18145291-dynamically-load-assembly
Regardless of what environment you deploy your UWP application to, the UWP API will be the same. Choosing to deploy your app internally instead of to the Windows Store will not enable non-supported API features, eg. Assembly.Load().
It seems as though the answer to this question is no.
The game has changed in UWP. UWP is a platform which is geared toward getting apps in to the store. It's a stripped down platform and doesn't appear to allow you to load assemblies at runtime. This was possible in .NET.
However, there does seem to be a way to run UWP style apps on top of the .NET runtime using the Desktop Bridge. I'm not really that familiar with it, but you can read more here as a starting my point. My guess is that if you want to load assemblies dynamically, the best approach would be to use this:
https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root
Does anybody of you guys have experiences with including a C#-based Console Application in a C#-based Universal Windows App?
The reason why I'm asking: I've an already exsisting Console Application developed by another developer. This Application includes a database with all the queries which I need for my App.
The problem: When I try to include the CA in my UWA project many commands like
private global::System.Runtime.InteropServices.HandleRef
throw new global::System.ApplicationException
don't get identified by VS2015.
Is there a way to let the UWA project identify CA commands? For example with adding an external CA-library or something like that.
Thank you!
You can't combine full .NET (console, winforms, WPF) assemblies with an UWP app, as they're different .NET frameworks. For more details, please read this reply. Part of the code is shareable in a Portable Class Library (PCL), but most likely not all of the code you've written.
Possible solutions:
Create an API (yourself or with the other developer) to expose the functionality needed over a (preferably) REST api.
Find a way to cheat the system. Example: launch a file (associated to the console application) with the Launcher api and output the results to a text file on disk, which you then read from your UWP app.
The first one is guaranteed to work. You might find a way to cheat the system for the second 'solution', but there's no guarantee that it won't break in the future when Windows 10 gets updated (experienced that myself for another 'hack' on the upgrade between Windows 8 and 8.1).
I'm trying to detect nearby devices using NFC or RFID from within a WPF application.
Microsoft's proximity API seems to be the right way to go:
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465221.aspx
Unfortunately, I see no way to get it running inside a WPF application (or any other Desktop Technology that is). All examples refer to Microsoft store apps only.
From within a WPF application I cannot reference the Namespace
using Windows.Networking.Proximity;
Is it just a reference that I am missing? Is it possible to use the proximity API from a WPF application at all?
I finally found a sample project using the proximity API from within a WPF application:
http://code.msdn.microsoft.com/windowsdesktop/NFC-Editor-529ccda6
There is also a short tutorial included on how to use WinRT API's in WPF applications.
The basic steps:
Manually add a <TargetPlatformVersion>8.0</TargetPlatformVersion> line to the csproj file
Back in Visual Studio, add a reference to Windows/Core/Windows to the project references
Add a reference to the Windows Runtime assemblies to the project.
See above given link for details.
I believe that the Windows.Networking.Proximity.ProximityDevice class is not available in WPF Applications. If you look on the ProximityDevice class page on MSDN, you'll see that it is part of the Windows.Phone API:
The monitor image next to the phone image also leads me to believe that it is available for Windows Store Apps too. I'm guessing that (at present at least) the vast majority of desktop computers won't have any RFC hardware that could be used with this code and so that is why it is missing from the standard .NET dlls.
[2020 is here]
Procedure to prepare your Console/WPF project to call UWP APIs (both are OK):
https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance
https://blogs.windows.com/windowsdeveloper/2019/09/30/windows-10-winrt-api-packs-released/
Heads up: You'll need to migrate the project from the packages.config management format to the PackageReference format
https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-steps