I’ve been dealing with several Milestone reference issues for the past few days.
I have a project “A” which contains references to Milestone SDK dlls. I then have a project “B”, which references project “A”. However, my Project B also contains a reference to Autofac via a nuget package. When I build the solution, the VideoOS dlls are copied into Project B’s bin directory. The VideoOS dlls include their own dependent Autofac.dll, which overwrites the Autofac.dll that I installed for Project B via nuget. This causes my application to throw a runtime exception that the Autofac manifest does not match the expected values.
Is there a better way to reference Milestone’s SDK without copying the DLL’s into my app’s bin directory? I experimented with setting “Copy Local” to “False” in Visual Studio for various combinations and permutations, but I just get different reference errors.
Further, is there a way that I can load all of the VideoOS dependencies into the Windows GAC instead of keeping them in the bin directory of my application? I think that might solve the problem but I’m not sure.
Thanks for any help!
Generally the dll’s just need to be available in the search path for your application. What that is will depend on you system and VS setup. But the simplest way is typically to have them copied to the same folder as the application.
You can try register the VideoOS dll’s in you Windows GAC, but due to unmanaged dll’s required I doubt you will get it to work - at least we don’t have any experience with it.
Wouldn’t it be possible for you to use the same version of Autofac as we are? Or alternatively there might be an option in VS to only copy if newer, but I’m not too familiar with that.
You’re right that the GAC approach is problematic. Many of the assemblies don’t have assembly manifests, so I’d have to add manifests to them before I could event put them in the GAC, and probably only after signing them with my own company’s keypair which wouldn’t be ideal.
Speaking of which, I also discovered that one of the assemblies (VideoOS.Platform.SDK.Log) doesn’t have a strong name at all, AKA it’s not signed by Milestone. This affects the security of anyone who consumes that assembly from Milestone’s SDK.
To verify this yourself, open the Developer Command Prompt for VS 2019 and run:
gacutil /i "C:\Program Files\Milestone\MIPSDK\Bin\VideoOS.Platform.SDK.Log.dll"
You can also use ildasm.exe to see that there’s no public key entry.
Is there a good reason why Milestone is releasing unsigned .dlls?
I’m going to look into Andriy’s suggestion of using assembly redirects. Although in general, as a piece of developer feedback, solving these .dll hell issues would be a major improvement for Milestone. Or if the SDK installer just had an option to install the SDK to the GAC, it would really simplify everything for developers.
Hi again John,
Regarding VideoOS.Platform.SDK.Log this is obviously something we have overlooked. We will fix it for the next release. Thanks for making us aware.
Best regards,
Peter
Hi John. If you manually copy the version of Autofac from your project B after build, does the Milestone SDK still work with this? I think you should then setup the assembly redirect, to redirect the references to older version of this Assembly to use your version.
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions