What is the best approach to communicate between UWP app (client app) installed on phone and WPF app itself installed on local machine if they are connected to the same router? Files should sync from client to server and vice versa.
As I investigated before there are WCF, Sockets, and Web. So what is the best one to use to create such functionality?
It does not matter if the app is WPF or UWP. To choose framework like WCF or Sockets you need to know how complex your scenario is. If it is rather simple, I would advice agains WCF. It can be unnecessary complicated for basic usage. You can try web api - lite system using JSON. Generally speaking, I do recommend the framework enabling http protocol as it is reusable for almost every scenario. But that is not filter that would help you much :D
For UWP that have not allowed calling localhost and you can use it to communicate to local wpf app.
More details here and here.
But you can make the uwp communicate to local wpf app in debug, see Deploying and debugging Universal Windows Platform (UWP) apps - UWP app developer | Microsoft Docs
If you want your uwp app can use localhost in release that you should use checknetisolation and you can see some way to use wcf in the article.
I am a wp8 developer and searching for a way to deploy my app on device "without the cable". I have searched over the web and could find nothing helpful. I know about he "Application Deployment" tool in WP8 SDK and my phone is also Developer Unlocked. I know how to simply deploy an app on windows phone. All i am looking for is to know, Is there any way I can deploy my application to my phone without using the phone cable?
Lets say i dont have my cable with me, what options do I have now?
Currently you can't debug an app on your phone without the USB cable. You can do this when developing for Windows 8.x so perhaps with the coming WP8.1 update we'll get the same feature for the phone..
There is the beta testing you could do for a test deployment through the store but the app will run through the cert. process so this is no option for testing while developing and there is no debugging.
You can only use the cable to deploy to your device. If you dont have a cable with you, just use the emulator.
I have a Windows Store - Metro app that connects with a Net TCP WCF Service running on same PC (hosted in a console application) but on Desktop mode of Windows 8. I have added a reference of WCF Service inside metro app and everything works fine.
I package my store/metro app and WCF Service and try out on another PC which don't have Visual Studio installed so I don't recompile the code, I just install the metro app package and run the executable of WCF Service. WCF Service starts fine but when I launch my metro app it give me error (see the image below)
It seems that for some reason metro app when installed on other PC is unable to find the service reference. I have tried many things after googling but nothing works. Any ideas/hint/suggestion would be greatly appreciated.
Windows Store Apps generally cannot use the loopback address, except for 1) communication within the SAME process, or 2) for development purposes. From How to enable loopback and troubleshoot network isolation:
Network communications using an IP loopback address cannot be used for interprocess communication (between two different apps) in a Windows Store app since this is restricted by network isolation. Network communication using an IP loopback address is allowed within an app within the same process for communication purposes.
A developer may want to use loopback for testing or debugging purposes, even though that capability will not be available for customers. For example, an app may want to download data from a web service from a Windows Store app. For development purposes, the developer wants to test the app on a single computer that is configured with the web service locally on 127.0.0.1.
Loopback is permitted only for development purposes. Usage by a Windows Store app installed outside of Visual Studio is not permitted.
In a production scenario, you will likely have to install the WCF service on a separate machine. Note that you will have to enable the "private network" capability in your application manifest (on the client app) to enable local network access.
My goal is to run flash locally on a Windows Surface RT tablet. From research, I have found that for websites to run flash, they have to be whitelisted on Microsoft's website. Through further research, I have found how to hack the whitelist to add any domain:
http://www.redmondpie.com/how-to-enable-flash-for-any-site-in-windows-8-rt-metro-internet-explorer-10/.
However, I cannot add the local file system (i.e. C:\ or file:\\) as they are not domains. One solution, I have though of is by using localhost. How can I write a web server to run on Windows 8 Surface RT, or can it be done?
In C#, I know you can use System.Net.HttpListener: http://www.codehosting.net/blog/BlogEngine/post/Simple-C-Web-Server.aspx. Is System.Net.HttpListener supported with Surface RT? If not, what are alternative solutions to play flash locally?
Theoretically, it is possible. You need to use StreamSocketListener to get a StreamSocket. Then you handle http input from that socket (tons of work), and send back your response. I've made my protocol work. One thing you might need to pay attention is that you might need a second machine to send the http request. I use IE from another PC to send the test request. Win8 network isolation won't allow tcp connections between 2 apps of a same machine...
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app