通过

Running the XPS System.Security.RightsManagement SDK samples - What I learned.

  • 项目

So I recently had a customer call me regarding the XPS SDK samples. (Make sure you setup your pre-production environment according to the SDK instructions.) I had all kinds of E_DRM_MANIFEST_POLICY_VIOLATION troubles, but here is how I got around it.

The samples can be downloaded from here:

https://download.microsoft.com/download/f/6/e/f6e32974-726e-4054-96af-9c747bf89a6e/RightsManagedPackagePublish.exe

https://download.microsoft.com/download/f/6/e/f6e32974-726e-4054-96af-9c747bf89a6e/RightsManagedPackageViewer.exe

(Make sure you have .NET 3.0 installed on your Dev box or you will get an error about the microsoft.WinFX.targets file missing (Hint: On Vista you need to turn this on through the control panel))

1. When running in debug mode you need to create a signed manifest for your app.vshost.exe, after each build. I did this by creating a .cmd file named makedmanifest.cmd with the following included in it (make sure you put all of your ISVTest certs in your output directory (i.e. /obj/Debug, obj/Release)):

Genmanifest –chain ISVTierAppSignSDK_Client.xml dmanifest.mcf manifest.xml

 

I created a file called dmanifest.mcf and added the following to it (which is different than what the sample docs tell you to do):

 

AUTO-GUID

 

ISVTier5AppSigningPrivKey.dat

 

MODULELIST
   REQ HASH RmPackagePublish.vshost.exe

 

POLICYLIST
   INCLUSION
      PUBLICKEY   ISVTier5AppSigningPubKey.dat

 

EXCLUSION

 

I then went into my Project >Properties>Build Events and added makedmanifest.cmd to the post-build events command line.

 

Also, to make things easier on myself I went to Project > Properties > Build and set the output path to \obj\Debug, to simplify the post-build command to just the makedmanifest.cmd command instead of having to put in the whole path to the file.

 

2. When running the standalone bits you need to replace the app.vshost.exe in the mcf, with just the app.exe. So I just created a makermanifest.cmd, and a rmanifest.mcf file that use the actual .exe that I can run when I just want to run the standalone .exe.

 

3. I had some manifest policy violation issues, that turned out to be a red-herring. I had to replace the TestTier certs, as the ones I was using were apparently corrupted.

 

4. It is probably better to use the applications path to place the manifest file in, instead of c:\. You can do this by setting something like:

 

String manifestloc = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location.ToString()) + “\\manifest.xml”;

 

..then pass this value in the code each place (2) where it asks for the rvc.xml file.

 

5. If you want to use the XPSViewer that ships with the .NET 3.0 redist in a Pre-Production environment, you can go to C:\Windows\System32\XPSViewer and replace its manifest, by signing the .exe the same way we did above. Just create a .mcf file replacing the app.exe with XPSViewer.exe, and run genmanifest on it using the name of the manifest file found in the XPSViewers directory. You should be able to use this to open the output of this SDK app (or you can compile and run the viewer app).

Hope this save someone some time down the road. I didn't run the viewer SDK sample yet, but I'm sure it will work the same way.

Thanks to Pankaj one of our RMS devs for doing a sanity check, and figuring out the bad cert problem, and for being awake late at night..like I usually am.

UPDATE: I just tested the RMPackageViewer sample and, as expected, following this guide it worked well.

MERRY CHRISTMAS EVERYONE!!!

-Jason

Comments