I have a uwp project and a windows app (net5).
Both are installed in the same machine (same will happen in production), but the uwp is installed using sideloading, not on windows store.
The windows app gets some data by listening to a wss port. I have to pass those data from the windows app to the uwp app and also wait for a response back from it.
To do this internal communication I came across the AppServiceBridgeSamples in this repo https://github.com/microsoft/DesktopBridgeToUWP-Samples but it is outdated and I can't use it.
Is there any alternatives to it? What would be the easiest implementation to achieve this?
Any suggestions/comments are appreciated.
Currently, the general way to implement a communication channel between a UWP app and a windows app is by using App service. This is not outdated. If you don't want to use the App service, you have to build your own socket server so that both of your apps could communicate with it. Another way is that your windows app could save the data in a local file and load them in the UWP app.
I have a UWP app and Unity3d app build for Windows. I have a requirement of establishing communication between UWP app and Unity3d app.Both apps will run on same computer.
Development of Unity3d app and Universal app(Windows 10 native app) both are done in C# language.
Communication should involve:
Launching and closing Unity3d app from UWP app.
Send data from UWP app to Unity3d app.
Receive data from Unity3d app to Windows native app.
I had searched for resources for this but unable to find any. Could someone please share possible ways to achieve the above and resources/examples for those.
Thanks :)
i did this via an Appservice: https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-and-consume-an-app-service in your normal xaml app host the app service and let unity consume data from it.
And via protocol activation the apps can start eachother.
I am currently in the process of migrating all of our applications over to the Windows 10 UWP platform. We were coming from the Windows 8.1 platform and we were using a WCF service to send both data as well as files to and from a server running our service.
This worked great in Windows 8.1 since it fully supported the uploading of files to a WCF service that had a nettcpbinding. However, according to numerous posts on here as well as the MSDN forums, nettcpbinding is not currently supported on UWP. Whenever I try to run our app and upload a file to our server I get PlatformNotSupportedException when it tries to upload.
The issue here is that while I could roll my own socket classes to upload this file, I find it hard to believe that Microsoft would've released UWP without basic support for nettcpbindings. On top of this it appears that the .NET library that is included in UWP apps does not have support for native FTP so I cannot do that either.
Has anyone had any experience in getting nettcpbindings to work with UWP? If I try to circumvent my proxy classes that I have made manually with "Add Service Reference" it ends up generating the upload method with an incorrect signature. The signature is supposed to be UploadFileAsync(RemoteFileInfo info) but is turned into UploadFileInfo(byte[] info when using "Add Service Reference".
Any ideas?
I have been struggling with this for over a month, but am slowly learning. Here is what I have:
C# Solution With 3 Projects
-Universal Windows Platform App (Cortana Voice Support)
::Above just shows a floating PNG image and is Cortana enabled
-Universal Windows Service (Cortana Background Service)
::Needed for the Cortana Support
-.Net 4.5 C# App with HTML DOM Automation
::Automates locating elements and clicking of a website
I can't re-code my .Net app's functionality in my Universal app because some of the libraries it uses won't install. (GhostDriver, PhantomJS, and a HotKey Library provided via NuGet. Installing on the Universal Platform fails on all 3 libraries).
What is needed:
-Master Universal Windows App or Service sends signal to .Net App
-.Net App receives signal and calls method/function providing my functionality.
I've never tried calling methods in other apps within the same solution and was wondering if there was a few-code workaround. What I need I think is a method of inter process communication or events, but can't find any examples of a UWP. Most are .Net communicating with other older non universal apps.
Thank you so much!
If I understand correctly, you were developing a app which will can automate the DOM operation through Cortana.
Do you need to submit this app to App Store?
If no, as Scott said, you can use WCF to communicate between UWP process and .NET 4.5 desktop app process.
If yes, as Andrew pointed out, you need an intermediate remote server hosting the service.
Is SignalR suitable for windows desktop applications (winforms/wpf)?
What are the advantages and disadvantages using SignalR with windows desktop applications?
Are there any performance considerations?
I want to make real-time connections between server and a lot of clients. The connections will be constant.
Is SignalR suitable for windows desktop applications (winforms/wpf)?
The answer from signalr.net is:
SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application.
(As stated correctly by others it can be self-hosted, so no need for IIS)
So the answer seems to be no. It is a server side API. But today is your lucky day, since the download of SignalR doesn't only reveal the server side API, but also a client side API called Microsoft.AspNet.SignalR.Client45 to use in your application. It works for WPF, WF or even console applications.
And even if it didn't, SignalR is just a wrapper around the WebSockets protocol, which is part of the HTTP protocol, which can be used on virtually any platform. The download also contains a sample for iOS and Xamarin for example.
What are the advantages and disadvantages using SignalR with windows desktop applications?
To have real-time notifications from and to the server.
Is there any performance problems?
That is a hard question to answer, since there is no reference point. Compared to what the performance is good or bad? Generally spoken, I don't think you have to worry to much about that. The API itself is fast, and it may prevent slow pull-requests you need to do else.
It is absolutelly correct to consume SinglarR hub in any client application, WPF, windows phone, UWP, iOS, Android, including HTML. Microsoft has created client libraries on many platforms.
When it comes to hosting SignalR, then you can definitelly host you SingalR server (hub) in WPF application, but you need a reason:
The reason may be:
IIS is not available
You don't know in advance where the APP will
be used. You just need to run an app, that will notify other apps
Performance - IIS adds some performance overhead.
By the way, SignalR and OWIN has been an inspiration for the new ASP.NET 5. You can now host your ASP.NET apps in WPF, console application or windows service app without IIS, or even on Linux.
http://www.asp.net/signalr/overview/deployment/tutorial-signalr-self-host
In a setup with a server and many clients: If you need "push" notifications from the server to some clients then SignalR is good to use.
I do so with WPF clients.
When you build a website with signalr functionality you have a signalR server, where the site is hosted and a signalr client, the javascript client that runs in the web browser that browses the site.
From years immemorable, web browsers were (and still are)... well,... desktop applications...
So you have desktop applications (the web broswer) that use SignalR to connect to a web site (the web server).
So, not only is it correct to use signalR for desktop applications, but this is what it is meant for. I really don't know what would be the use of signalR if it wasn't to be used in a desktop application at some point, because, frankly, a user sits in front of a desktop (or a smart device), and doesn't exist "in the cloud" (unless you are Neo from Matrix). With signalR you have "real-time" reactions from the server presented in your desktop environment (a web browser or another desktop application, for instance an application that controls the lights in your home, or prints something in your printer).