asp- Seite -> Inproc-Server -> exe

[Steffen Dittmann]

Hallo, ich spreche aus einer asp-Seite einen inproc-server an. Das funktioniert soweit ganz gut, nur wenn der inproc-server über DCOM auf eine TAutoobject mit einem IDispatch- Interface in einer exe gehen soll, startet die exe, aber beim Aufruf einer Methode kommt "Schnittstelle nicht unterstützt". <br>
Rechte habe ich dem COM- object in der exe eigentlich alle möglichen eingeräumt. <br>
Rufe ich den inproc- server aus einem normalen account heraus auf, funktioniert das ganze auch.
Bitte um Hilfe!

[Andreas Kosch]

Hallo,

wird NT 4 SP? oder Windows 2000 verwendet? Unter welchem Benutzerkonto läuft der In-Process-Server? Wenn von DCOM die Rede ist, läuft der Automation-Server (EXE) auf einem anderen Rechner? Wenn ja, welches Betriebssystem wird dort verwendet

Hallo, <br> eine wichtige Sache fehlte noch, Inproc- Server und exe laufen auf 2 verschiedenen Rechnern. Beide sind Mitglied einer Arbeitsgruppe und haben NT 4 mit SP 5. Der Inproc- Server läuft unter
dem Benutzerkonto IUSR_Rechnername

[Andreas Kosch]

Hallo,

ich habe diese Konfiguration einmal mit meiner Umgebung (Windows 2000, IIS 5, COM+) nachgebaut. Der Client (Windows 2000 Professional) ruft eine ASP-Seite auf dem IIS 5 auf, dort wird ein eigenes COM+ Objekt erzeugt, das über die Methode CallEXE einen DCOM-Server (EXE) auf einem anderen Rechner (Windows 2000 Server) aufruft. Dabei habe ich die folgende Konfiguration verwendet: <br>
a) Client: Login als Administrator <br>
b) Server: Login als Administrator <br>
c) DCOM-EXE wird auf dem Server installiert und über DCOMCNFG so konfiguriert, dass das DCOM-Objekt unter dem Konto des Interaktiv angemeldeten Benutzers ausgeführt wird. <br>
d) Das aus der ASP heraus aufgerufene COM+ Objekt wird in einer eigenen COM+ Application installiert, wobei die Application unter dem Konto des Interaktiv angemeldeten Benutzers ausgeführt wird. <br>
e) Wird nun die ASP-Seite aufgerufen, ist auf dem Windows 2000 Server der Start der DCOM-EXE zu sehen, die ASP liefert den richtigen Rückgabewert zurück.

ASP-Seite:
<pre>
<%
Dim iReturn
Set DelphiASPObj = Server.CreateObject("ASPCALLOBJ.ASPObjCallEXE")
iReturn = DelphiASPObj.CallEXE("Text von der ASP")
Response.Write iReturn
%>

ASP-Komponente:
<pre>
uses ComServ, ASPCALLEXE_TLB;

resourcestring
cREMOTE_ADR = '192.168.10.1';

function TASPObjCallEXE.CallEXE(const sInfo: WideString): Integer;
var
aSrv : ICallFromASP;
begin
aSrv := CoCallFromASP.CreateRemote(cREMOTE_ADR);
Result := aSrv.DoWork(sInfo);
end;
</pre>

Wenn der In-Process-Server unter dem vom IIS vordefinierten Benutzerkonto <b>IUSR_Rechnername</b> läuft, hat er nur die Rechte, die auch dem <b>Gast</b>-Benutzerkonto unter NT zugeordnet werden. Normalerweise ist dann der Zugriff auf Ressourcen jeglicher Art immer dann ein Problem, wenn diese auf einem anderen Rechner liegen. Da das Freischalten des Gast-Benutzerkontos bei beiden NT-Maschinen wohl nur selten in Frage kommt, sollte das COM-Objekt unter einen anderen Benutzerkonto (für das mit DCOMCNFG Start- und Zugriffsrechte eingeräumt wurden) ausgeführt werden

[Andreas Kosch]

Hallo,

ich habe diese Konfiguration einmal mit meiner Umgebung (Windows 2000, IIS 5, COM+) nachgebaut. Der Client (Windows 2000 Professional) ruft eine ASP-Seite auf dem IIS 5 auf, dort wird ein eigenes COM+ Objekt erzeugt, das über die Methode CallEXE einen DCOM-Server (EXE) auf einem anderen Rechner (Windows 2000 Server) aufruft. Dabei habe ich die folgende Konfiguration verwendet: <br>
a) Client: Login als Administrator <br>
b) Server: Login als Administrator <br>
c) DCOM-EXE wird auf dem Server installiert und über DCOMCNFG so konfiguriert, dass das DCOM-Objekt unter dem Konto des Interaktiv angemeldeten Benutzers ausgeführt wird. <br>
d) Das aus der ASP heraus aufgerufene COM+ Objekt wird in einer eigenen COM+ Application installiert, wobei die Application unter dem Konto des Interaktiv angemeldeten Benutzers ausgeführt wird. <br>
e) Wird nun die ASP-Seite aufgerufen, ist auf dem Windows 2000 Server der Start der DCOM-EXE zu sehen, die ASP liefert den richtigen Rückgabewert zurück.

ASP-Seite:
<pre>

Dim iReturn
Set DelphiASPObj = Server.CreateObject("ASPCALLOBJ.ASPObjCallEXE")
iReturn = DelphiASPObj.CallEXE("Text von der ASP")
Response.Write iReturn
</pre>

ASP-Komponente:
<pre>
uses ComServ, ASPCALLEXE_TLB;

resourcestring
cREMOTE_ADR = '192.168.10.1';

function TASPObjCallEXE.CallEXE(const sInfo: WideString): Integer;
var
aSrv : ICallFromASP;
begin
aSrv := CoCallFromASP.CreateRemote(cREMOTE_ADR);
Result := aSrv.DoWork(sInfo);
end;
</pre>

Wenn der In-Process-Server unter dem vom IIS vordefinierten Benutzerkonto <b>IUSR_Rechnername</b> läuft, hat er nur die Rechte, die auch dem <b>Gast</b>-Benutzerkonto unter NT zugeordnet werden. Normalerweise ist dann der Zugriff auf Ressourcen jeglicher Art immer dann ein Problem, wenn diese auf einem anderen Rechner liegen. Da das Freischalten des Gast-Benutzerkontos bei beiden NT-Maschinen wohl nur selten in Frage kommt, sollte das COM-Objekt unter einen anderen Benutzerkonto (für das mit DCOMCNFG Start- und Zugriffsrechte eingeräumt wurden) ausgeführt werden

[Steffen Dittmann]

Hallo, <br> Danke für die ausführliche Antwort! Ich werde es gleich mal probieren