3

I have a C# DirectShow.Net application and i want to test it running on other computers in release mode. How can i go about making sure my program will run on other machines that don't incorporate the windows sdk and the filters it avails?

I will have to include the dirctshow dlls and such but what can i do about the filters themselves?

Update: I have virtual machines to run it on, but moreover how can i make sure a certain directx filter is on a computer and if it isnt, grab the dll and register it to the computer from code?

Edit: After i have the DLLs registered i run my program. It doesnt run, so i grab graphstudio and i attach my program's graphs to graphstudio and none of the filters are connected and when i try to manually connect them they refuse to connect.

Edit2: 

Can you post more details about the scenario you are having problems with?

I am running my application which works on my windows 7 32bit machine on my Virtualbox VM. the virtualbox wont allow me access to my usb device for streaming purposes so i commented out the code that depends on it. when i run it, the filters wont connect. I did some testing and tried to recreate the graphs without the source and they wont connect together so that may actually be the problem.

OS version?

At the moment i am running the 32bit XP virtualbox VM

which filters you are using?

I am using

Source -> Smart tee (capture) -> GMFBridgeSinkFilter
          Smart tee (preview) -> AVI Decompressor -> Video REnderer

GMFBridgeSource -> ffdshow video encoder -> avi mux -> File writer

(w)riter has to be lowercase for some odd reason. dev machine has (w)riter and (W)riter

Which filters do you have there that you are not using?

Do you mean which are standard on the OS or filters i put in the code and am not connecting to?

You could also try with the original GraphEdit instead of GraphStudio, and you could debug your application remotely and see where it is failing exactly.

Graphedit only comes in the full windows sdk which is a pain to download where im at.

Grant
  • 684
  • 1
  • 7
  • 26
  • 1
    IMHO, the best approach is to use a Virtual Machine. You might not get the performance you expected, but you will be able to try different configurations and OS versions. – HiperiX Jun 27 '11 at 19:49
  • 1
    The SDK installs filters? That's news to me. Have you actually tried this? – Hans Passant Jun 27 '11 at 20:13
  • tried what? i have my dev machine with 7 different windows sdk versions and i created an application incorporating directshow filters. I move the application to one of my virtual machines and after i register the corresponding DLLs (directshowlib, gmfbridge, ffdshow etc). I run the application but it will not run. I download graphstudio to view the program and none of the filters are connected and they wont connect even in graphstudio – Grant Jun 27 '11 at 20:19

1 Answers1

1

Here is a list of a few verifications that you could do:

  • As @HiperiX stated, it is a good idea to test your application in a clean system, maybe using some virtualization software. If you need to support Win XP, it will be a good idea to test it there too, since there are a few DirectShow filters that are only available in Win Vista and later.
  • About the required filters, some of them might be provided by Windows. Those that are not, you must provide them and register them in the target system during the installation process of your application. I would recommend in this case creating an installation project from visual studio and attach all your dependencies dlls there. For a manual installation you can copy your filters to your application's folder and register them using regsvr32 filtername.ax from command line.
  • One more detail you will need to take care of is compatibility with 64 bits versions of Windows, since you cannot use filters built for 32bit native mode from a 64 bit applications. If your application was developped in .net and it was built using AnyCPU mode, the .net JIT will create 64 bit code from it and your 32 bit dlls will fail to load. So if you are using 32 bits dlls I would recommend building your .net application with CPU Type = X86. You can set this mode in your project configuration in Visual Studio.
  • Depending on how your filters were created, you may also need to install Visual c++ redistributable files.
  • About this remark:

I did some testing and tried to recreate the graphs without the source and they wont connect together

That is certainly a problem, you cannot create a graph without a source filter AND a destination filter. The source filter will in general determine the content format, compression, color space etc, etc. In order to test this application with a virtual system you need to provide direct access to your USB ports inside the virtualized OS and install the drivers for your capture devices there, as in a real system. Otherwise DirectShow will not detect your device(s).

yms
  • 10,361
  • 3
  • 38
  • 68
  • is there a way i can run regsvr32 from code? I can do the manual install, but im sure somebody is going to get a hold of it and not know what to do and complain – Grant Jun 27 '11 at 20:24
  • @yms ok, would you know anything about my Edit: question update aswell? – Grant Jun 27 '11 at 20:38
  • Can you post more details about the scenario you are having problems with? OS version? which filters you are using? Which filters do you have there that you are not using? You could also try with the original GraphEdit instead of GraphStudio, and you could debug your application remotely and see where it is failing exactly. – yms Jun 27 '11 at 20:46
  • updated, and i shall be messing with VM to make my usb work correctly to further test this – Grant Jun 27 '11 at 21:57
  • 1
    it does work on my VM. I had to install VS2010 for testing/debug. the VM changed the name of the device and i had to add ffmpeg and GMFbridge – Grant Jun 28 '11 at 18:57