Glengamoi

Hallo zusammen,

meine Firma hat mich abgestellt, eine Strategie zur Umstellung von VB6 auf VB.NET und ASP auf ASP.NET zu entwickeln. Dabei fiel schnell auf, dass die Migration der VB6-Komponenten vergleichsweise einfach ist (im Gegensatz zu den vielen ASP-Seiten). Ich probiere mich daher zurzeit in der Anknüpfung von VB.NET-Komponenten aus ASP heraus.

So weit bin ich bisher gekommen:

1. Ich erstellte ein neues Projekt im VS2008 -> Visual Basic Class Library
2. Dort fügte ich eine COM Class hinzu. (VS2008 erstellte automatisch ClassId, InterfaceId, EventsId und eine entsprechende Annotation <ComClass(..)>. Das Projekt bekam auch automatisch unter dem Compile Reiter das Häkchen bei Register COM interop.)
3. Zusatzlich habe ich in den Projekteigenschaften unter dem Reiter Signing ein neues name key file angelegt. Was - soweit ich das beurteilen kann - das globale Regristrieren der zukünftigen Assembly ermöglicht.
4. Nach dem Build-Vorgang liegt auch eine .tlb-Datei im Ordner \bin\Debug\. Im OLE/COM Object Viewer (OleView.Exe) finde ich auch unter All Objects mein Projekt ("WeatherService") mit meiner Klasse ("WeatherProvider"). Die CLSID ist auch die, die sich VS2008 als ClassId hat einfallen lassen. Auch eine ProgId wird angezeigt (hier: "WeatherService.WeatherProvider"). Somit habe ich mir auch die Verwendung des RegAsm.exe erspart.
5. Als nächstes habe ich testweise ein VB6-Projekt erstellt, welches die registrierte Klasse nutzt. Ich fügte es über die Reiter Projekt->Verweise.. hinzu und konnte dann damit ganz normal arbeiten.
6. Jetzt zum ASP:
   

   <%
       Set ws = Server.CreateObject("WeatherService.IWeatherProvider")
   %>
   

   wird gefolgt von der Fehlermeldung:
   

   Serverobjekt Fehler "ASP 0177 : 800401f3'
   Server.CreateObject-Fehler
   

