DotNet in Access für Anfänger. HowTo Anleitung?

[Dmitry]

Guten Tag,
ich wollte nun in einer Access Datei, ein C# dll integrieren, die ich auch selbst geschrieben habe.

So, nun kommen tausende Fragen, bei denen ich selten leicht eine Antwort finden kann.
Ich bin Anfänger mit VS und C#. Benutze VS2012.

Gibt es "hello world" c# Klasse ? Anleitung wie ich solche erstelle? (also speziell für Access, com interop was auch immer)
Dann auch eine Anleitung wie ich meine DLL (am besten ohne dll-registrierung, also ohne admin rechte) in Access über DotNetLibFileManager hinzufüge und aufrufe, oder sonst irgendwie aus macros? Am besten noch mit Autocomplete von der klasse. Dann kommt noch die Frage mit dem debuggen, aber nicht so relevant jetzt.

Ziel ist eine Access Anwendung zu erstellen, mit DLL drin, so dass die Anwendung auch auf einem anderem PC genau so gut funktioniert und die DLL's benutzt, auch ohne Admin-rechte.

Ich habe schon zu viel probiert, modDirectCOM.bas oder NetComDomain.cls.. geht kaum und verwirrt mich schon. (mit NetComDomain hats geklappt, aber ohne autocomplete)
.tlb ohne Admin-rechten habe ich mit dem Tool "TlbExp.exe" realisiert. (http://stackoverflow.com/questions/3382 ... ring-build)
mit DotNetLibFileManager hinzugefügt..
dann kommt aber "Objekterstellung durch ActiveX-Komponente nicht möglich" .. wenn ich irgendwas von meinem Object aufrufen will..
Ein Umweg war mit NetComDomain.CreateObject() das Object erstellen, und einer Variable die "as myObject" defniert ist, zuzuweisen.
Dann hat man Funktionalität und Autocomplete. Ob das so gedacht war? ...

Deswegen hätte ich gern einfach klares "es wird so gemacht".

Es wäre gut ein Anleitung bzw Links, von euch zu bekommen, weil ihr es richtig einsetzen können.

Danke im Voraus.



*noch dazu kommt gleich die Frage, ob ich Drittanbieter-DLLs irgendwie in Access (mit eigener Wrapper-DLL? modifiziert?) einsetzten kann?
* wie erstelle ich die .Net Objekte mit einem Constructor, in vba?

[Sten Schmidt]

Hallo,

Gibt es "hello world" c# Klasse ? Anleitung wie ich solche erstelle? (also speziell für Access, com interop was auch immer)

das .NET-Lib Repository enthält eine ganze Reihe von Beispielen, die sind i.d.R. alle COM-Sichtbar.

Dann auch eine Anleitung wie ich meine DLL (am besten ohne dll-registrierung, also ohne admin rechte) in Access über DotNetLibFileManager hinzufüge und aufrufe

Der DotNetLibFileManager fügt ein beliebiges Binary zu einer lokalen Tabelle hinzu. Weiterhin existiert dort Code der dann beim Starten der Access-Anwendung bei Bedarf alle Files aus dieser lokalen Tabelle in das Dateisystem rausschreibt (Deployment).

Ein Beispiel von Josef habe ich in diesem Thread gefunden.

oder sonst irgendwie aus macros? Am besten noch mit Autocomplete von der klasse.

Das geht auch, hierzu muss über Verweise der Verweis auf die entsprechend generierte TLB hinzugefügt werden.

Dann kommt noch die Frage mit dem debuggen, aber nicht so relevant jetzt.

Das geht im Visual Studio über das Menü "Debuggen >> An Prozess anhängen", dort muss dann der MSACCESS.EXE-Prozess ausgewählt werden.

Ich habe schon zu viel probiert, modDirectCOM.bas oder NetComDomain.cls.. geht kaum und verwirrt mich schon. (mit NetComDomain hats geklappt, aber ohne autocomplete)

NetComDomain ist der richtige Weg, wenn die TLB als Verweis hinzugefügt wurde, dann geht auch Intellisense.

.tlb ohne Admin-rechten habe ich mit dem Tool "TlbExp.exe" realisiert. (http://stackoverflow.com/questions/3382 ... ring-build)

die Tlb kann man vom VisualStudio beim Erstellen des Projekts erzeugen lassen, hierzu müssen die 2 folgenden Zeilen in das Postbuild-Ereignis der Projekteigenschaften eingefügt werden. Die Tlb liegt dann bei /bin/debug wie auch die Dll erzeugt wird.

Code: Alles auswählen


call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
Tlbexp "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)"
 

dann kommt aber "Objekterstellung durch ActiveX-Komponente nicht möglich" .. wenn ich irgendwas von meinem Object aufrufen will..
Ein Umweg war mit NetComDomain.CreateObject() das Object erstellen, und einer Variable die "as myObject" defniert ist, zuzuweisen.
Dann hat man Funktionalität und Autocomplete. Ob das so gedacht war?

Das war schon so gedacht, schau dir mal die Beispiele aus dem DotNetControlContainer an, hier wird ebenfals CreateObject() benutzt.

*noch dazu kommt gleich die Frage, ob ich Drittanbieter-DLLs irgendwie in Access (mit eigener Wrapper-DLL? modifiziert?) einsetzten kann?

Ja sicher geht das. Modifizieren sicherlich nicht, aber zumindest einen COM-Sichtbaren Aufruf bereitstellen geht auf jeden Fall.

* wie erstelle ich die .Net Objekte mit einem Constructor, in vba?

COM unterstützt keine parametrisierten Konstruktoren, und VB/VBA auch nicht. Ich erstelle mir in diesem Fall in .NET eine Wrapper-Klasse mit parameterlosem Konstruktor und einer oder mehrerer Methoden Init_1() und ggf. Init_2() um überladene Konstruktoren darzustellen. Die Konvention lautet dann, dass immer erst eine der Init-Methoden aufgerufen werde muss. Das ist aber Geschackssache, man könnte auch über eine Factory nachdenken.


@Josef: kannst du den Thread ins richtige Unterforum verschieben?

[Dmitry]

Vielen dank für die Antwort!

Der DotNetLibFileManager fügt ein beliebiges Binary zu einer lokalen Tabelle hinzu. Weiterhin existiert dort Code der dann beim Starten der Access-Anwendung bei Bedarf alle Files aus dieser lokalen Tabelle in das Dateisystem rausschreibt (Deployment).

und DotNetLibRepair fügt die gespeicherte dateien in /lib/ und erstellt Referenzen darauf in access-datei?
Wie EarlyBindingName Parameter von dem DotNetFileManager funktioniert verstehe ich noch nicht, bzw wofür ist es da? (nur als info?)

die Tlb kann man vom VisualStudio beim Erstellen des Projekts erzeugen lassen, hierzu müssen die 2 folgenden Zeilen in das Postbuild-Ereignis der Projekteigenschaften eingefügt werden. Die Tlb liegt dann bei /bin/debug wie auch die Dll erzeugt wird.

Code: Alles auswählen


call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
Tlbexp "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)"
 

bei mir ging zuerst nicht.
dann habe ich noch /out:"$(TargetDir)$(TargetName).tlb" hinzugefügt, jetzt gehts (vllt weil das Projekt im Netzwerk liegt)
also:

Code: Alles auswählen


call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
Tlbexp "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)" /out:"$(TargetDir)$(TargetName).tlb"
 

*noch dazu kommt gleich die Frage, ob ich Drittanbieter-DLLs irgendwie in Access (mit eigener Wrapper-DLL? modifiziert?) einsetzten kann?

Ja sicher geht das. Modifizieren sicherlich nicht, aber zumindest einen COM-Sichtbaren Aufruf bereitstellen geht auf jeden Fall.

geht ohne wrapper?
Ich habe bis jetzt das nur mit eigener DLL gelöst, die externe Classenmethoden nachbildet, und externe object.methode dort entsprechend aufruft, bzw zurückgibt.
Ich sollte auch vorher das externe DLL mit strong-name unterzeichnen. (http://buffered.io/posts/net-fu-signing ... y-signing/)

Gibt es vllt ein leichteres Weg?

[Sten Schmidt]

Hi,

Wie EarlyBindingName Parameter von dem DotNetFileManager funktioniert verstehe ich noch nicht, bzw wofür ist es da? (nur als info?)

Der EarlyBindingName ist der Name bzw. der "COM-Namespace" der Bibliothek. Wenn die COM-DLL im System registriert wäre, dann wäre das der Name der Bibliothek der im Objektbrowser angezeigt würde. Die Angabe wird aber nur benötigt wenn mann EarlyBinding arbeiten will.

geht ohne wrapper?
Ich habe bis jetzt das nur mit eigener DLL gelöst, die externe Classenmethoden nachbildet, und externe object.methode dort entsprechend aufruft, bzw zurückgibt.

Das mache ich i.d.R. auch so, "ohne" ginge es m.E. nur so:

a) Die Drittanbieter-DLL ist COM-Sichtbar
b) Die Drittanbieter-DLL besitzt Klassen die nicht als sealed gekennzeichnet sind -> Ableitung erstellen und COM-Sichtbarkeit herstellen.

Aufgrund der Nachteile von COM/VB(A) sind aber häufig Übersetzungen notwendig, so dass Variante a) selten geeignet sein dürfte.

