locked
Binaries for ProMRDS services RRS feed

  • Question

  • ProMRDS is truly an indispensable resource for anyone using MRDS.  Trevor should get an additional boatload of MS stock options for writing this book!  For the past few months, I have been experimenting with MRDS by copying and pasting from various ProMRDS sample source files and wrapping that into my own code, and everything has worked so far.  I am now getting into the part of ProMRDS that really interests me, namely chaper 8 on simulated articulated entities.  I had to modify a few things in order to incorporate ProMRDS's TestBench service into my own 'MyTestBench' service and make the latter work.  For example, instead of calling the www.promrds.com/contracts/2007/09/jointmover.html service as is indicated in TestBench'es manifest, I had to use www.microsoft.com/contracts/2008/08/jointmover.html as that was that only assembly found in the MRDS R2 bin.  While the two jointmover are presumably similar (certainly when comparing their respective source), there are some differences.  I believe  ProMRDS's vesion is better, but I am debating if I should use that to replace its MRDS counterpart.  In order to do this, I will need the binaries.  I could recompile the jointmover source that comes with ProMRDS, but I see from the Update file that comes with the ProMRDS release that binaries should already be included and indeed copied over to the MRDS/bin directory.  That is certainly not true in my case.  I extracted the ProMRDS package following the accompanying instructions, but no binaries.  I also tried rerunning buildall.cmd that comes with ProMRDS.  All I saw was the command window briefly flashing on the screen, but nothing happened.  Assuming that I recompile jointmover using ProMRDS source, that would then overwrite the MRDS version already in the /bin directory.  Is that a good idea?  Ideally, it would be better to have all of ProMRDS's binaries in ProMRDS/bin directory, and then have a way to switch between an MRDS version and a ProMRDS version by modifying just the manifest. I know that's probably tricky to do.  I would appreciate any advice from people more familiar with ProMRDS.  
    Friday, November 20, 2009 11:23 PM

Answers

  • There are some subtle issues here that you might not be aware of.

    I am assuming of course that you know about the updated samples at http://www.promrds.com

    When we first released the ProMRDS samples, I spent a lot of time on the packaging using DssDeploy. However, that "locked in" the samples to V1.5. Naturally when V2.0 shipped (RDS 2008), people wanted updated samples. The complication was that there were two Editions -- Express and Standard/Academic. Each of these required its own DssDeploy package.

    To further compound the problem, people often wanted to place the source into a different destination folder, and the binaries are specific to a particular version of RDS due to strong naming. So I eventually decided to create a ZIP file and let people rebuild the code themselves. This means that if you downloaded the ZIP you must recompile all the code -- there are no binaries. I'm sorry if the instructions appear to imply otherwise.

    As for buildall.cmd, that has not been 100% successful. Firstly there are dependencies so the code needs to be compiled in the correct order. I find that running buildall.cmd twice usually takes care of this, but sometimes this does not work either. It depends to some extent on your particular environment. By the way, buildall.cmd is designed to be run from a DSS Command Prompt window. If you double-click on it in Windows Explorer it will not work.

    Recompiling is always a good idea, unless you only have the binaries for a service. Note that you can have two services with the same name as long as the contract identifiers are different, i.e. the month or year.

    Trevor
    Tuesday, December 1, 2009 10:19 PM