The Milestone Integration Platform SDK, or MIP SDK, is available to the public at no cost. The installer includes the .NET libraries, documentation, samples and tools.
A common development pattern for a MIP SDK project is to install MIP SDK, create a new Visual Studio project using the available MIP templates, or create a new project and manually add the necessary references.
Depending on the type of project, there may be additional native assemblies to copy to the build directory, so you need to gather those or preferably use one of the provided Copy*.bat files to copy the right DLLs to the output path. Normally you’d want to point to these bat files in the post-build action of your project to ensure the right DLLs are copied at build time.
This process works, but has the following drawbacks…
- The MIP SDK or at least the redistributable SDK must be installed so that you have the necessary DLLs to compile component or plug-in projects.
- If you need to recompile with a different version of the SDK, you need to download and install a different MIP SDK version, or update your project references to point to some repository you might have setup to store the bin files for different SDK versions. Don’t forget to update your post-build script to copy the right native assemblies!
- If you’re collaborating with multiple developers, you should all have the same SDK version installed or align on some other process to ensure the project references don’t break when opening the same project on two different systems.
- If a hotfix/patch is released for a part of the SDK, you need to figure out how to make sure everyone is using the updated SDK components.
Without NuGet, the best way to get close to solving the above issues is to create a shared repository of MIP SDK binaries, with each SDK version separated into different subfolders. Then maybe have a pre-build event to copy the right DLLs to a local folder if they’re different, and have the post-build event run the Copy*.bat file(s) needed to ensure everything makes it into the output path.
Instead of trying to build an elaborate process to address the issues above, I’ve compiled a list of NuGet packages based on the 2019 R2 version of Milestone’s MIP SDK redistributable binaries.
I broke these out into several different packages in order to keep them small. Most of them, with the exception of the Transact, ConfigurationAPI and Management packages, have a dependency on Cascadia.VideoOS.Platform.SDK. That means if you install the Media package, you’ll automatically get the base package as well.
Each package is configured to ensure all necessary DLLs are automatically copied to the output path at build time. So if you’re using the Media or Export packages, you needn’t worry about setting up a post-build action or other mechanism to ensure you have the right DLLs.
Since I’m merely repackaging the redistributable DLLs, I named Milestone Systems A/S as the Owner, and myself as the package author. The Project URL for each of these packages points you to the online MIP SDK documentation. A common convention for NuGet package name/IDs is to use the namespace for the library in the package. But there’s a good chance Milestone will release an official set of NuGet packages in the future and I didn’t want to “steal” the VideoOS.* package names. For this reason, I prefixed each package with Cascadia, which has the added benefit of helping to highlight the fact that this is an unofficial set of packages which people should use at their own risk.
If you find these useful or have suggestions for improvements, please send me a message as I’d love your feedback!