Hinzu kommt, dass die aktuelle Version der NetComDomain nur funktioniert, wenn die DLL mit .NET 3.5 (oder Vorgänger) erstellt wurde, 4.x läuft aktuell noch nicht.

Gibt es vllt ein leichteres Weg?

Ich wüsste aktuell keinen...

[Dmitry]

Vielen Dank für die Antwort, wieder!

geht ohne wrapper?
Ich habe bis jetzt das nur mit eigener DLL gelöst, die externe Classenmethoden nachbildet, und externe object.methode dort entsprechend aufruft, bzw zurückgibt.

Das mache ich i.d.R. auch so, "ohne" ginge es m.E. nur so:

a) Die Drittanbieter-DLL ist COM-Sichtbar
b) Die Drittanbieter-DLL besitzt Klassen die nicht als sealed gekennzeichnet sind -> Ableitung erstellen und COM-Sichtbarkeit herstellen.

Aufgrund der Nachteile von COM/VB(A) sind aber häufig Übersetzungen notwendig, so dass Variante a) selten geeignet sein dürfte.

Hinzu kommt, dass die aktuelle Version der NetComDomain nur funktioniert, wenn die DLL mit .NET 3.5 (oder Vorgänger) erstellt wurde, 4.x läuft aktuell noch nicht.

