locked
Interprocess Communication

Answers

All replies

  • One of the IPC issues discussed during Build was that Metro apps may be in a suspended state. So you cannot safely assume that an app is listening or ready to receive a message at any time. This makes Metro <=> Metro communciation tricky. Same goes for Desktop => Metro communication, but Metro => Desktop communication may work out easier since the desktop app can guarantee to be alive (short of a crash).
    http://blog.voidnish.com
    Wednesday, September 21, 2011 11:10 AM
  • Nishant, when you say "Metro=>Desktop communication may work...", do you know if there is a reliable way to do this in which both AppStore policy as well as WinRT are compliant with? Thanks in advance.
    Wednesday, September 21, 2011 2:46 PM
  • Nishant, when you say "Metro=>Desktop communication may work...", do you know if there is a reliable way to do this in which both AppStore policy as well as WinRT are compliant with? Thanks in advance.


    I am not sure of app-store policy on this but considering you are allowed to use WCF/web-services, it probably shouldn't matter if you connect to a desktop app hosting a WCF service. You could test this out by running it through the provided verification app (and see if it passes the validation).

    I don't think you could use classical mechanisms like named pipes though.

     


    http://blog.voidnish.com
    Wednesday, September 21, 2011 3:03 PM
  • Your app cannot use localhost to connect to another process on the same box -- this is a basic security principle that you won't be able to evade.  Even the presense fo the windows web services APIs won't help you -- it's all blocked by the firewall.

    Wednesday, September 21, 2011 9:54 PM
  • Check out this thread: http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/0005b94f-8409-4804-88c5-e2f5fcce460a

    In VC11 you need to set the capabilities to allow local communication. I have seen this work for web services (where the service was hosted as a managed C++ service). I havent tried sockets yet although that should work too, as there is a specific capability to allow localhost socket communication.  

     

     

     

    Sunday, September 25, 2011 3:10 AM
  • I saw that one, you asked the same question in that thread.

    But my concern was really IPC rather than RPC, my testing shows that sandbox blocks talks from localhost, but that does work between networks, that including hyper-V setup, which is it intended for.

    Wondering what solution you came up with IPC eventually?

     

    Thanks,

    Sunday, September 25, 2011 4:10 AM
  • None of the traditional IPCs are going to work. For e.g. shared memory, named pipes, COM (Exe or DLL) is not going to work between metro and Win32. Thats why I was trying to use WSDL or sockets to do communication on localhost (and simulate an IPC). I have verified that WSDL works (if the capability is selected). Thats why I thought sockets over localhost will also work although you mention in another thread that it didnt work even though you selected the capability. Note that my mechanism is creating the server in Win32 and WinRT is acting as a client. This has worked for WSDL. 
    Sunday, September 25, 2011 5:21 PM
  • You are right in that none of the 'fast' traditional interprocess comms method will work.

    FYI, There is some thoughts from an MS visual studio team member here and also links to the MS build videos discussing this issue ...
    http://stackoverflow.com/questions/7465517/how-can-a-metro-app-in-windows-8-communicate-with-a-backend-desktop-app-on-the-sa

    • Edited by Harvey_Green Wednesday, September 28, 2011 2:33 AM
    Wednesday, September 28, 2011 2:33 AM
  • Your app cannot use localhost to connect to another process on the same box -- this is a basic security principle that you won't be able to evade.  Even the presense fo the windows web services APIs won't help you -- it's all blocked by the firewall.

    Why can we not evade this? I want to develop an app that is 100% functional in metro-only mode, but it has the opportunity to access a process locally via IPC to localhost (like WCF) for certain functions. I do not understand why this isn't allowed and, as a developer, you aren't winning me over with this whole Metro concept.
    • Edited by awgneo Friday, February 10, 2012 1:54 AM
    Friday, February 10, 2012 1:53 AM
  • Please see the post from John Hazen in the Building Metro style apps with C# or VB forum for the answer and some background on this.

    Interaction between Metro style and non-Metro style applications

    Thanks,

    -David

    Friday, February 10, 2012 9:31 PM
    Moderator