[ISS7] aspx-Seite inklusive Verweise veröffentlichen?

[phpMorpheus2]

Hi.

Ich habe ein Projekt in Visual C# .NET Programmiert.
Der Anstoß der C# Funktionen kommt über Button in einer aspx Seite.

Das Projekt benötigt registrierte ActiveX-Elemente sowie .net-assemblies, welche als Verweise hinzugefügt wurden.

Nun möchte ich das gesamte Projekt, welches auf einem Virtuellen Server programmiert wurde, auf einem small business Server 2008 mit IIS7 installieren.

Wenn ich den Projekteordner 1:1 kopiere, funktioniert schonmal die hälfte nicht mehr.
So habe ich auf dem sbs08-server ein neues Projekt angelegt, die .cs Dateien neu eingebunden, die aspx-Seite kurz neu konstruiert und die Verweise festgelegt!

Wenn ich nun über MVS08 debugge, so wird ja auch ein Server von MVS erstellt.
Lasse ich das Projekt über diesen laufen, so funktioniert nun alles einwandfrei.
Doch wenn ich das Projekt 1:1 in einen ISV-Ordner kopiere, diesen über IIS7 einfach nur auswähle und einem Port zuordne, so kann ich die Seite erreichen,
doch wird mit beim Instanzerstellen von Objecten aus den Assemblie-Dateien gesagt, das die COM oder eine Abhängigkeit dieser, nicht gefunden werden konnte.

Frage:
Muss ich nun im IIS7 z.B. die web.config explizit nochmals einbinde damit der IIS7 die Verweise finden kann oder dergleichen?

Vielen Dank

PS: Hoffe ich bin in der richtigen Forenkategorie..

[AmicaNoctis]

Hallo,

das Stichwort "ActiveX" klingt sehr nach clientseitigem Code. Also ist nicht der Server schuld, dass die COM-Klassen nicht gefunden wurden, sondern der Client. Falls ich mich irre, bitte nochmal konkretisieren.

Gruß,

Amica

[phpMorpheus2]

Es ist eine ganz normale DLL.
Diese ist im Projekt zugewiesen worden.

Diese DLL ist abhängig von weiteren DLL-Dateien.
Ich habe nur die haupt-dll verwiesen, welche sich selbst die Infos aus den im selben ordner liegenden DLLs holt.

Nun habe ich das Projekt veröffentlicht mit MVS08 und im bin-Ordner sind alle verwiesenen DLLs, doch nicht die, welche die haupt-dll braucht, welche zuvor immer im selben Ordner lagen.

Außerdem sind die DLLs im bin-Ordner nun andersnamig. Warum auch immer!?

Ich habe die fehlenden DLLs einfach mal mit in den bin-Ordner kopiert, geht trotzdem nicht.

Fehlermeldung:
Die COM-Klassenfactory für die Komponente mit CLSID {05A2BAFB-9D79-4DCA-A84E-A1FC671A40E2} konnte aufgrund des folgenden Fehlers nicht abgerufen werden: 80040154.

die CLSID ist der Pfad zur haupt-dll.
Wenn aber MVS08 die DLLs im bin Ordner mitliefert, warum zieht er sich die DLL-Pfade der Verweise an Land, anstatt die mitgelieferten DLLs im bin-Ordner zu nutzen? Wofür sind die sonst mitgeliefert worden?

Quellfehler:

Zeile 24:             // ISAM Verbindung
Zeile 25:             this.clCon = new bzCLConnector.CLConnector(); //<= FEHLERZEILE
Zeile 26:             this.oCLConnectorData = new bzCLConnector.CLConnectorData();

[AmicaNoctis]

Tut mir leid, aber ich weiß immer noch nicht, ob du das vom selben oder einem anderen Rechner aus aufrufst und ob das serverseitig (ASP) oder clientseitig (ActiveX) ausgeführt wird. Wenn clientseitig, reicht eine DLL da nicht. Da musst du eine COM-sichtbare Library schreiben und im GAC registrieren. Außerdem läuft es dann ohnehin nur im IE.

[phpMorpheus2]

Tut mir leid, aber ich weiß immer noch nicht, ob du das vom selben oder einem anderen Rechner aus aufrufst und ob das serverseitig (ASP) oder clientseitig (ActiveX) ausgeführt wird. Wenn clientseitig, reicht eine DLL da nicht. Da musst du eine COM-sichtbare Library schreiben und im GAC registrieren. Außerdem läuft es dann ohnehin nur im IE.

