locked
DssDeploy Directory Management RRS feed

  • Question

  • I'm trying to create a deployment package (using CTP2).   I can create the package without apparent problem; however, when I try to deploy it, I'm having problems.   

    If I deploy it by just double-clicking the archive file (I'm on another node different from the computer on which the archive was created),  I get the WInForm asking me for the target directory; however, it is grayed out and I cannot select a specific target.

    If I deploy anyway, it creates a directory tree matching that on my source machine.   In both cases, I'm working with directories under the RDS root.   

    If I try to use the CL,  I can't seem to get  the proper parameters.   It tells me that I need to use the /specific CL option, but there is no documentation (I can find) and if I construct a simple /specific  option, it says it is not recognized.

    My preferred solution would allow double-clicking of the archive and selecting the target directory, with files not including the directory I use as a base (below the RDS root) copied to the designated target.   Is this something I need to deal with on the source/packaging side or is this a target side problem? 

    My packaging command is:
    ..\..\..\..\bin\dssdeploy /p /s- /cv+ /v:Verbose /n:"gptg NXT Ultrasound Collection" /r:"..\Readme.htm" @Files.txt UltrasoundCollection.exe

    One of my deployment command attempts is:
    bin\dssdeploy /u  /t:gptgDeploys  "C:\Documents and Settings\...\UltrasoundCollection.exe"  
    I'm expecting to see the WinForm to allow me to select the target location.   I get an error saying I need to use the '/specific' option.

    Suggestions appreciated.

      -Don
    Friday, August 29, 2008 11:49 PM

Answers

  • The /cv+ opertion means that the package will only deploy into an installation that matches the "current version" where you package the files. This does not allow you to select a directory when you unpack the package.

     

    When you say that it "creates a directory tree matching that on my source machine", do you mean that it creates the tree under the MRDS installation on the target machine? This is what should happen.

     

    We are making some changes to DssDeploy for V2.0. If you have any suggestions we would like to hear them now.

     

    Bear in mind that MRDS executables are strongly named and so they must be matched to the correct DLLs. If you only plan to distribute source code and let the user re-build, then this should not be a problem. However, if you want to distribute executables then it is important that we match the versions exactly.

     

    Trevor

     

     

    Saturday, August 30, 2008 4:16 AM

All replies

  • The /cv+ opertion means that the package will only deploy into an installation that matches the "current version" where you package the files. This does not allow you to select a directory when you unpack the package.

     

    When you say that it "creates a directory tree matching that on my source machine", do you mean that it creates the tree under the MRDS installation on the target machine? This is what should happen.

     

    We are making some changes to DssDeploy for V2.0. If you have any suggestions we would like to hear them now.

     

    Bear in mind that MRDS executables are strongly named and so they must be matched to the correct DLLs. If you only plan to distribute source code and let the user re-build, then this should not be a problem. However, if you want to distribute executables then it is important that we match the versions exactly.

     

    Trevor

     

     

    Saturday, August 30, 2008 4:16 AM
  • Trevor,
    Thanks for the reply.   I apparently misunderstood the meaning of cv+.   I presumed that simply meant the same version of MRDS itself (which I have), not the same file structure.   Yes, it creates the tree under the MRDS root. 

    Not sure I have any specific suggestions but a couple of areas where I struggled to achieve what I wanted were:
    (1) Above, where I wanted to deploy into a different directory (under MRDS) than exists on the source machine - could be documentation or could be overloaded implications of cv+.
    (2) In creating the package,  building the list of files would probably be helped by a wizard that provides something like D&D (along with suggestions/options for things to address specific objectives like source, simulation, ...) to build the files list.  Editing the results of a directory dump is sometimes not too obvious and error prone for things not in the specific directory.
    (3) Automatic creation of a dsshost command to run it.   Specifically, if it needs multiple manifests or other settings, creating a command line would be helpful for the non-expert user on the deployed node.  Admittedly, this may require too much magic to be achievable in reality ("just which manifests did you really want???") but it does drive to standardization. 
    (4) For many of us, the magic content of ACL's, strong naming, etc.  can be pretty high.   Anything that allievates those potholes would be helpful.

    Thx,
     --Don
    Saturday, August 30, 2008 12:36 PM
  • Trevor,
    One further suggestion (unless I'm again misinterpreting an existing option).   When I unpack into the users target directory (whose name Imay not know at build time),  MRDS creates a containing directory in the package that corresponds to the name of the directory immediately under the root of MRDS on the build machine.   That is often a local name.   It would be good to be able to specify a containing directory which is essentially a more 'innocuous' name in which the build is packaged.  

    On the deployment side, it might also be useful to be able to specify a replacement for the containing directory - essentially, move the entire structure up one level in the hierarchy eliminating the name used as the top level of the package.  If done, the system should check and ask if that is what is meant in the case where the target directory is non-empty.

      --Don
    Saturday, August 30, 2008 1:10 PM