Brownfield Anwendung arbeitet mit C# und COM via .tlb Dateien...hat irgendwer ne Alternative dazu???

Hallo Leutz,

ich plage mich seid geraumer Zeit mit dem ewigen: Update, neu registrieren, kein Adminmode usw. rum. Das ganze ist ne bestehende Access Anwendung die mit C# aufgebohrt wurde. Leider ist es aus vielerlei Gründen nicht möglich einfach den ganzen alten Kram loszuwerden.

Damit das ganze verständlicher wird hab ich mal nen Bild gebastelt.

Die Frage ist: hat irgendwer schon ne Lösung am Laufen oder ne Idee im Kopp wie ich diese COM/.tlb connection loswerden kann?

Wichtig dabei: es muss von C# aus auf Access zugegriffen werden (bestehende Dialoge müssen angezeigt werden können und ja es gibt Übergabeparamter) aber auch muss von Access aus auf C# Assemblies zugegriffen werden können da der Zugriff auf den SQL Server (aber nur teilweise) auch über C# Assemblies laufen MUSS!!

Howard

Hallo Howard,

Access <-> C# ist auch mein täglich' Brot.
Access versteht nur COM, daran ist nicht szu ändern. Es gibt zwar seit Windows XP die Möglichkeit COM-DLLs ohne Registry zu verwenden (Stichwort SxS oder Side-by-Side). Dabei werden die Infos, die sonst in der Registry stehen, in einer XML-Manifestdatei gepflegt. Leider unterstützt Access diese SxS-Geschichte nicht wirklich. All meine Versuche in dieser Hinsicht sind gescheitert. Also zurück ans Reißbrett.

Man kann die COM-Verweise nicht verhindern, aber drastisch reduzieren. Statt Deine Funktionalität direkt für COM-Interop zu veröffentlichen, baust Du ein allgemeines Kommunikationssystem, welches von Access und C# gleichermaßen genutzt wird, um Befehle und Nachrichten auszutauschen. Die eigentlichen C#-Assemblies, welche die Funktionalität implementieren, werden von dieser Kommunikationsschicht per Reflection geladen und aufgerufen. So wird XCopy-Deployment möglich (vorausgesetzt, die Kommunikationsschicht wurde einmal unter Admin/Hauptbenutzer installiert).

Aus C# heraus könnte sich sowas etwa so anfühlen: (Nachfolgender Code ist nur Pseudeo-Code!)

// Access-Formular starten
AccessObject accForm = AccessInteropHelper.OpenFom("Article");

// Methode am Formular aufrufen
bool success = (bool)accForm.InvokeMethod("LoadArticle",4711);

// Komplete Daten von Access-Objekt abrufen
ADODB.RecordSet rs=(ADODB.RecordSet)accForm.InvokeMethod("GetArticlePrices");

// Recordset in .NET DataTable umwandlen
DataTable table = AccessInteropHelper.ConvertRecordSetToDataTable(rs);

Aus Access heraus könnte sich das so anfühlen:

' Interop-Kommunikationsmanager erstellen
Dim objDotNetInterop As Rainbird.DotNetInteropManager
Set objDotNetInterop=new Rainbird.DotNetInteropManager

' C#-Formular öffnen
Dim objDotNetForm As Rainbird.DotNetObject
Set objDotNetForm=objDotNetInterop.CreateObject("Rainbird.Example.dll","Rainbird.Example.LoginForm")

' Methode an C#-Formular ausführen
Dim objResult As Rainbird.DotNetObject
Set objResult=objDotNetForm.InvokeMethod("ShowDialog")

' Konkreten Wert auslesen
Dim lngDialogResult As Long
lngDialogResult  = objResult.GetValueAsInt

Vor Allem ist es sehr wichtig, sämtliche Interop-Mapping-Geschichten aus den Funktionalen C#-Klassen komplett rauszuhalten! Also z.B. nicht in .NET Objekten plötzlich mit ADODB.RecordSets arbeiten, nur weil das von Access zu geliefert wird. Stattdessen Wrapper-Klassen schreiben und diese in eine separate Assembly auslagern. Die Interop-Kommunikationsschicht konsumiert dann diese Wrapper.
Ob Access-seitig auch Wrapper erstellt werden müssen hängt davon ab, ob Access schnellst möglich komnplett abgelöst werden soll, oder ob es - warum auch immer - noch längere Zeit beibehalten werden soll.

Dieses Konzept ist praxiserbrobt. Ich kann damit sogar .NET Windows.Forms als MDI-Childs im Access-Anwendungsfenster laufen lassen. Das ermöglicht eine fließende Migration von Access nach .NET. Die Formulare können Stück für Stück durch Access-Formulare ersetzt werden. Die .NET Formulare fühlen sich für den Endanwender nicht als Fremdkörper an, die sie sich wie Access-Formulare verhalten.

Nur falls das für Dich interessant ist.

Wollte mich nur nochmal zu Wort melden das du nicht denkst deine Mühe (auf meine Frage zu Antworten) war vergebens 😁

Also mein Kollega baut gerade ne Spike um die Ideen die du uns gegeben hast mal auszutesten. Hat uns auf jedenfall eine neue Denke ermöglicht und sieht bisher aus ganz gut aus was er da zusammen schraubt.
Wenn er durch ist, melden wir uns nochmal mit nem Fazit damit auch alle anderen was davon haben die das hier lesen....

Bis denne

Howard