Derzeit rufe ich vom selben Server auf.
Später soll jedoch von außen auf den Server zugegriffen werden.
Die DLL, welche unter MVS08 als Dateityp "ActiveX" bezeichnet wird,
ist auf dem Server registriert.
Ich habe sie unter "COM" ausgewählt.
Der Pfad bei der COM-Auswahl ist der, wo die DLL liegt und wo sie registriert wurde! (C:\SAGE\bzCLConnector.dll)
Füge ich Sie nun als Verweis hinzu,
so steht unter Eigenschaften dieses Verweises:
-Lokale Kopie = True
-Pfad = C:\Program Files\Microsoft Dynamics CRM\CRMWeb\ISV\Schnittstelle\Schnittstelle\obj\Debug\Interop.bzCLConnector.dll

Obwohl die DLL zuvor "bzCLConnector.dll" hieß.
Ist das normal?

Da die Schnittstelle für Microsft Dynamics CRM 4.0 und der Sage Classic Line programmiert wurde, ist es vollkommen ok, wenn es nur im IE funktioniert.
Denn dynamics crm funktioniert auch nur im IE.

Die DLL, also die ActiveX-Datei ("bzCLConnector.dll") greift lokal auf die Sage Classic Line zu, holt dort Daten, verwarbeitet diese und gibt eine Meldung an die aspx-Seite aus.
Also ist die ActiveX-Datei vollständig serverseitig.

[AmicaNoctis]

Füge ich Sie nun als Verweis hinzu,
so steht unter Eigenschaften dieses Verweises:
-Lokale Kopie = True
-Pfad = C:\Program Files\Microsoft Dynamics CRM\CRMWeb\ISV\Schnittstelle\Schnittstelle\obj\Debug\Interop.bzCLConnector.dll

Obwohl die DLL zuvor "bzCLConnector.dll" hieß.
Ist das normal?

Ja, vereinfacht ausgedrückt muss die C-DLL erst für .NET gewrappt werden und dabei entsteht so eine Interop-DLL. Genauer findest du das hier.

OK, also serverseitig. Ich hatte mich wohl von dem "ActiveX" verwirren lassen. Da kann ich dir grad nicht weiterhelfen.

Amica

[phpMorpheus2]

Da kann ich dir grad nicht weiterhelfen.

Amica

Danke trotzdem

[phpMorpheus2]

Dennoch heißt es, das ich die COM-Datei wrappen sollte und die in .NET gewrappte DLL neu verweisen muss, richtig?

Ich gehe mal davon aus, dass MVS08 die COM-Datei in .NET wrapped,
diese in den bin-Ordner packt und beim debuggen diese gerwappten Dateien nutzt.

Wenn ich jedoch das Projekt veröffentliche, so versucht der small business Server die COM-Datei zu verwenden, welche registriert ist, also die ungewrappte.

Somit ersetze ich jetzt mal die Original COM-Dateien mit den gewrappten, änder die Namen (kürze das "interop." weg).

Ist das soweit richtig?

[AmicaNoctis]

Tut mir leid, das ist zu lange her, dass ich mich damit rumgeplagt hab. So richtig richtig klingt das grad nicht mit Umbenennen und so. Ich würde an deiner Stelle vielleicht lieber in einem .NET-Forum nachfragen und parallel im MSDN stöbern, auch wenn das grausam ist.

[phpMorpheus2]

Tut mir leid, das ist zu lange her, dass ich mich damit rumgeplagt hab. So richtig richtig klingt das grad nicht mit Umbenennen und so. Ich würde an deiner Stelle vielleicht lieber in einem .NET-Forum nachfragen und parallel im MSDN stöbern, auch wenn das grausam ist.

Ok danke. Bin schon fleißig am MSND'nen.
Ich belasse das wrappen bei sich, denn ich bin der Sache hoffentlich dichter auf die Spur gekommen, denn es funktioniert 100%ig unter einer 32bit Platform,
doch unter einer 64bit Platform macht die COM-Datei schwierigkeiten.

Die Firma weiß auch nicht ob Sie auf einer 64bit Umgebung läuft, wurde noch nie getestet meinten Sie eben.

Kann man denn mit MVS08, den Code, trotz physikalischer 64bit Platform, in einer virtuellen 32bit Umgebung debuggen und ausprobieren?
Bislang stand es immer auf "Any CPU". Das funktionierte nicht.

Auf x64-Version bekomme ich viele Warnungen:
Assemblygenerierung, system.data.dll, auf die verwiesen wird, hat einen anderen zielprozessor...

Auf "Itanium", also eine x86-Version von Intel und somit wieder x64,
exakt das selbe Problem.

Auf einer WinXP x32 Virtuellen Maschine, welche auf einem Win7 64bit läuft, funktioniert es einwandfrei.

Vielleicht liegt es wirklich an der 64bit Version der betriebssysteme.