4

I've been looking around for a while for a possible solution and explanation, but I can't find anything really.

The following command is being run from a windows service. The same command does function if used directly in cmd. It does not return any errors or anything else for that matter.

    System.Diagnostics.Process process = new System.Diagnostics.Process();
    System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
    startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
    startInfo.FileName = "cmd.exe";
    startInfo.Arguments = "/C lpr.exe –S " + printerIP + " –P " + deviceName + " –o l " + fInfo.DirectoryName + @"\" + fInfo.Name;
    process.StartInfo = startInfo;
    process.Start();

It might just be some minor thing I'm missing, but I just can't see it. If it's possible to go around using the lpr-command with an easy alternative I'd love that, but I havent seen anything yet.

Edit: Forgot to add that the file I'm trying to send to the printer is a pcl file.

Edit2: When I run the command without the Hidden windowstyle and WaitForExit(5000) applied to the process then I can't seem to see any commandline written - all that appears is the empty command prompt.

Edit 3: Been toying a bit around with this now and I've come up with the following:

    System.Diagnostics.Process process = new System.Diagnostics.Process();
    System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
    startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
    startInfo.FileName = "lpr";
    startInfo.Arguments = " –S " + printerIP + " –P " + deviceName + " –o l " + fInfo.DirectoryName + @"\" + fInfo.Name;
    process.StartInfo = startInfo;
    process.Start();

The above code works if it is executed by a user clicking a button in a form. So I decided to change my code into running as a tray application, seeing as I thought this might solve the issues - yet it still seems to refuse being run. Could it be some sort of issue with it being run by a triggered timer or another thread? Or perhaps something to do with the rights of those methods?

GoD1x
  • 77
  • 2
  • 10
  • Do you get any error or exception or is it just doing nothing? – Yannick Blondeau Aug 19 '12 at 10:58
  • It does absolutely nothing. I have the code wrapped in a trycatch writing to a txt with any errors that might occur. It doesn't work with or without valid printerIP, deviceName and file. Its almost like it doesn't execute, but it should, shouldn't it? @YannickBlondeau – GoD1x Aug 19 '12 at 20:13
  • Do remember, that the service has not got the full user access, where are you writing the file to? – BugFinder Sep 01 '12 at 09:52
  • It's being sent to a network printer. Though it's no longer running as a service, but as a form application without a visible form. The command is still being executed in a different thread( or by a timer). Could it be that the thread needs to be given administrator rights? @BugFinder – GoD1x Sep 01 '12 at 18:32
  • Are you sure its finding lpr.exe ? you shouldnt need admin rights, but without you stepping through code, and tracing whats happening and executing it and capturing all responses etc.. its hard to know. lpr may return an error code but no error code will be fed back to your app .. – BugFinder Sep 02 '12 at 00:31
  • It's finding the lpr.exe, seeing as if it does not, then it will return with an exception saying that the file could not be found. The code part works if it is used in a form and a user clicks a button to fire the code - but if it is fired from my automated application that executes the code through timers/background threads it doesn't work. @BugFinder – GoD1x Sep 02 '12 at 10:57
  • Whats different about the background app then? How is that app run? – BugFinder Sep 02 '12 at 11:05
  • It's a windows form application which doesn't show its form - instead it has an icon in the tray where you can right-click and start the timers, stop the timers or exit the application. The big difference is that it runs the code above in a seperate thread or by a timer - whereas the form that works used user input in the form of a button press. @BugFinder – GoD1x Sep 02 '12 at 13:33
  • Ok that shouldnt make any difference to what happens, in the slightest. – BugFinder Sep 02 '12 at 17:29
  • That's what I thought too, but apparently it does... Any clue how I might try and run the process with current logged in user's rights (or as a specific user account)? - just to see if that's somehow the issue. @BugFinder – GoD1x Sep 02 '12 at 17:55
  • Instead of silently running in a thread, add a debug window and run it it there with output etc (or trying the smart inspect from www.gurocksoftware.com – BugFinder Sep 03 '12 at 06:19

1 Answers1

3

Change your code to this:

System.Diagnostics.Process process = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
startInfo.FileName = "cmd.exe";
startInfo.Arguments = "/C C:\windows\Sysnative\lpr.exe –S " + printerIP + " –P " + deviceName + " –o l " + fInfo.DirectoryName + @"\" + fInfo.Name;
process.StartInfo = startInfo;
process.Start();

The issue is that you are trying to access a 64 bit application (lpr) from a 32 bit cmd.exe application. The simple solution is to use the sysnative directory.

http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm

The 'Sysnative' folder is invisible in Windows Explorer If you start Windows Explorer and open the Windows folder on your hard disk, you may notice that the Sysnative folder is not shown. The main reason to this is that Windows Explorer is a 64-bit program (when run in a 64-bit Windows), and the Sysnative folder is only visible and accessible from 32-bit software. If 64-bit software need access to the 64-bit system folder in Windows, the only option is to use the System32 folder name (for example: C:\Windows\System32).

Using the 'Sysnative' folder will help you access 64-bit tools from 32-bit code Some tools in a 64-bit Windows only exist in a 64-bit version; there is no 32-bit version available. And some of these tools are located in the 64-bit System32 folder. One example is the nbtstat tool that is used to help troubleshoot NetBIOS name resolution problems. If you try to run the nbtstat tool from 32-bit code (for example from an application or from script) and use a path like C:\Windows\System32, you will get a "File not found" error. The file can not be found; although Windows Explorer shows that the nbtstat program file actually is located in the C:\Windows\System32 folder.
The solution to this (somewhat confusing) problem is to include the virtual Sysnative folder in the folder path when you want to run the tool. For example like this: C:\Windows\Sysnative\nbtstat.exe The file path above will give you access to the 64-bit nbtstat tool from a 32-bit application or from a 32-bit script. We recommend you to read this article / blog post (at Scottie’s Tech.Info) to get more details about this.

omrsafetyo
  • 310
  • 2
  • 7