Freitag, 4. April 2008

Mit dotNet drucken... ein Erfahrungsbericht

Das Drucken einer Datei mit dotNet ist eigentlich keine all zu große Herausforderung. Beispiele findet man wie Sand am Meer, der eigentliche Code ist auch nicht all zu komplex.
Entsprechend schnell hat die Methodik auch funktioniert, als sie lokal in einem UnitTest aufgerufen wurde. Gedruckt wurde dabei auf einen Netzwerkdrucker. Der gleiche Code sollte aber nun als Assembly im SQL Server 2005 abgelegt werden, so dass im Prinzip nur eine Stored Procedure aufgerufen werden muss, um - in diesem speziellen Fall - einen bestimmten Report aus den Reporting Services zu drucken. Und was kommt wohl jetzt? Richtig, es hat nicht funktioniert.
Nach mehreren erfolglosen Versuchen, die Druckfunktion für den Druck auf einem Netzwerkdrucker zu realisieren, kam dann die Idee, den Drucker direkt via USB mit der Entwicklungs-VM zu verbinden. Nach Tagen des Misserfolgs dann die Überraschung: auf einem lokalen Drucker wird der Report ausgegeben.

Meine Vermutung geht zur Zeit dahin, dass dem Aufruf für einen Netzwerkdrucker noch der zu verwendende Port angegeben werden muss. Beim UnitTest muss dies nicht geschehen, weil der Aufruf hier direkt aus Windows kommt. Wird jedoch die SP aus dem SQL Server aufgerufen, kommt der Aufruf für das unterliegende OS aus dem Web, was offensichtlich einen Unterschied macht.
Diese Vermutung muss noch durch ein wenig Research und Trial and Error verifiziert werden, doch bin ich zuversichtlich, der korrekten Lösung auf der Spur zu sein.

Sobald ich genaueres weiß, seid ihr die Ersten, die es erfahren.

EDIT: Des Rätsels Lösung ist gefunden!
Anders, als ich es vermutet habe, ging die Lösung doch, wie von Tropensturm vermutet, in Richtung Benutzer-Authentifizierung.
Da die Assembly im SQL Server aufgerufen wird, greift sie auch mit dessen Rechten auf das Netzwerk zu. Offenbar besteht hier allerdings nicht das Recht, auf Netzwerkdrucker zuzugreifen. Deshalb holen wir uns die Rechte des aktuell angemeldeten Windows-Benutzers. Das geschieht folgendermaßen.

   1:  // Vorbereitung
   2:  System.Security.Principal.WindowsIdentity clientId = null;
   3:  System.Security.Principal.WindowsImpersonationContext impersonatedUser = null;
   4:   
   5:  // Windows-Identität ermitteln
   6:  clientId = SqlContext.WindowsIdentity;
   7:   
   8:  try
   9:  {
  10:      // Windows-Berechtigungen holen
  11:      impersonatedUser = clientId.Impersonate();
  12:   
  13:      // An dieser Stelle drucken
  14:  }
  15:  finally
  16:  {
  17:      if(impersonatedUser != null)
  18:      {
  19:          // Windows-Rechte wieder abgeben
  20:          impersonatedUser.Undo();
  21:      }
  22:  }

Und kaum macht man es richtig, funktioniert es... ;)

3 Kommentare:

Tropensturm hat gesagt…

Daran das die SQL DB mit dem SQL User läuft und eventuell nicht genügend Berechtigungen für einen Netzzugriff hat, kann es nicht liegen? Nur ne Idee die mir als erstes kam :)

BBo hat gesagt…

Interessanter Ansatz, aber die Rechte von SQL-Sicht sind i.O.
Danke dennoch für den Hinweis.

Tropensturm hat gesagt…

Also doch der User ;) schön das es jetzt geht :)

PS Danke für das Stück Code