.NET-Klassenbibliotheken für Access/VBA

[Sten Schmidt]

Kennt jemand einen günstigen legalen Zugang zu VS 2010?

Die Upgrade-Lizenzen (also die Box, nicht als VLK) sind günstig und berechtigen zum Upgrade ausgehend von z.B. Studio Express oder jeder anderen freien IDE.
Dürfte dann so in etwa 1,5 mal so viel wie ein Office Professional OEM kosten.

[Josef Pötzl]

Hallo!

zu VB.net vs. C#:
Wir können das auch mischen. Einzige Bedingung: ein VS-Projekt muss in einer Sprache sein. In eine VS-Solution kann aber gemsicht werden. Da ich sowieso mehrere kleinere Projekte mit übersdchaubaren Aufgaben erstellen will, sollte das kein Problem sein.

Beispiel SqlTools: das besteht derzeit aus 4 Projekten und 3 Test-Projekten.

Online Meeting zusammensetzen um die einzelnen Bereiche der CodeLib zu diskutieren und zu implementieren

Das wird auf jeden Fall sinnvoll sein, da man sich so am besten absprechen kann.

Außerdem könnte es hilfreich sein, wenn wir im Wiki die wichtigsten Punkte (Was kann die Lib, wie setzt man sie ein u. ä.) festhalten.
Ich werde auf jeden Fall auch im Bugtracker die einzelnen Projekte einrichten, damit wir gezielt die Fehlerbehebung koordinieren könnten. (Ein Link vom Bugtracker zum SVN-Repo erfolgt automatisch, wenn man Bug #nr bzw. Issue #Nr im SVN-Kommentar eingibt. "Bug #123 fixed" würde den Bugtracker-Eintrag als erledigt markieren.)

mfg
Josef

[Christoph Jüngling]

Kennt jemand einen günstigen legalen Zugang zu VS 2010?

Nicht zu VS2010, aber Microsoft hat gerade die Beta von VS2011 freigegeben, die darf man jetzt 300 Tage lang ( auch für Produktivcode !!!! ) einsetzen. Habe ich mir schon fix runtergeladen und installiert. Sieht gut aus, benötigt aber Win 7 ..

Ein guter Hinweis, danke

[Josef Pötzl]

Hallo!

SharpDevelop sieht auf den ersten Blick auch nicht schlecht aus und scheint kompatibel mit Visual Studio 2010 z sein. Es sollte möglich sein, die gleichen Projekt- u. Solution-Dateien zu verwenden.
Anm.: Verwendung von Subversion oder Git sowie das Starten von Tests ist fix eingebaut.

mfg
Josef

[Christoph Jüngling]

SharpDevelop sieht tatsächlich gut aus, scheitert allerdings daran, dass es NUnit nicht zu finden scheint. Im weiteren bedeutet die starke Anbindung an Subversion, dass ich Hg wohl nicht benutzen kann. Ich werde mal schauen, was sich da machen lässt.

[Josef Pötzl]

Hallo!

Ich konnte mit SharpDevelop ohne Probleme die Unit-Tests ausführen.
Anm.: ich installierte NUnit vor SharpDevelop - vielleicht lag es daran.

Bezüglich Hg: über das Dateisystem wird es immer funktionieren, oder?
Ansonsten bleibt nur noch Visual Studio - und ide Frage, ob dort Hg optimal unterstützt wird.

mfg
Josef

[Christoph Jüngling]

Ich konnte mit SharpDevelop ohne Probleme die Unit-Tests ausführen.
Anm.: ich installierte NUnit vor SharpDevelop - vielleicht lag es daran.

Ok, das habe ich gar nicht installiert, weil es gemäß der Beschreibung enthalten sein sollte. Vielleicht nur ein Verständnispropblem, danke

Bezüglich Hg: über das Dateisystem wird es immer funktionieren, oder?
Ansonsten bleibt nur noch Visual Studio - und ide Frage, ob dort Hg optimal unterstützt wird.

Sicher, rein auf Dateiebene gibt es mit Hg und hgsubversion auch keine Probleme. Allerdings unterstützt diese Extension keine SVN-externals, so dass ich dafür etwas eigenes basteln muss (post-update hook).

Wenn's läuft, beschreibe ich es mal

[Sten Schmidt]

Access-Test-Client: SqlToolsTestClient.zip

Hallo Zusammen,

ich sitze gerade an einer möglichen Integration der DotNetLibs in die AccessCodeLib, so dass der ImportWizard beim Erstellen einer neuen Anwendung alle notwenigen Schritte erledigt, um die .Net DLLs benutzbar zu machen.
Als Basis dient im Wesentlichen Josefs Testclient für die SqlTools.

Da es zukünfig ja nicht nur SqlTools in .NET geben wird, stellt sich mir gerade die Frage ob es hier auch in der CodeLib eine Trennung geben soll (z.B. SqlTools, RibbonTool, ..., die Bibliotheken sind also separat importierbar) oder ob wir einfach sagen, OK, gib mir einfach alle .NET Bibiotheken die es gibt?

Variante A: Aufteilung

• Höhere Flexibilität
• Mehr VBA Module/Klassen notwendig

Variante B: Keine Aufteilung

• weniger VBA Module/Klassen notwendig
• höhrerer Speicherplatzverbrauch (es würden immer alle DLLs importiert), ggf. Gegensteuerung durch Einsatz von ZIP-Komprimierung

Die Funktion, dass der ImportWizard automatisch ggf. vorhandene VBA-Varianten durch die .NET Version ersetzt wäre in beiden Szenarien gleichermaßen denkbar.

[Josef Pötzl]

Hallo!

Ich bin für eine Aufteilung.
Beim Import-Wizard könnte man sich überelgen, ob man ein spezielles Factory-Modul gestaltet und dort die notwendigen Methoden einfügt.

LG
Josef

[Sten Schmidt]

Moin,

Beim Import-Wizard könnte man sich überelgen, ob man ein spezielles Factory-Modul gestaltet und dort die notwendigen Methoden einfügt.

genau an diesem Problem hänge ich noch... *eigentlich* müsste der ImportWizard das Factory-Modul (z.B. DotNetLibs.cls) in Abhängigkeit der ausgewählten Bibliotheken from Scratch erstellen (weil eine Factory für jede Lib unschön ist).

Idee A:

Es müsste doch eigentlich möglich sein, das Factory-Modul für alle Libs vorzuereiten, und dann alles auszukommentieren, z.B. mit einem speziellen Tag. Während des Imports könnte der ImportWizard dann das importierte Modul mit den auskommentierten Methoden bearbeiten und die Kommentare entsprechend der Abhängigkeiten entfernen.

Idee B:

Wir erfinden einen neuen Import-Dateityp "FactoryModul_XYZ.bas.part". Je nachdem welche Abhängikgiten vorliegen, wird der Factory-Code aus den .part-Files eingelesen und in das neu generierte FactoryModul hinzugeüfgt.
Vorteil: der <use>-Tag könnte dafür eingesetzt werden.