locked
How to direct DssDeploy where to put files? RRS feed

  • Question

  • I hope I am just missing something obvious, but I’m getting confused with DssDeploy.  My development environment looks different than what I want the production environment to look like.  I see how to add components with the “/d” option, but when I do this the deploy package creates a directory structure just like my development environment on the deployed machine.  I don’t see how to specify a different location.


    My development environment looks like this:

     

    [root] = “C:\Microsoft Robotics Studio (1.5)”

     

    [root]\Projects\MySolutionFolder

        MyThirdParty01.dll

        MyThirdParty02.dll

        MyThirdParty03.dll

        MySolutionReadMe.htm

     

    [root]\Projects\MySolutionFolder\MyProjectAFolder

        MyProjectA.manifest.xml

     

    [root]\Projects\MySolutionFolder\MyProjectAFolder\Proxy\Obj\Debug

        MyProjectA.Y2008.M04.Proxy.dll

     

    [root]\Projects\MySolutionFolder\MyProjectAFolder\Obj\Release

        MyProjectA.Y2008.M04.dll

     

    [root]\Projects\MySolutionFolder\MyProjectBFolder

        MyProjectB.manifest.xml

        MyProjectBInitialPartner.xml

        MyThirdParty01Datafile.Omp

        MyThirdParty01Datafile.Ops

     

    [root]\Projects\MySolutionFolder\MyProjectBFolder\Proxy\Obj\Debug

        MyProjectB.Y2008.M04.Proxy.dll

     

    [root]\Projects\MySolutionFolder\MyProjectBFolder\Obj\Release

        MyProjectB.Y2008.M04.dll

     

    The DssDeploy is putting everything from the projects folder into identical paths that it creates on the deployment machine and the read me file into the equivalent solution folder.

     

    Like this:

     

    [root]\Projects\MySolutionFolder

        MySolutionReadMe.htm

     

    [root]\Projects\MySolutionFolder\MyProjectAFolder

        MyProjectA.manifest.xml

     

    [root]\Projects\MySolutionFolder\MyProjectBFolder

        MyProjectB.manifest.xml

        MyProjectBInitialPartner.xml

        MyThirdParty01Datafile.Omp

        MyThirdParty01Datafile.Ops

     

    According to “Microsoft Robotics Studio Partner Program (MSRSPP) Guide” (http://msdn.microsoft.com/en-us/robotics/bb383567.aspx)

     

    The manifest files and the InitalPartner file should go into “samples\config”.  I’m not real sure where the third party data files or the readme file should go.

     

    I thought I might re-create the desired deployment file structure on my development machine and manually copy the files after each build before I run DssDeploy, but I can’t believe this is standard operating procedure, so I must assume I’m missing something.

     

    Any help or pointers will be appreciated.

     

    Thanks,

    Dogulas

     

     

    Monday, June 9, 2008 4:39 PM

Answers

  • Sorry for the delayed response.

     

    DssDeploy replicates the directory structure of its input. So you are doing the right thing by creating a different layout before running dssdeploy.

     

    Andreas
    Friday, June 13, 2008 11:40 PM
  • Hi Dogulas,

     

    Not ignoring you -- just waiting for somebody else to jump in.

     

    For our book, we created exactly the file structure that we wanted and then built a DssDeploy package from that. This is what you are doing now.

     

    As far as testing is concerned, that is relatively easy. Just blow away the "live" hierarchy. It gets a little more complicated with the bin folder where you have to explictly remove the DLLs. However, this is only necessary if you add or remove services, or change their contract ids. Running DssDeploy will overwrite existing DLLs anyway.

     

    I build my DssDeploy packages using a batch script. I suppose the script could also clean up, although I usually do this by hand since I only have to delete one directory tree.

     

    For "surgical" replacements, my batch script allows me to build just one chapter out of the book. Then I can just run an individual chapter DssDeploy package to update only one part of the book code. Kyle and I exchanged chapters this way too.

     

    The way that DssDeploy works means that the packages do not appear in the "Add / Remove Programs" list. An inventory of the files is automatically created in the Packages folder under the MRDS root as a HTML file, so you can see what was installed. However, I agree that an uninstall is desirable.

     

    Finally, there is a tool written by Paul Roberts that allows you to examine the contents of a DssDeploy package. Obviously you don't need to do this if you created the package! But it is useful when you are about to install a package that you got from somebody else. Have a look on Channel 9 for program. It's called ViewDssDeployContents.

     

    Trevor

     

    Friday, June 13, 2008 11:50 PM
  • I asked the MRDS question off hand.  After a quick check in these forums, I easily found the answer.

     

    Thursday, June 19, 2008 11:29 AM

All replies

  • Since I haven’t heard any feedback, suggestions, or commiserations, I decided to stumble forward.

     

    I had to create the file structure on my development machine that duplicates the file structure that I want to see deployed.  I then copied my project to this new location.  This means that I cannot deploy to the same machine that I develop on and need a second machine with MSRS installed just to test the deploy package.  This also means that I have a manual copy step after each compile to move the stuff that goes into the samples\Config directory.  I feel it shouldn’t be this hard so I must be doing something wrong.  If anyone has gone through this before, I’d love to know what you did differently.

     

    Dogulas

     

    Wednesday, June 11, 2008 1:28 PM
  • helloooo?

    Friday, June 13, 2008 7:32 PM
  • Sorry for the delayed response.

     

    DssDeploy replicates the directory structure of its input. So you are doing the right thing by creating a different layout before running dssdeploy.

     

    Andreas
    Friday, June 13, 2008 11:40 PM
  • Hi Dogulas,

     

    Not ignoring you -- just waiting for somebody else to jump in.

     

    For our book, we created exactly the file structure that we wanted and then built a DssDeploy package from that. This is what you are doing now.

     

    As far as testing is concerned, that is relatively easy. Just blow away the "live" hierarchy. It gets a little more complicated with the bin folder where you have to explictly remove the DLLs. However, this is only necessary if you add or remove services, or change their contract ids. Running DssDeploy will overwrite existing DLLs anyway.

     

    I build my DssDeploy packages using a batch script. I suppose the script could also clean up, although I usually do this by hand since I only have to delete one directory tree.

     

    For "surgical" replacements, my batch script allows me to build just one chapter out of the book. Then I can just run an individual chapter DssDeploy package to update only one part of the book code. Kyle and I exchanged chapters this way too.

     

    The way that DssDeploy works means that the packages do not appear in the "Add / Remove Programs" list. An inventory of the files is automatically created in the Packages folder under the MRDS root as a HTML file, so you can see what was installed. However, I agree that an uninstall is desirable.

     

    Finally, there is a tool written by Paul Roberts that allows you to examine the contents of a DssDeploy package. Obviously you don't need to do this if you created the package! But it is useful when you are about to install a package that you got from somebody else. Have a look on Channel 9 for program. It's called ViewDssDeployContents.

     

    Trevor

     

    Friday, June 13, 2008 11:50 PM
  • Thank you Andreas and Trevor,

     

    Glad to know I wasn't missing anything.

     

    Trevor, got you book.  Nice!  It just arrived today.  The first thing I looked up was DssDeploy and was not disappointed.

     

    I was originally thinking about writing an app that simply removed the files that I knew were placed by DssDeploy, but I abandoned that idea because I realized I had no knowledge of what it was doing under the hood.  For all I knew it was writing all sorts of registry entries.  I just felt it was safer to do nothing.

     

    Thanks guys

     

    Tuesday, June 17, 2008 12:34 AM
  • Hi Dogulas,

     

    Looks like Andreas and I crossed our postings :-)

     

    Glad to hear you got the book :-)  I'm still waiting for mine. I guess it takes longer 'cause I live half a world away.

     

    As for DssDeploy, it is a very "low impact" installer. It does not go creating heaps of registry entries. Neither does MRDS for that matter.

     

    Depending on the options you use for DssDeploy, it might take a whole MRDS runtime system with it. This allows you to deploy to computers where MRDS is not currently deployed and ensure that all of the DLLs are the right versions. You probably realise already that MRDS uses strong naming, so it is important to get versions right.

     

    However, if you can do it, I would suggest installing MRDS on the target machine and then only shipping the source and necessary binaries. You will have to explicitly specify the DLLs for your services this way, but you can easily include multiple services in the same package because they are just extra entries in the options file. The advantage of this approach is smaller packages and you can easily subset the files if you want to make a minor update. The disadvantage is that you have to keep all the machines in synch with the same version of MRDS, but it does not change all that often.

     

    Of course, if you want a "turnkey" solution you can let DssDeploy figure out the dependencies and just copy all of the necessary DLLs with no source. Just be careful if you ship this to customers. For instance, DssDeploy only installs into exactly the same version of MRDS so they might get confused if it creates a brand-new installation with a different version from the one they are running. This is an issue right now with the April CTP of V2.0 and our book code packaged for V1.5.

     

    Trevor

    Tuesday, June 17, 2008 5:00 AM
  • Thanks Trever,

     

    Since my application is a component and not meant to be a complete solution, I packaged it without the full MRDS install.  I did, however, make 1.5 a prerequisite.  Speaking of 2.0, any idea when it will be released in production?

     

    Also, I noticed throughout your book you refer to it as MRDS, but I have seen it refered to as MSRS.  Are these synonamous or has there been an official name change?

     

    Thanks,

    Dogulas

     

    Tuesday, June 17, 2008 8:53 PM
  • I asked the MRDS question off hand.  After a quick check in these forums, I easily found the answer.

     

    Thursday, June 19, 2008 11:29 AM