How to dynamically load SDK from Milestone Bin folder

Hi,

Our company currently has a video integration that utilises the Milestone MIPS SDK. Currently our integration references dll files from the SDK and includes these files with our installer. This means that customers must only install our integration for the video integration to work as we are essentially shipping the Milestone SDK with our product.

The downside of this is that we must re-release our integration each time a new SDK is released by Milestone. Ideally what we would like is for customers to be able to install the SDK version that matches the Milestone server they are running (likely by running the MIPS SDK redistributable installer) and for our integration to dynamically load the SDK dlls from this location rather than shipping with the milestone SDK that we compiled against. This has however proved problematic as the Milestone SDK does not seem to be installing dlls into the .net global assembly cache and I cannot seem to find another way of reliably loading these dlls at runtime.

Our business team mentioned that they had heard from the market that Milestone integrators may have solved this issue in another way… Are you or your development team aware of any other options that may work for us here?

Hi Rob,

You are entirely right regarding the redistributables. In their current state they cannot be used the way you want. It is something we are considering to change, but currently it is not possible. Among other things due to dependencies on unmanaged dlls that cannot be registered in the GAC.

That said we do not recommend the approach you describe. There is no need for keeping the SDK version and the server version aligned. The MIP SDK should be both back- and forward compatible, meaning that your integration should work with newer versions of the servers as well. So there is really not any reason to update your integration to a newer version of the SDK unless you want to utilize new functionality introduced in later releases.

Best regards,

Peter