This project is read-only.

Allowed to extend MSE toolbase?

Topics: Technical Questions, Usage Scenarios
Aug 6, 2009 at 11:14 AM
Edited Aug 6, 2009 at 11:25 AM


I was wondering how you look upon extending the "toolbase" of MSE by calling into the binaries available? Lets take a very standard example: Scripting the deployment of backup files. This is easily done by peeking into Microsoft.MSE.Tools.ArchiverModule.dll and using the existing classes and methods, but is it "frowned upon" to post any findings, screenshots, code etc. here?

Best regards

Aug 6, 2009 at 3:14 PM

In general the biggest concern would be around compatibility between releases, for this the Catalog Service is the preferred path for building out your own capabilities since we are a bit more cautious about changing/removing operations. 

As long as you are only using public classes and methods in the assemblies and state the release you used, I don't see a problem.

The most common use of additional api's that make life easier are: 

  • *ArchiverModule (used by the MSEArchiver command line tool).
  • *ConfigurationDesigner (IDataMashaller interface) - for custom Assertion UI Designers - so when you configure an Assertion you don't have to look at XAML in the Model Viewer. (look at the precreated designers for XSLT and ServiceDebug assertions.)
  • *WizardFramework for creating your own metadata import wizards.
  • *ChannelModel - Embedded in the Resource Moniker, used for taking control of ChannelFactory/Binding creation to invoke a resource.  (We are trying to move away from using this though.)

Again, each of these would have a certain risk of compatibility challenges in future releases since we do reserve the right to change them.