Remote Tools Framework 1.0 Is For Real


Published by Dave Edson 


Last year we released a powertoy for the Remote Tools Framework. Now, with the SP1 release, we have released the real product.


The Remote Tools Framework allows you to write remote tools (think Remote System Information) quickly and easily. A Remote Tool is now a plug-in, distributed as a .cetool file. This one file bundles together all of the different peices of a remote tool. No setup involved, just double click on the .cetool file to run it.


The new Remote Tools Shell is the entry point to running the plug-ins. You can deploy multiple tools to the same device simultaneously. You can split the shell’s window to provide side-by-side functionality. Included with the product is the new Remote System Information, which now shows you more information than older versions, especially in the areas of certificates.


Also new with the Remote Tools Framework is a wizard for Visual Studio that will make building your own custom tool a snap. Simply run the wizard, and you will have a simple remote tool that is ready to be enhanced with your specific needs.


Now that the Remote Tools Framework is no longer a powertoy and instead a real product, you can be assured that we are committed to it and its success.


Feel free to ask me any questions about it.


If you have installed SP1 of Platofrm Builder, you already have the Remote Tools Framework, just look on your start menu for “Microsoft Remote Tools Framework 1.0”. If you want to install just the framework and not Platform Builder, go to http://www.microsoft.com/downloads and then search for “Remote Tools Framework”.


Cheers!
Dave Edson
Remote Tools Framework Guy