Im Internet gibt es nur wenig darüber zu finden. Daraus schließe ich, dass es entweder zu einfach ist oder es eher selten ist, dass jemand aus ASP heraus auf .NET-Objekte zugreift. Gibt es vielleicht ein paar brauchbare Tutorials oder Erfahrungsberichte? Was mich sehr wurmt, ist, dass ich aus einen VB6-Projekt darauf zugreifen kann. Von ASP her aber nicht :-(

Für Eure Hilfe bin ich sehr dankbar

Marcel

Es geht auf jeden Fall mit ASP!

Du musst die DLL auch registrieren...

Ich habe mir vor Jahren dazu  notiert:

DLL mit neuem Namen und Namespace (WeatherService).
  Registrierung mit:
     [DotNetVerzeichnis]\regasm.exe WeatherService.dll /tlb:WeatherService.tlb /codebase

Initialisierung mit in ASP mit:

set  myObj=CreateObject("WeatherService.IWeatherProvider")

Gruß, Chris

Im Augenblick verstehe ich nicht ganz, warum Du in .NET erstellte COM-Interops in klassischem ASP nutzen willst?

.NET bzw. ASP.NET ist eigentlich erst in Reinform richtig leistungsfähig, deshalb hat die alte Server.CreateObject - Methode da nichts mehr zu suchen.

JuergenAuer:

Im Augenblick verstehe ich nicht ganz, warum Du in .NET erstellte COM-Interops in klassischem ASP nutzen willst?

Da hast Du natürlich Recht, was ist aber, wenn man ein umfangreiches ASP-Project hat und dieses um Funktionalitäten erweitern will.
Soll man dann bei VB 6 bleiben?

Hallo zusammen.

Erstmal ein großes Entschuldigung von mir, dass ich solange nichts von mir hören ließ. Mein Benutzeraccount wurde gleich nach dem Eröffnen dieses Threads gesperrt. Der freundlichen Hinweis: ich solle mich an den Moderator des Forums oder den Administrator wenden. Leichter gesagt als getan, denn es scheint keinen zu geben! Und auch die Emailadresse webmaster@dotnetgerman.com ist eher nur eine Einbahnstraße. Ich hab dann den pragmatischen Ansatz verfolgt und mich einfach nochmal angemeldet. Somit kann ich mich wenigstens für die Antworten bedanken.

• Aber vorerst erstmal Kritik:
  Mir ist klar, dass ASP.NET um einiges schneller ist also ASP.ALT. Aber wie jeder erfahrene Programmierer weiß, gibt es in jeder Firma Altlasten. In unserem Falle sind das ASP-Seiten mit über 7000 Zeilen. Und diese sind leider immer noch im produktiven Bereich bei uns zu finden :-(  Und wer jetzt immer noch daherkommt und meint er möchte hier mit der ASP -> ASP.NET-Migration anfangen, der darf meinen Job gern übernehmen.
  In sofern wollen wir eher versuchen zentral die VB-Komponten auf VB.NET umzustellen. Das ist einfacher, wenn zuvor sauber programmiert wurde (und man den Wizard dann gut verwenden kann). Mit dem COM-Objekten können wir dann weiterhin eine funktionsfähige Lösung aufrechterhalten und auch Anwendertests fahren. Der Endnutzer sollte in der Regel keinen Unterschied außer vielleicht in der Geschwindigkeit merken. Die wirkliche ASP.NET-Migration kann dann dem jeweiligen Entwickler nach Belieben aufgebürdet werden. Die Applikationschicht wäre dann wenigstens einheitlich in .NET.
  

• Einen großen Dank an Chris.
  Der Satz "Es geht auf jeden Fall mit ASP!" hat mich trotz etlicher Misserfolge und der o.g. Nachrichtensperre weitermachen lassen und mich letztendlich den wahren Fehler finden lassen.

Die fertig kompilierte dll lag bei uns auf einem Netzlaufwerk (verbunden als Y:\). Das Regristrieren mit RegAsm.exe klappte dann auch wunderbar. Ein Beispielprojekt unter VB6 (welches auch Y:\ kannte) lief perfekt. Nur der dämliche IIS7 wollte nicht auf das Netzlaufwerk. Und er gab natürlich auch keine Fehlemeldung. Ich musste mit dem ASP-Fehlercode 80070002 vorlieb nehmen. Über drei Ecken gedacht, hab ich die dll dann lokal kopiert und registriert. Et voilá: Es funktioniert.

Danke trotzdem an alle

Marcel

Der Benutzeraccount wurde vermutich gesperrt, weil Du nicht Vor und nachname benutzt hast.

Der IIS7 kennt das Netzlaufwerk Y: nicht, weil du es in Deinem Context erstellt hast, der IIS aber als IUSR_Machinname, netzwerkdienst oder
sonst einem Account läuft, wo es eben kein y.\ gibt. Dein VB6 läuft unter Deimnem Usernamen und kennt deswegen y:

Aber schön das es jetzt geht... ich weiß noch genau, wie ich damals gekämpft hatte.

Gruß, Chris

Ich frage mich nur ernsthaft, ob diese Reihenfolge des Upgrades sinnvoll ist.

Praktisch gibt es doch zwei Möglichkeiten:

(1) Erst die VB6 auf VB.NET umstellen, dann die ASP auf ASP.NET

(2) Erst ASP auf ASP.NET, dann die VB-Sachen.

Das Problem bei (1) sehe ich darin, daß man alle ASP-Seiten ebenfalls anfassen muß, um die Verweise anzupassen.

Fängt man dagegen mit (2) an, dann läßt sich die Objekterstellung womöglich so auslagern, daß man beim späteren (1) bloß noch diesen ausgelagerten Code einmal ändern muß.

Es gibt noch eine dritte Möglichkeit...

Das Projekt ist sehr umfassend, erledigt seine Aufgaben Problemlos und eine Neuprogrammierung kommt nich in Frage.
Dann ist es sinnvoll Erweiterungen in .NET zu machen, da es einfach viiiieeel einfacher ist.

Hallo zusammen.

Da nun einige Zeit ins Land gestrichen ist, wollte ich mich doch mal wieder melden und vielleicht diesen Thread von meiner Seite her zum Abschluss bringen.

• Erstmal möchte ich folgendes widerlegen:
  

  JuergenAuer:

  Das Problem bei (1) sehe ich darin, daß man alle ASP-Seiten ebenfalls anfassen muß, um die Verweise anzupassen.

  
  Nach meinen vielen kleinen Testversuchen und Funktionsbeweisen bin ich davon überzeugt, dass eine Komponente von VB6 nach VB.NET migriert und sauber als COM interop verpackt keine Änderungen an alten ASP Seiten bedarf. Man muss einfach nur aufpassen, dass die Namen und Namensräume der Komponenten erhalten bleiben und dadruch der Aufruf Server.CreateObject("...") nicht irgendwo ins Leere läuft.
  Allerdings glaube ich, kommt man schon irgendwann an gewisse Grenzen, die eine Anpassung erfordern. Soweit ich das bemerkt habe, ist das bei komplexeren Datentypen der Fall, die die COM Schnittstelle nicht übermitteln kann. (So musste ich ein Array von Strings als Array von Objects übergeben, weil der COM Wrapper grad mal ein SAFEARRAY(VARIANT) packt. An eine Collection mag man gar nicht erst denken.)
• Und nun:
  Zurzeit habe ich eine lokale Kopie unserer Produktivumgebung und darf damit experimentieren. Und ich habe diesmal wirklich mit der GUI-Ebene (also den ASP Seiten) angefangen. Der Assistent, den ich im Internet gefunden habe, rödelt schon seit Stunden. Ich bin gespannt, was wird, wenn was wird. ;-)

In diesem Sinne, wünscht mir Glück und vielen Dank für Eure Unterstützung

Marcel

Ich Wünsch Dir Glück ;--)

MarcelSchmidt:

• Erstmal möchte ich folgendes widerlegen:
  

  JuergenAuer:

  Das Problem bei (1) sehe ich darin, daß man alle ASP-Seiten ebenfalls anfassen muß, um die Verweise anzupassen.

  
  Nach meinen vielen kleinen Testversuchen und Funktionsbeweisen bin ich davon überzeugt, dass eine Komponente von VB6 nach VB.NET migriert und sauber als COM interop verpackt keine Änderungen an alten ASP Seiten bedarf. Man muss einfach nur aufpassen, dass die Namen und Namensräume der Komponenten erhalten bleiben und dadruch der Aufruf Server.CreateObject("...") nicht irgendwo ins Leere läuft.
  

Ich muß gestehen,  daß ich so eine Upgradestrategie nie nutzen würde.

Ich würde genau im Gegenteil die Namen und Namensräume eindeutig anders benennen. Dann kann man mit Suchen/Ersetzen arbeiten. So läufst Du Gefahr, daß auf einem System noch eine alte Komponente registriert ist - und die neue Komponente in Wirklichkeit gar nicht genutzt wird.

Mir ist es da lieber, wenn das im Vorfeld hinreichend kräftig crasht - ich dann aber auch weiß, daß ich alle Stellen geändert habe.