frage zu der Variante b)
ich habe versucht so eine dll abzuleiten (https://csv.codeplex.com/), bekomme aber die Fehlermeldung:
"Dieser Typ hat ein übergeordnetes ComVisible(false) in seiner Hierarchie. Aus diesem Grund sind QueryInterface-Aufrufe für IDispatch oder Klassenschnittstellen nicht erlaubt."
Vielleicht ist das Problem bekannt?

Oder was heißt "COM-Sichtbarkeit herstellen"? Ich habe es so gemacht:

Code: Alles auswählen


    [ComVisible(true), ClassInterface(ClassInterfaceType.AutoDual)]
    [Guid("...")]
    public class myCSVData : CSVData
    ...
 

[Sten Schmidt]

Hi,

im Prinzip würde ich denken dass es so funktionieren müsste.

Du könntest mal probieren ob es einen Untschied macht wenn du es so wie in ConditionStringBuilder.cs
aufbaust, also die abgeleitete Klasse mit ClassInterfaceType.None und ein eigenes COM-Interface mit ComInterfaceType.InterfaceIsDual...

[Dmitry]

Danke, hat geklappt.
nur dafür muss man nun für den Drittanbieter ein extra Interface erstellen, und die Methoden copypasten. (evtl. mit eigenen erweitern, falls nötig)
erst dann von dem Interface und Drittanbieter-dll ableiten.

Das ist aber immer noch leichter, als alle Methoden nachbauen.

[Sten Schmidt]

Super, schönes Wochenende!