using System.Speech.Synthesis with Windows10 universal app (XAML-C#) - c#

I tried to use the SpeechSynthesizer from System.Speech.Synthesis because it seems more comprehensive than the one I used before (Windows.Media.SpeechSynthesis) : I want to be able to set the volume, the gender of the voice, ... Besides, the french prononciation has some bugs, so I wanted to check if System.Speech was better.
I added the reference, but the Build gives this error and I can't fix it :
Cannot find type System.MarshalByRefObject in module CommonLanguageRuntimeLibrary.

There isn't really a way to use the .NET API System.Speech.Synthesis in a WinRT app, without creating an app that will wind up failing the WACK tests for submission.
Many of the .NET namespaces haven't been projected into WinRT. In particular, System.Speech.* since there's already Windows.Media.SpeechSynthesis and Windows.Media.SpeechRecognition, which were brought over from the windows phone API namespaces instead, and should be functionally complete for the majority of purposes.
Only old .NET APIs that are part of the .NETCore profile have been projected to WinRT.

Related

Xamarin : add .dll files at runtime to add functionnalities to application

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).

How does MonoRuntime lives side-by-side with ART?

I've read that applications which are being developed using Mono are deployed with a MonoRuntime that works similar as ART, interprets the C# code, executes them etc. I assume Unity and Xamarin both does this.
What is strange for me is that theoretically I could write a runtime and ship it with my app? But that is supposed to be next to the runtime, below the application framework? How can the sandboxing let this happen?
I assume this might be the solution to my confusion, but I struggle understanding it.
What am I missing here?
Thanks in advance
First think about how NDK/JNI apps work on Android. They are launched from standard Android Java code run via ART/Dalvik and use JNI calls into C/C++ code. The process is still within the standard Android 'sandbox' but has additional lower level access to libraries provided by Android NDK headers. As that code is written in C/C++ it can be performant/cross system compatible.
So to answer:
But that is supposed to be next to the runtime, below the application framework?
I would argue no, at least you aren't really below the Android application framework. The MonoRuntime is started from Android and can use any of the 'Standard Libraries' which are exposed either via a JNI wrapper to the Android Java side or by a NDK header.
If you look at the below diagram you'll see 'Standard Libraries' which can be OpenGL ES which has a Android Java API and OpenSL ES which exposes more detail in NDK than the Android Java media api.
I could write a runtime and ship it with my app?
Yes you could, although you may want to define clearly what you mean by 'runtime'. If you are pre-compiled you can strip out unnecessary classes/modules which I believe Mono does.
How can the sandboxing let this happen?
You are still in the sandbox. Nothing prevents you from writing your own interpreter / Virtual Machine written in C/C++, interfacing the Android framework through standard JNI/NDK calls, and adding it to your own APK. Regardless you are still limited to what the Android framework/runtime allows for apps along with same process restrictions and limitations.

Windows UWP - Dynamically Load Assembly In Side Loaded App

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

Proximity tap in WPF

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

Get 'Normal' .NET Classes to work on Windows 8

I normally write a lot of C#/.NET applications, so I figured I'd try out that combination for writing a Windows Store app first. However, I've been having a lot of trouble lately seeing as the classes seem to have developed a habit of disappearing. I've currently tried to write a simple FTP app, but the FTPWebRequest class is missing, and when I tried to create a Metro-Style terminal for Cmd, I noticed the Process class is missing. Is there any way of getting these classes back?
In essence, you can't. There may be some related WinRT classes available, but WinRT apps are sandboxed and don't necessarily have the same flexibility as your normal desktop app.
See for more details: http://blogs.msdn.com/b/b8/archive/2012/05/17/delivering-reliable-and-trustworthy-metro-style-apps.aspx
No, you can't get them back because they aren't there. When you create a Windows Store app, you are targeting a different version of the framework. Another example is when you target the .NET compact framework, the same calls will not be available as in the "normal" framework.

Categories