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 https://www.microsoft.com/downloads and then search for "Remote Tools Framework".
Cheers!
Dave Edson
Remote Tools Framework Guy
Comments
- Anonymous
June 05, 2007
Is this for CE6 only, or can it be used with CE5? - Anonymous
June 06, 2007
The comment has been removed - Anonymous
June 06, 2007
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 - Anonymous
June 06, 2007
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 - Anonymous
June 06, 2007
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 - Anonymous
June 06, 2007
Great. I meant to also ask: will this work on headless devices? Is it just using corecon? - Anonymous
June 06, 2007
The comment has been removed - Anonymous
June 06, 2007
The comment has been removed - Anonymous
June 06, 2007
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 - Anonymous
June 06, 2007
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". - Anonymous
June 06, 2007
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 SadahiroProgram Manager, Remote ToolsMicrosoft Corporation - Anonymous
June 13, 2007
Is it also possible to create a C# device side for CF 2.0 for the add-in?ThanksMartin - Anonymous
June 14, 2007
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. - Anonymous
June 17, 2007
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? - Anonymous
June 18, 2007
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. - Anonymous
July 06, 2007
The comment has been removed - Anonymous
July 09, 2007
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 - Anonymous
July 24, 2007
Hello,Does Windows CE support RDP, or any other type of remote desktop connection.Thank You,Paul - Anonymous
July 30, 2007
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