[asp.net 2.0] Printerlijst van client pc ophalen

[Arethusa]

Ons bedrijf levert een asp.net intranetapplicatie met vb.net als taal en sql server als database. Deze applicatie draait bij klanten in diverse omgevingen:

• Server-client (1 server, 1 of meerdere clients)
• Client-client (2 pc's)
• Client (enkele pc)

De server is een win2000/win2003 machine en de clients zijn winxp pro machines.
Op de server draait Active Directory.

Als voorbeeld neem ik een server/client omgeving.Via onze applicatie kan men rapporten afdrukken via crystal reports. Men print via de printer die op de server draait Dit veroorzaakt problemen met de printer spool op de server en raakt om nog onbekende redenen vol waardoor het printen moeilijk verloopt. Dat willen we dus anders hebben. En totdat we het printerspool probleem oplossen willen we een andere manier van printen proberen.

Het standaard printersettings opbject in .net haalt printers op van de machine waarop de ap draait. In dit geval een windows server. Via de client word dan geprint met de printer die op de server geïnstalleerd is.

Wat eigenlijk mijn vraag is, is of het mogelijk is om alleen de printers op te halen via het .net framework (of andere manier) die op de client pc geïnstalleerd staat.

Mijn idee was eerst om via active directory de printer op te halen die op de client geïnstalleerd staat. Maar aangezien er niet altijd met een AD word gewerkt is dat wat lastig.

Google/GOT en MSDN helpen me alsnog niet veel. Maar misschien gebruik ik niet de juiste woorden.

Het verhaal klinkt misschien wat wazig wat betreft het server en client verhaal maar hopelijk ben ik duidelijk.
Heeft iemand een tip?

[RobIII]

Het zou niet goed zijn als een server-side applicatie bij de settings van de client kon via een browser he? Dat gaat (op die manier) dus niet lukken. Dat je er eventueel via 'een achterdeurtje' (dus via AD of andere gein) bij kunt is daarmee niet uitgesloten maar ik zie er het nut niet van. Sowieso neem ik aan dat de printers op de clients ook allemaal "aan" de server hangen. Het enige wat je dan zou 'oplossen' is dat je van 1 queue (op de server) overgaat naar meerdere queues (op de clients) die net zo goed met z'n allen dezelfde printer gaan liggen stangen.

Maar ik zou eerst gewoon eens uit gaan zoeken waarom je spool volloopt(?) en wat daar de oorzaak van is in plaats van een omslachtige (en waarschijnlijk nooit goed functionerende) workaround te verzinnen (tenzij je vanuit de clients zélf gaat printen op "eigen" printers uiteraard). Kijk trouwens ook eens naar printerpooling (let op het ontbreken van de s); daarmee kun je aan 1 queue meerdere printers hangen zodat printen van een queue sneller afgehandeld kan worden (en wellicht het verstoppen van je queue opgelost is). Let daarbij wel op het volgende:

quote: http://www.microsoft.com/...dl_pif_flqn.mspx?mfr=true

Because it is impossible to predict which printer will receive the document, keep all printers in a pool in a single location. Otherwise, users might have a hard time finding their printed document.

Euh; lang verhaal kort: blijf uit de weg van symptoombestrijding, pak het probleem bij de gonads.

[ Voor 64% gewijzigd door RobIII op 16-10-2007 23:50 ]

[Arethusa]

RobIII schreef op dinsdag 16 oktober 2007 @ 22:05:
Het zou niet goed zijn als een server-side applicatie bij de settings van de client kon via een browser he? Dat gaat (op die manier) dus niet lukken. Dat je er eventueel via 'een achterdeurtje' (dus via AD of andere gein) bij kunt is daarmee niet uitgesloten maar ik zie er het nut niet van. Sowieso neem ik aan dat de printers op de clients ook allemaal "aan" de server hangen. Het enige wat je dan zou 'oplossen' is dat je van 1 queue (op de server) overgaat naar meerdere queues (op de clients) die net zo goed met z'n allen dezelfde printer gaan liggen stangen.

Maar ik zou eerst gewoon eens uit gaan zoeken waarom je spool volloopt(?) en wat daar de oorzaak van is in plaats van een omslachtige (en waarschijnlijk nooit goed functionerende) workaround te verzinnen (tenzij je vanuit de clients zélf gaat printen op "eigen" printers uiteraard). Kijk trouwens ook eens naar printerpooling (let op het ontbreken van de s); daarmee kun je aan 1 queue meerdere printers hangen zodat printen van een queue sneller afgehandeld kan worden (en wellicht het verstoppen van je queue opgelost is).

Je hebt natuurlijk gelijk wat betrefd je opmerking over het benaderen van client gegevens vanaf een server applicatie. Mijn idee was omdat dit in een kleine afgeschermde omgeving plaats vind, we qua beveiliging wel goed zaten. Maar inderdaad zou er een ranzige work-around bedacht moeten worden voor het printerspool verhaal wat niet tot een oplossing van het probleem leid.

Ik zal je tip over die pool eens doornemen en kijken of dat tot de oplossing leid.


Edit: Mooie quote trouwens

[4of9]

dmv een activeX control of een fully trusted .NET dll geladen in de browser (dat kan maar weet niet hoe)
Zou het kunnen,

[RobIII]

4of9 schreef op dinsdag 16 oktober 2007 @ 22:17:
dmv een activeX control of een fully trusted .NET dll geladen in de browser (dat kan maar weet niet hoe)
Zou het kunnen,

En IE only

Schiet me zojuist wel een andere "quick'n'dirty" workaround te binnen. Je kunt de server natuurlijk een PDF laten uitpoepen _{(desnoods via een virtuele PDF printer als Win2PDF ofzo, dan hoef je je code verder niet aan te passen maar loop je dus ook het gevaar dat die 'spool' over de zeik gaat net als de andere)} en die vervolgens naar de client sturen die 'm dan (als alles goed is) opent in Acrobat Reader. Dan kan de client op zijn beurt weer simpel printen zonder dat je er (al te) veel voor hoeft te doen.

Maar deze tip heb je niet van mij

[ Voor 8% gewijzigd door RobIII op 16-10-2007 22:19 ]

[_Thanatos_]

(desnoods via een virtuele PDF printer als Win2PDF ofzo, dan hoef je je code verder niet aan te passen maar loop je dus ook het gevaar dat die 'spool' over de zeik gaat net als de andere)

Veel mooier: Prince XML

[sig69]

Ik vind het eigenlijk sowieso een vreemde constructie. De printactie wordt door de gebruiker geinitieerd (tenminste, dat maak ik op uit de TS), en zou mijns inziens dus ook op de client afgehandeld moeten worden. Een gebruiker kan nu dus niet op een lokale printer printen mocht hij dat willen, alleen op printers die op de server geinstalleerd staan. Ik weet niet of dit de oorzaak het probleem is, maar het komt op mij vreemd over.

[__fred__]

De standaard Crystal Reports viewer voor Web kan op de client printopdrachten versturen, en je kunt Crystal ook een PDF laten genereren op de server die je inderdaad ook op de client kunt printen.
Ik zie dus niet zo goed wat het probleem is?

[ Voor 12% gewijzigd door __fred__ op 17-10-2007 15:40 ]

[Arethusa]

sig69 schreef op woensdag 17 oktober 2007 @ 10:52:
Ik vind het eigenlijk sowieso een vreemde constructie. De printactie wordt door de gebruiker geinitieerd (tenminste, dat maak ik op uit de TS), en zou mijns inziens dus ook op de client afgehandeld moeten worden. Een gebruiker kan nu dus niet op een lokale printer printen mocht hij dat willen, alleen op printers die op de server geinstalleerd staan. Ik weet niet of dit de oorzaak het probleem is, maar het komt op mij vreemd over.

Laat ik proberen het iets duidelijker te maken in een server-client omgeving.
De client pc start internet explorer op op daarop ziet komt in de browservenster de volgende link:
http://server/applicatie. De client werkt nu dus met de applicatie vanaf de server.
Er is een scherm met waarmee men een rapport kan kiezen. In dat scherm kan men ook een printer kiezen wie volgens de volgende code word ingeladen.

Visual Basic .NET:

Private Sub BindReportData()
            Dim i As Integer
            For i = 0 To PrinterSettings.InstalledPrinters.Count - 1
                ddlPrinters.Items.Add(PrinterSettings.InstalledPrinters.Item(i))
            Next
        End Sub

Deze code haalt dus de printers van de server op. Op onze server staan 3 printers geinstalleerd. Op mijn pc 4 (de client). Ik zie dus alleen de printers van de server wat ook logisch is aangezien vandaar de applicatie draait.

Het uiteindelijke printen gaat via deze code:

Visual Basic .NET:

Private Sub btnPrint_panel1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnPrint_panel1.Click
            Dim oCrSup As New CrystalReportSupport.Report
            Dim crReportDocument As ReportDocument

            oCrSup.ReportID = Integer.Parse(Session("sesReportID").ToString) 'id uit database
            oCrSup.Culture = Session("culture").ToString
            crReportDocument = oCrSup.GetReport(CType(Session("sesRepParams"), ArrayList)) 'array met parameters
            crReportDocument.PrintOptions.PrinterName = ddlPrinters.SelectedValue
            If IsNothing(Session("sesRepNrOfPrintOuts")) Then 'aantal afdrukken
                crReportDocument.PrintToPrinter(1, True, 1, 125)
            Else
                crReportDocument.PrintToPrinter(Integer.Parse(Session("sesRepNrOfPrintOuts").ToString), True, 1, 125)
            End If
        End Sub

Het leek mij toen ik de TS maakte wel een idee om in het eerste codevoorbeeld alleen de printers van de client pc op de halen, dus de pc die de applicatie aanroept.

Echter gebruiken we meerdere omgevingen zoals in de TS staat waardoor het allemaal wat verwarrender in elkaar steekt.


@__fred__ , zoals je ziet haal ik dus via een andere manier de printers op. Dit doen we door de gehele applicatie heen op deze manier. Je hebt gelijk als je zegt dat Crystal Reports de lokale printers ophaalt. Ik wil feitelijk hetzelfde bereiken via mijn eerste codevoorbeeld als Crystal Reports doet.

[ Voor 5% gewijzigd door Arethusa op 17-10-2007 16:21 ]

[sig69]

__fred__ schreef op woensdag 17 oktober 2007 @ 15:39:
De standaard Crystal Reports viewer voor Web kan op de client printopdrachten versturen, en je kunt Crystal ook een PDF laten genereren op de server die je inderdaad ook op de client kunt printen.
Ik zie dus niet zo goed wat het probleem is?

Ik weet niks van Crystal reports, maar heb het even opgezocht:

You can print a report two ways with Crystal Reports for Visual Studio 2005:

From the GUI, with the Print button on the toolbar that is provided with the CrystalReportViewer control on a Web or Windows Form.
From the SDK, with the ReportDocument object.
Printing from the GUI

In a Windows application, the print button on the CrystalReportViewer control toolbar opens the standard print dialog box.

In a Web application the print button on the CrystalReportViewer control toolbar opens a secondary Web page that emulates a print dialog box. A pdf is generated on the Web server, and then downloaded and displayed on the Web page. (It works much like Print Preview.)

Als je met

Visual Basic .NET:

PrinterSettings.InstalledPrinters

In een Asp.Net omgeving printers ophaalt, kan ik best begrijpen dat je de printers op de server krijgt.

Ik vermoed dat je bezig bent een paar dingen door elkaar te halen. Mocht dit niet zo zijn maar een bewuste design keuze geweest zijn, waarom heb je dan niet gewoon voor een CrystalReportViewer control op een Web Form gekozen als ik vragen mag?

Edit:

Ik wil feitelijk hetzelfde bereiken via mijn eerste codevoorbeeld als Crystal Reports doet.

Benje nu niet enorm het wiel opnieuw aan het uitvinden dan?

[ Voor 5% gewijzigd door sig69 op 17-10-2007 16:32 ]

[Arethusa]

Feitelijk doe ik inderdaad dingen dubbel ja, daar ben ik me van bewust.

De applicatie waar ik aan werk bestond al op deze manier en we lopen zo af en toe bij een klant tegen problemen aan als ik in de TS beschreef. Op de manier zoals we het nu doen werkt ook vaak prima. Het is een bewuste keuze geweest om de printers via het .net framework op te halen En deze te gebruiken in combinatie met het afdrukken van een rapport. Ook gebruiken we een report viewer om het rapport af te beelden.

De combinatie met het framework en het rapport scheelt een aantal stappen wat betrefd het afdrukken. Je selecteert nu een printer uit de lijst en klikt op afdrukken. Printen via de cr viewer vereist een aantal stappen meer die ik het liefst vermijd.

Dezelfde lijst printers ophalen, en afbeelden in de dropdowlijst als die de crystal reportviewer ophaalt is dus mijn wens. Misschien moeten we ons ontwerp eens gaan herzien.

[ Voor 29% gewijzigd door Arethusa op 17-10-2007 16:51 ]