Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts
James Chaldecott (OXINST)
AFAICT, those tutorials don't actually address (or document) this problem.
In fact, if you start with the "console app" template and not the "DSS Hosting" template, then following the instructions in Tutorial 1 doesn't give you a working DSS host, it gives you this exact error. I've posted detailed feedback to MSDN, but I thought I'd bring it up here, too.
This could actually be a bit of a problem for me.
What I'd really like to do is something like up simple client-server (same PC) with DSS. I don't want to use DSS internally on the client end, just the minimum amount of code to talk to DSS services in the server process (and set-up subscriptions). I think that means the clients have to host the whole DSS environment as well, though.
Edit: I originally put more details [1] in-line here.
If all my client programs have to be in the same directory, it would be a bit of a killer. I really don't like the idea of completely independant client programs all having to be deployed to the same place for them to work. Just the sheer volume of little test harnesses that would end up in there (on a dev box) would feel uncomfortable.
I was starting to think I might need to use WCF instead of DSS for client-server comms, and I think this is going to seal the deal.
So that just leaves my system service (that is still hosting DSS). How much of the MSRS stuff really needs to be there for it to work properly from a directory other than the original installation directory Can I just get away with dropping in DssHost.exe or DssProxy.exe, as Reflector seems to indicate.
Cheers,
James
[1]
I'm planning to have a system service (always running) that hosts the DSS runtime, and contains a bunch of DSS services that interface with various hardware devices. These are not what you might "traditionally" call robots, but they fit the programming model fairly well. The most important function of these services (from an application perspective) is to deliver (fairly large volumes of) data asynchronously to client programs.
There will be a much larger body of "application" code that exists entirely outside of the MSRS domain, that is more to do with data storage, processing, rich UI, etc, etc. I was originally hoping that this code could talk directly to the services via DSS. As I understand it, though, if I want a client to subscribe to notifications from a DSS service, the client has to host an instance of the DssEnvironment, as well.