I don't know if you can do it with other PDF viewers in such a way that those viewers are plug-and-play replacements for Adobe Reader. You'll probably have to tailor it to each program you want to support. It's not so difficult to have Reader on one's system, really, if it's necessary to perform a job and most computers come with it preinstalled.
The first thing you have to know is that when you tell it to print via that verb, via either code or the Explorer context menu, you are doing something like this:
""C:\Program Files\Adobe\Reader 10.0\Reader\AcroRd32.exe"" /p /h "%1"
Note the arguments: /p (tells it to print) and /h (start minimized).
AcroRd32.exe /t path "printername" "drivername" "portname"
The document specifies that this initiates Adobe Reader and prints a file, whose path must be fully specified, while suppressing the Print dialog box. (Copy-pasted from Developer FAQ.)
There is also an option /n which "launches a separate instance of Acrobat or Adobe Reader, even if one is currently open." (Developer FAQ again.) That could be used to run multiple print jobs in parallel, I imagine.
So basically, you could iterate your list of PDFs, and for each one start a new print process with a Process.Start call and wait for it to close via a Process.WaitForExit. This will make your program appear to hang and I hate when programs hang while they perform operations, so you should really do this in a cancellable BackgroundWorker that reports progress and still leaves your GUI somewhat interactive.
Thanks, @djdanlib. I have confirmed now that I can assume that Acrobat Reader is present, and so I can use your Acrobat Reader /t solution. It does print, but adding /h does not make it minimized.