Upgrading to 2016 MIP SDK

MIP
1

I’m attempting to upgrade to the 2016 R3 MIP SDK. I need to be able to build an x86 application.

In preparation, I’ve tried building the “VideoViewer” example that comes with the SDK as an x86 application and am getting various compile and/or runtime errors such as “BadImageFormatException” and “Could not load file or assembly VideoOS.Platform.SDK.UI”.

Is it possible to build this (and other) application in 32-bit mode? If so, what MIP downloads do I need to install on my machine in order to do so?

Thanks.

2

See (https://force.milestonesys.com/support/articles/en_US/How_To/Processor-architecture-compatibility-for-the-Milestone-Integration-Platform-MIP-SDK)

3

Thanks again for your help.

After reading the article, my problem may be that I’ve managed to install both the 32 and 64 bit versions of the 2016 MIP SDK on m machine. I’ll try cleaning everything off and re-install only the redistributable x86 installer.

Again I can build/run the ComponentSamples in 64-bit mode with no trouble. It’s only when I try to build a 32-bit application that I have trouble.

4

In your project you need to exchange the referenced Videoos.x.x. dlls, build (release) 32 bit and need to replace the dependent dll files with the ones from the 32 bit redistributable package.

See (https://force.milestonesys.com/support/articles/en_US/How_To/Dependent-files-in-MIP-SDK)

Are you using the newest versions? What version is the redistributable MIP SDK?

5

I believe I’ve replaced the references in my project so that they are pointing to the correct, 32-bit, MIP 2016 dlls. I’m using the 2016R3 x86 version of the MIP SDK.

FYI, in the “VideoViewer” example I’m attempting to build, there’s a post-build action that calls the CopyImageViewerActiveX.bat file to copy a number of dlls into the projects target directory. Is this command needed?

Thanks again for your advice and patience!

6

No, the command is not needed, but you need to have something in place that does “the same thing”.

You can once and for all take the dependent files and copy them to the folder where you have the executable etc, and remove the build action.

I can see how the this build action can be real bad if it continuesly copies in the original 64 bit dependent files when you attempt to replace them with the 32 bit files.

You will in your scenario need to either delete that build action or change it so that it handles the correct set of files!