How to trigger a desktop process from sideloaded Windows Store Apps–the easy way using the brand new Visual Studio Templates

This posting is a follow up posting to my article on how to Trigger Desktop processes from Windows Store Apps. The last article was lengthy, but the result was correct. In the meantime you can download Templates for Visual Studio in the Visual Studio Gallery that make your life very easy when you try to achieve the same Thing. No Need for 50 steps, when you can do it in 14.

Basically  you can find a description on the downloadpage of the templates . Let’s go a little more into detail, to make sure it does work for you.

How To

1. Download &  install the templates. Restart VS afterwards.

2. Start VS as Admin. This will make your life very easy!

3. Create a solution containing 4 Projects in Visual Studio. A Windows Store App project based on the C# Template, a Classic C# Library, a Brokered Windows Runtime Component Project and a Brokered Windows Runtime Component Proxy.

4. Reference the Classic Library Project from your Broker Project.

5. Reference the Broker Project from the Proxy Project.

6. Reference the Proxy Project from the App Project.

7. Open the Settings of the Proxy Project and select Linker/General/Register Output –> YES. That’s why we started VS as admin!

8. Open the app manifest in the code Editor and add the following lines (you can put it right before the closign </Package> tag.

 <Extensions>
  <Extension Category="windows.activatableClass.inProcessServer">
    <InProcessServer>
      <Path>clrhost.dll</Path>
      <ActivatableClass 

 ActivatableClassId="BrokeredWindowsRuntimeComponent1.Class"

  ThreadingModel="MTA">
        <ActivatableClassAttribute Name="DesktopApplicationPath" Type="string" 

 Value="C:\Users\YOU\Documents\visual studio 2013\

 Projects\bwrc\bwrc\bin\Debug" />
      </ActivatableClass>
    </InProcessServer>
  </Extension>
</Extensions>

9.  Make sure you edit the path end ActivatableClassId correctly, depending on where the Output of the brokered component can be found and depending on the fully qualified class of the brokered component. For Debug purposes this will be the debug Folder. In production you will need another location! You just have to specify it.

10. Good News! You are basically done. To get this app to life, you could do stuff like:

11. Create a public method in ClassicLibrary:

 namespace ClassLibrary1<br>{    public class Class1<br>    {               public int RunCmdFromClassic()<br>        {<br>            System.Diagnostics.Process proc = new System.Diagnostics.Process();<br>            var cmd = "xcopy";<br>            System.Diagnostics.Process.Start("CMD.exe", cmd);<br>            proc.Close();            return 42;<br>        }<br>    }<br>} 

 11. Create a public method in the Broker that creates an instance of the classic class and Triggers the RunCMD Method. 

 namespace BrokeredWindowsRuntimeComponent1<br>{    public sealed class Class<br>    {        public int DoIt()<br>        {<br>            ClassLibrary1.Class1 cla = new ClassLibrary1.Class1();<br>            cla.RunCmdFromClassic();            return 42;<br>        }<br>    }<br>} 

12. Create a button in the mainpage of the app.

  <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"><br>        <Button Content="Click" Click="Button_Click"  

 Name="theButton"></Button><br>    </Grid> 

13. Add an Eventhandler that Triggers the brokered component.

 private void Button_Click(object sender, RoutedEventArgs e)<br>      {<br>          BrokeredWindowsRuntimeComponent1.Class cla =  

 new BrokeredWindowsRuntimeComponent1.Class();<br>          theButton.Content = cla.DoIt().ToString();            <br>      } 

14. Now let it run! Click the button and – it works! The result will look like this with the cmd opening up just once.

Comments

• Anonymous
  February 11, 2015
  The comment has been removed