Comments (19)

  1. Anonymous says:

    Is this for CE6 only, or can it be used with CE5?

  2. Anonymous says:

    I am looking for a solution to run Nunit and our in house benchmarking software on a custom Windows CE 5 device.  I had been looking at the Core Connectivity APIs which lead me here.  We are a C# shop.  My needs are:

    1) Copy the various executable files (Test Runner, dlls containing the tests, etc) to the device.

    2) Execute the Test Runner Remotly.

    3) Collect the standard out and standard error to the Desktop.

    4) Copy the results XML file from the device to a network drive.

    Can the Remote Tools Framework help with this?  Or am I better off sticking with CoreCon?

    Pat O

  3. ce_base says:

    Fin Springs: it can be used with CE6, CE5, WM6, WM5, and WM2003.

    Pat O: The Remote Tools Framework can do all that you ask for.  (I’m hand-waving on the stdout/stderr question because I don’t know how to do that.  However the framework plug-ins can do anything an application can do, so if you already know how to do that you should be able to make your framework plug-in do it too.)  I believe you will find it MUCH easier to write a Remote Tools Framework plug-in than to write against CoreCon.  The framework can do everything that CoreCon can do, but the interface is much clearer and easier to use.

    Sue

  4. Anonymous says:

    Sue,

     Thanks for the response.  One other question.  It seems that the Remote Tools Framework is designed to work through the Remote Tools Shell.  My need is for this to be automated as part of our build process.  Is this possible with the Remote Tools Framework?

    Pat O

  5. ce_base says:

    Interesting question!  So you want to run automated tests at the end of your build?  There might be a way for you to use our own test hooks to automate the UI, but I’ll have to let Dave or someone on our test team answer that.  If we don’t support that now, we definitely should.  And if we do support it, we should document it (I don’t believe I saw that in our docs).  Thanks for bringing it up!

    Sue

  6. Anonymous says:

    Great. I meant to also ask: will this work on headless devices? Is it just using corecon?

  7. ce_base says:

    It is just using CoreCon.  If you use native code for the device side of your plug-in, then this will work on headless devices.  If you use managed code on the device side, there is actually a dependency on some UI stuff. So, even though in CE6 there’s a headless version of the .NET CF, the Remote Tools Framework device-side managed component requires the full-blown .NET CF.

    And just to make sure it’s clear, for headless devices, you can use managed code on the desktop side to write your plug-in, as long as the device side is native.

    Sue

  8. ken sadahiro says:

    Additional information about the downloads:

    • The English version of the Remote Tools Framework 1.00 is here:

    http://www.microsoft.com/downloads/details.aspx?FamilyID=35e9ef0f-833f-4987-9d1f-157a0a6a76e4&DisplayLang=en

    • The Japanese version of the Remote Tools Framework 1.00 is here:

    http://www.microsoft.com/downloads/details.aspx?FamilyID=445b15a3-2b78-4fd8-be0b-861c0e58ea4d&DisplayLang=ja

    PatO:

    What is your need for automation? Do you need to launch a remote tools framework plugin, connect it to a specific device AND operate some of its features from an external program?  Or do you just need to launch a plug-in?

    If it’s the former, we don’t currently have an official way of automating a remote tools framework plug-in just yet, but it is under consideration.

    If it’s the latter, then you can launch a specific plug-in from the command line by providing its path after "remotetoolsshell.exe", for instance, if your plugin is myplugin.cetool, then:

    remotetoolshell myplugin.cetool

    will launch this plugin.  The only thing is that you’ll be asked to specify a device to which you want to connect.

    If this is acceptable, an extension to this idea is that when your remote tools framework plug-in’s desktop side .NET Class Library is launched, you may be able to do some things in one of the callbacks that are called by the framework.    You can learn more about plug-in entry points by referring to the extensive Remote Tools Framework API reference documentation that is shipped as part of the product — look for the PluginComponent class.

  9. Anonymous says:

    To add to Ken’s contents…

    "Yes, it is possible to use the remote tools framework without the remote tool shell and the UI. However, this is an unsupported scenario currently.

    Remote tools framework uses a native COM assembly to communicate with the device. This assembly is RemoteToolServer.dll that ships with the product. If you don’t want to use the remote tool shell, then you can use remote tool server assembly with a device side app. This device side app needs to be similar to the device side code specified in the samples. This will help you to integrate your automation needs. If you want to use C# you might need to write an interop with the interfaces defined that you want to use in the remote tool server assembly. You also need to create an xsl file that defines the boot strapping modules that you want kick started or files that you want copied over prior to running the device side. This xsl file needs to be stored in the global corecon datastore"

    Anand

  10. Anonymous says:

    There is a bug/typo in the RemoteTools Framework Shell sample.  Under DeviceEmulatorRemote System InformationSystemSummary, on the right panel it has a value for "CDS Version" but it should be "CSD Version".

  11. ken sadahiro says:

    David:

    Thanks for letting us know!


    Coming back to Pat O’Hara’s question about automation during the build process:

    I wanted to add that, while the Remote Tools Shell doesn’t directly support your use case, your plug-in could expose public APIs to which a client app could call, and/or you could setup interprocess communication between your build commands and the Remote Tools Shell in a variety of ways.

    It’s interesting that you wanted to do something with a remote tool during your automated build process.  I’m curious to find out more about this. (See below for my email)


    A note to developers regarding RemoteToolServer.dll:

    Anand mentioned this, but I just wanted to reiterate that calling the RemoteToolServer.dll directly is unsupported in this release. There is no documentation on the API that it exposes, nor are there any samples available.

    Furthermore, this DLL is subject to significant changes in future versions.

    If you do have a need to program a remote tool application with a custom UI (managed or native), please email me directly for further discussion.  I can be reached at kensadah [at] microsoft.com.

    Ken Sadahiro

    Program Manager, Remote Tools

    Microsoft Corporation

  12. Anonymous says:

    Is it also possible to create a C# device side for CF 2.0 for the add-in?

    Thanks

    Martin

  13. ken sadahiro says:

    Martin:

    Is it also possible to create a C# device side for CF 2.0 for the add-in?

    Yes, it is.

    While the Remote Tools Framework device side managed libraries depend on .NET CF 1.0, you can still run the device side binaries on a .NET CF 2.0 device.  There’s a topic in the documentation that discusses the use of a .config file to specify the .NET CF runtime version for the executable.

    With that said, there is an issue we are investigating – it pertains to the Remote Tools Framework (and CoreCon, which is used underneath) startup process on a .NET CF 2.0 device (e.g. Windows Mobile 6).  You may experience problems launching the device-side managed executable on such a device, if there are no pre-existing CoreCon-based connections already established on the device at the time of startup.  We are still in the process of investigating.

  14. Anonymous says:

    I installed ver 1.0 and CE 6.0(+SP1) on my Vista machine. COMinterpop exception prevents me from making a new project from VS2005. I installed on two machine and both shows the same symptom. Not installed WM 6 SDK or anything because 2003 devices are by default. What could be wrong? Is there anything similar symptom?

  15. Anonymous says:

    JP,

    Start by double checking on the following. Make sure you have VS 2005, VS 2005 SP1, and the Vista Patch also. Remember: VS 2005 SP1 Update for Vista (http://support.microsoft.com/kb/929470) Requires VS 2005 SP1.

  16. Anonymous says:

    Hi,

    I’m try to install the RTF 1.0 on my computer, but after few seconds the install process breaks and I got following error message in a box: "An installation for Microsoft Visual Studio 2005 Professional Edition – ENU is currently suspended. You must undo the changes made by that installation to continue. Do you want to undo those changes?" (Yes/No). (Error Code 1704)

    Whats wrong?

    I have installed

    Windows XP SP2

    Visual Studio 2005 Professional Edition ENU SP1 (8.0.50727.42

    .NET Compact Framework 2.0

    Windows Mobile 5.0 Pocket PC SDK

    Bye

    Andreas

  17. ce_base says:

    It sounds like there’s something incomplete about your VS2005 install.  I’d try using Add/Remove Programs to inspect your VS2005 install — perhaps try adding or removing a small feature from your VS install to see what happens.  Or try doing a repair (which will take a lot longer, unfortunately).  Or say "yes" when it asks you to undo the VS2005 changes…  Sorry, those are the only suggestions I know.

    Good luck,

    Sue

  18. dropthedrum says:

    Hello,

    Does Windows CE support RDP, or any other type of remote desktop connection.

    Thank You,

    Paul

  19. ce_base says:

    Please don’t post miscellaneous questions on our blog.  You can ask questions on our newsgroups, such as microsoft.public.windowsce.platbuilder.

    Windows CE has RDP as an option that OEMs can add to their platforms.  If you are not an OEM and if the OEM did not add RDP to their platform then you cannot install it.  I don’t think Windows Mobile includes RDP.

    Sue