InedoSDK Documentation

Creating an Extension using the SDK

  • Last Modified: 2020-06-24

An Inedo Extension is a .NET library that implements certain abstract classes defined in the Inedo.SDK library, and is packaged in a zip file.

There are two ways to get started with the Inedo SDK:

This documentation will assume you're using Visual Studio and NuGet to create an extension. For a complete type reference of the SDK, please visit the Inedo SDK Reference.

Creating the Project

First, create a new class library project in Visual Studio, and target .NET 4.5.2. Use NuGet to add a reference to the Inedo.SDK package.

Make sure that the SDK assemblies added by the NuGet package have the Copy Local property set to False. SDK assemblies should not be included in the extension.

Creating and Adding Components

After creating your project, you can start creating classes that inherit from extensible components.

See Writing a Simple Create File Operation.

Building and Deploying the Extension

Once you've added all the desired components, and your project compiles, it is now ready to be packaged as an extension, and deployed to your Inedo product.

Direct Deployment

An extension can be directly deployed to an Inedo product's extension root as a simple universal package.

To do for an extension named MyExample, first create a manifest file called upack.json with the following contents:

  "name": "MyExample",
  "version": "1.0.1"

Then, create a zip file called with the compiled output in a package folder, and the upack.json at the root, like this:


Rename the the zip file to MyExample.upack, and copy the .upack file into the Product extensions directory. By default, this will usually be in C:\ProgramData\«product-name»\Extensions, but you can verify the exact location by going to the Admin->All Settings page and looking for the ExtensionsPath value.

Finally, restart the product services (and application pool if hosting in IIS).

Extension Gallery Deployment

You can also package extensions in a universal package, deploy them to a ProGet feed, and configure your Inedo product to use your private feed instead. Such a package has three metadata requirements:

  • group - must be "inedox"
  • name - must be the same name as the assembly name
  • _inedoSdkVersion - this additional property must be present, and a string with the three-party version number of the Inedo SDK used to build the extension

You can also specify property named _inedoProducts that is an array comprised of:

  • string values; BuildMaster, Otter, Hedgehog, or ProGet
  • object values; a key/value pair with the product name and a string semantic version, representing the SDK version compatibility

For example, the metadata for an assembly named MyExample.dll might look like this:

  "group": "inedox",
  "name": "MyExample",
  "version": "1.0.1",
  "_inedoSdkVersion": "1.4.0",
  "_inedoProducts": [ "BuildMaster", { "Otter": "1.2.0" } ]

Note that the _inedoSdkVersion and _inedoProducts properties are only used for filtering what's shown on the Extensions page in the product. If the values are specified incorrectly, the extension may still be downloadable yet unloadable.

Verifying and Testing the Extension

On the Admin > Extensions page, you should now see your custom extension. If you click on it, you will be shown all the types that are loaded by the product. These types should appear in the appropriate parts of the software.

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit 7dc9c9e6 on master