Nick Gunn

I couldn't find this in the forums, and it might help someone...

If you want to run dss services within a custom host/node e.g. a service, then you need to make sure that the MSRS DssHost.exe is in the same directory as your exe. This seems to remove the requirement that you run your host within the MSRS directory.

This was with the May 1.5 CTP.

Managed to get a WPF application up and running with the DSS runtime inside.



Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Omid K. Rad

Actually, DssHost.exe is itself a utility app that references the DssEnvironment.dll assembly. So your hosting app should be independent of DssHost.exe and needs only use the DssEnvironment class.

It's interesting to hear you're doing rich UI over Dss Smile





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Nick Gunn

That's what I thought, but I couldn't get it to work. When I reflected over the the code listed in the exception's stack, I found a static class called LayoutPaths whose initialisation fails if it can't find certain executables.

Also, this failure just results in DssEnvironment.Initialize() failing to return, which wasn't so good.

Hopefully, both will be addressed in a forthcoming release.





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Henrik F Nielsen

Nick,

We have updated the DssEnvironment API to make it more consistent and also provided four new hosting tutorials that show how to use it available at [1]

Henrik

[1] http://msdn2.microsoft.com/en-us/library/bb643214.aspx






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.







Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Henrik F Nielsen

James,

I am looking for your detailed description of the error you see when creating a DssEnvironment but couldn't find it

You absolutely don't need all apps to be in the same folder but you are right that if you want the clients to subscribe to other services then it is easiest to host the DssEnvironment -- otherwise you just have to implement DSSP yourself which I don't think is worth it in your situation.

As to the DLLs you need to copy over, this base list should do:

  • dssenvironment.dll
  • ccr.core.dll
  • ccr.adapters.winforms.dll
  • dssbase.dll
  • dssruntime.dll
  • dssruntime.proxy.dll
  • dssruntime.transform.dll

Let me know how it goes - we do want to see you unstuck.

Henrik






Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Zinaida

Hello Henrik,

I created very simple application which hosting Dss node. My .exe file is not in MSRS bin folder. I copied over all dll's to where is my .exe file:

  • dssenvironment.dll
  • ccr.core.dll
  • ccr.adapters.winforms.dll
  • dssbase.dll
  • dssruntime.dll
  • dssruntime.proxy.dll
  • dssruntime.transform.dll

Added those dlls to References list in my C# project. When the application starts I got:

Unable to locate the MSRS installation directory.

Could you help me with that

Thanks

Zinaida





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

George Chrysanthakopoulos

Hi, for us to accept a custom host the following conditions must be met (we will update the docs to make this clear)

1) your host must be in a directory called \bin (like our dsshost)

2) the list of dlls you mention above must be in that same directory

3) dsshost.exe (even if you dont use it) must also be there

for 2.0 we will relax some of these requirements





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Zinaida

I had all in \bin folder except dsshost.exe. Now it works.

Thanks adain.





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Zinaida

Hi,

I hurried to say it works. I didn't get that message, but it steel doesn't work. Do you have working example when a host is NOT in MSRS\bin folder

I relocated hosting tutorial1 to my folder, created \bin folder and copied over all dlls, my exe and dsshost.exe there.

In project properties I changed Reference paths to my \bin.

This is what I got:

Rebuilding contract directory cache. This will take a few moments ...
Contract directory cache refresh complete
Rebuilding contract directory cache. This will take a few moments ...
Contract directory cache refresh complete

I did the same for my prototype and got the same result.

Thanks





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Stephen Bogner

I have been able to write a Windows Application to create and manage a DSS Host, although some issues remain and a fair bit of work is still needed to make it robust and worth sharing...

In addition to copying the specified ccr*.* and dds*.* files into the executable directory (debug or release, according to the default VS behaviour) as mentioned above, I found that it was also necessary to create a /store subdirectory below the directory that contains the executables, and to copy (and edit) the contractDirectory.state.xml file as well, so that it points to the desired executable directory, rather than

<string>C:\Microsoft Robotics Studio (1.5)\bin\</string>

I also find it awkward to compile everything into a central \bin directory. I think it would be cleaner to use a "meta-manifest" to list all of the service locations that are relevant to me for a given instantiation of the host, so that only the services that I really care about are reported in the control panel, for example. That would let me keep all of the code for a service in a tight directory structure that does not have "outliers" or non-standard deployment modalities. XCopy deployment of an individual service should just work. Sure, a person can figure out the special setups needed to make things work if he has to, but why not do things the way people expect - or that the tool (Visual Studio) normally tries to enforce At the very least, if it simply has to do something in a non-standard way then I think that needs to be explained (and maybe even justified)...

Steve.





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

George Chrysanthakopoulos

Hi stephen, DssDeploy creates that meta-manifest and allows you to have a pure Xcopy deployment. You give it a manifest, and it analyzes all your services dependancies, all their state files they need, plus any additional files you want, and then creates a single, self-deployment EXE that recreates the directory structure with all the binaries required!

It works on manifests (but they can have a single entry since we parse it for any additional dependencies), not custom hosts however





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Zinaida

Hi,

I fixed my problem. To run your hosting application from your folder(it can be any folder, not just \bin) you need to copy over all dlls from the list above plus Microsoft.Cci.dll. You can find that list of dlls in C:\Microsoft Robotics Studio (1.5)\runtime.txt file.

Stephen,

You do not need to create \store directory and copy (and edit) the contractDirectory.state.xml. It's done when you run your application at the first time.

Thanks everybody!





Re: Microsoft Robotics - Decentralized Software Services (DSS) Hosting DSS in other (custom) hosts

Zinaida

It's me again. There is a small correction in my post above. Your executable and all dlls have to be in your \bin folder.

Thanks