Pelco Developer Network (PDN)

VideoXpert SDK APP

How to field an VideoXpert SDK app.

Installed VS2013 on a machine and compiled the c# sample. Went to the bin\debug\x86 directory on the dev machine and launched the program. Runs.. Installed the SDK on another machine, copied the entire sample directory over to same paths, add the paths to the system path, but the EXE will not launch. Error says File not found, CSharpWrapper or one of it's dependencies. The correct files are in the bin directory, because it runs fine on the other machine. What are the dependencies for CSharpwrapper? I assume its trying to load something else when it gets loaded. . I have used the Pelco SDK and the DS series SDK and never had this problem.. The wrapper DLL, VX DLL, Mediacontrol DLL, and the cppRest dll's exist in the exe directory. How does one field a product written in the VideoXpertSDK?

It's possible to use depends.exe in order to examine a dll and see what dependencies are missing on a file. That is a good place to start.

Specific to your question, it sounds like another GStreamer path issue. The dependencies for the sample projects go like this: C# Sample -> CSharpWrapper -> MediaController -> GStreamer. The sample copies what it needs from the local projects except for GStreamer. Since it is fairly large, instead we add the GStreamer location to the path at runtime, like this:

var currentPath = new System.IO.DirectoryInfo(Application.ExecutablePath);
var rootSamplePath = currentPath.Parent.Parent.Parent.Parent.Parent.Parent.FullName;
const string PathFormat = "{0}\\MediaController\\ThirdParty\\GStreamer\\1.8.1\\{1}\\gstreamer_runtime\\bin";
var gstreamerPath = new System.IO.DirectoryInfo(string.Format(PathFormat, rootSamplePath, processType));

When you state that you copied over the entire sample directory, we're assuming you mean the C# directory. If so, it means that the GStreamer files are not present since they are located in the MediaController project and not in the CSharpSample directory. If things compile and you are getting only black video, then the core assemblies are not being found in the bin directory. Those are direct dependencies so MediaController would be unable to load without them. If you see black video then that means that the bin files are present, but when GStreamer tries to load a plugin it can't be found since the plugins are delay loaded dlls.

To correct that you could use the same suggestion as in the other post:

Copy the GStreamer folder to the output directory like this:

MediaController\ThirdParty\GStreamer\1.8.1\x86\gstreamer_runtime
to
gstreamer

And change the code to the following:

var currentPath = new System.IO.FileInfo(Application.ExecutablePath).Directory.FullName;
var gstreamerPath = new System.IO.DirectoryInfo(string.Format("{0}\\gstreamer\\bin", currentPath));

It's also worth noting that this is only for sample code though. This method could be used in a real integration but we wouldn't recommend it. It would rely too much on the relative path between the executable and the Gstreamer directory. Instead a better way is to add the Gstreamer directory to the system's PATH (or add it to a new GST_PLUGIN_PATH environment variable). If you did it this way, then you could have the application anywhere and move it anywhere as long as the correct Gstreamer location is in the path.

No, I copied over the ENTIRE directory including the exact directory structure as found in the .zip file that includes everything including the GStreamer dir. I have added the GStreamer path to the system path. Depends is of no help as it lists hundreds of files. It's not a path issue as I have found a band-aid by uninstalling all versions of Microsoft C++ resdit. that may exist on the test machine and installing the full Visual Studio 2013; but this not really a solution that can be used in the real world, as it renders the other machine's software that you are using useless. The MediaControl / GStreamer appear to require exact versions of some C++ core files and possible others but I can't find any documentation on what these are..

Additionally,
On a another test machine I had working with the original VS2013 install, I had a MSVC++ 2012 v11.0.50727, and update of this brought the version to 11.0.61030 which caused the above error also. I had to uninstall that particular version and repair Visual Studio to install the original version. I'm not 100% sure it was this particular update that caused the error, but removing the VC version and installing the original version got it back working.

This is extremely confusing trial and error to get these apps to run on other machines with various software on them. I had zero issues with this when using your DS SDK or the Pelco SDK.

Understood, thank you for the clarification and feedback.

One thing that we did notice reviewing the information that provided previously was this part:

Went to the bin\debug\x86 directory on the dev machine and launched the program. Runs..

Are you copying a debug version over and trying to run that? If so, that would explain why the redist didn't work but installing the full VS2013 did - the full version would include the necessary debug files too. If this is the case then you'll want to rebuild everything on the development machine using release mode and DLLs and then try again with the redist on the testing deployment machine.