I am looking for a way to interface with an Adafruit bluefruit LE (nRF8001 chipset) board, using c# in a windows desktop app (From what I've seen, I cannot use the Windows.Devices namespace without hacking it in.)
The device is properly paired to my tablet and seems to have no problems there, I'm just looking for a way to receive data from it in my program.
There has to be a way to do this, I cant think that Microsoft would limit using bluetooth to metro apps only, I just cant find it.
So, for posterity:
Everywhere on the net says to put the below in your csproj file:
<PropertyGroup>
<TargetPlatformVersion>8.0</TargetPlatformVersion>
</PropertyGroup>
This is actually incorrect if you are running windows 8.1, you have to put 8.1 there instead of 8.0. This change will allow you to reference the "Windows" assembly in the windows -> core section of the references dialog. Putting 8.0 there gets you a bunch of other things there that you don't want.
you also have to reference this dll:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\v4.5.1\System.Runtime.WindowsRuntime.dll
Which contains extension methods that allow you to use regular await calls on Windows.Foundation.IAsyncOperation instances. This is required because those instances don't contain the GetAwaiter method that the await keyword looks for.
After that you should be able to use the WinRT API in your desktop application.
Related
I would like to use nice UWP bluetooth classic APIs in my app. However my app has to be used as .exe, and it has to be portable (no installation in system). Is this possible?
The API used by UWP comes from the Windows Runtime Api, if you need to integrate Windows Runtime API in your desktop application, this is feasible.
Here is the document: Call Windows Runtime APIs in desktop apps.
But there are still some restrictions:
Due to the reference to the corresponding version of the SDK, your application can only run on the corresponding version (and above) of the Windows 10 system. May not work properly on lower version systems.
According to the description of this document, the Bluetooth API in Runtime is not yet fully supported in desktop applications.
In the description, you mentioned that you want to use portable application. Although many application functions can only be used in applications with a package identity, Windows.Device.Bluetooth is not listed here.
If the class under the Windows.Device.Bluetooth namespace has the Windows.Foundation.Metadata.DualApiPartition attribute, it means that the class can also be used directly in desktop applications, you can view related APIs in the Windows.Device.Bluetooth document.
Last year Stefan Wick provided an answer to a question about silent printing in UWP applications How to silent print from a UWP application, along with a sample app showing a solution.
That app won't work for me, as it can't access local settings. The error is that it needs Windows.Foundation.FoundationContract 3.0.0.0. The UWP project has access to that, but the Win32 project does not, and I can't figure out how to reference it (Nuget won't recognize it and I can't find a viable dll to download).
Any suggestions on how to get this to work?
Or any alternatives to get UWP to print directly to a USB connected receipt printer without requiring the user to see the print preview dialog?
Thanks!
You can reference the Windows.Foundation.FoundationContract directly from the References folder in C:\Program Files (x86)\Windows Kits\10\References\. Specifically this library is in the 10.0.17763.0\Windows.Foundation.FoundationContract\3.0.0.0 subfolder.
For more info on how to reference the libraries see this blogpost.
I know, there is an issue with System.AppDomain.CurrentDomain.GetAssemblies() in the Portable Class Libraries. To overcome it, I have decided to extract the list of assemblies in the target application and send it to my PCL as custom objects.
This was easy when using single-platform applications (pure WinForms, pure WP 8 application, etc.). However, I cannot find any suitable replacement for the method in Windows 10 Universal apps (and the documentation for both PCLs and Win 10 Universal Apps is pretty bad, so far). The reason, why PCLs are not able to get a list of assemblies is simply because the library does not know of all the assemblies, until it is built and packed into DLL. However, that cannot be said of the Universal App, since it should run the same system (Windows 10) -> therefore, it should be the same program on both PC and Phone -> therefore, the application should know of all its assemblies already before compiling.
So, does there exist a suitable replacement for this method, or some workaround how to get all the assemblies inside the app?
EDIT: I have found this workaround, which loops through all .dll and .exe files... however, that seems extremely unreliable. Is there a cleaner/better way?
I am new to Windows 8 App Store development and have bumped into something strange.
If I create a normal .net library (signed library) and attempt to add it to my Windows Store application, Visual Studio 2012 moans that I can't add this project. Both projects are in the same solution.
This project contains a reference to the System.Net assembly, as I use some of the types from there. I know that System.Net is not a fully supported namespace. TcpClient, NetworkStream, etc have all been removed. I also know that StreamSocket, DataReader and DataWriter in the Windows.Networking namespace is the alternative.
Before I loose you, let me get to the point. Instead of adding the compiled assembly from this project as a project reference to the Windows Store application, I browse for the compiled assembly on my hard drive and reference the assembly directly.
To my surprise, this worked! This leads me to the following questions:
Why? That doesn't make sense to me. Someone please explain.
Also, if I use this library, will the Windows Store reject my application? Answering the second question myself... Answer is YES! Windows Certification App, no longer recognises this as a Windows Store App if the mentioned library is referenced.
There are a couple ways to add an assembly reference to a project:
Add assembly reference to a project in same solution.
Browse for an assembly somewhere on your hard drive.
In Visual Studio 2012, if you add a non compliant WinRT assembly reference to a WinRT project, Visual Studio 2012 won't allow it.
However, if you add the same assembly to the WinRT project by browsing on your hard drive, the assembly is referenced successfully. This only works if the referenced assembly is signed with a strong key. I'm not sure if this is a flaw in the product or intentional.
Microsoft makes up for this flaw (if it infact is one) later on when passing your Windows Store App through certification. Certification fails because it recognises that an assembly has been referenced in the project which is not appropriate for a Windows App Store product.
So in summary, you can NOT reference WinRT assemblies in your WinRT projects. The drawback with doing this is that your app will fail Windows App Store validation. The advantage with this is if you are not developing a Windows App Store product, you can re-use work you've already done.
It's not all together clear to me, so I am hoping someone here knows the answer. I am using the C# Json.Net and the C# HtmlAgilityPack both built from sources for "Any CPU". I've noticed that both of these include using directives that reference assemblies that don't seem to be available in Metro yet they both build fine.
If I reference them, does this mean my app will thunk to unmanaged code?
What exactly causes thunking to unmanged code?
Why are DLLs allowed to reference assemblies that are not available to WinRT and my app is not?
Will this fail the windows store approval process?
What are the general rules for DLLs I include with my app that I need to worry about?
Thanks in advance!
When developing apps that target WinRT, the app should only use the API's available in Windows 8 WinRT. The API's are defined in WinMD files. If the app used the desktop API's, then it will be rejected during the Windows store approval process.
Imagine this scenaio. You developed a WinRT app that uses .NET DLL's from desktop mode (client profile). The app is deployed in Windows store and user downloads it on ARM tablet. The application will crash as it does not have the desktop (client) .NET DLL's on the ARM devices.
so this brings us to the question on what .NET classes we can use while developing apps for WinRT. The article http://kishore1021.wordpress.com/2012/08/06/what-is-portable-class-library-project-in-visual-studio-2012-net-4-5/ lists the .NET classes available for WinRT application development.
Change all open source projects dependencies to target WinRT. See if some methods / classes in WinRT are missing so the code does not compile. Try to find the alternative methods/classes.
Such as List.FindAll(), change to Linq Where()