Module aus VB.NET in C#

Kurze Frage für die die auch VB kennen:
In VB gibt es Module. Gibt es die auch in C#?

Langfassung:
Ich möchte gern eine reihe von Objecten definieren, die in alle fast Fenster eingebunden werden. Diese gehen von einfachen Strings mit einen Dateipfad bis hin zu einem DataSet, seiner initialisierung und einlesen der Daten.
Diese sollen über das Hauptfenster einfach initialisiert werden und dann überall in den Projektdateien verfügbar sein, ohne das ich dazu eigene Instanzen bespielsweise einer Klasse erstellen muß. Dies hätte dann zur folge, das ich es z.b. wieder mit zwei DataSets in unterschiedlichen Instanzen zu tun habe (was ich absolut vermeiden will).

Hallo,

falls ich dich richtig verstanden habe - wenn Du es wirklich so lösen willst bietet sich dafür das Singleton Pattern an:* Eine Instanz der Klasse

• Referenzen auf diese Instanz werden über eine statische Methode geliefert -> Jeder arbeitet mit dem gleichen Objekt.

Grüsse,
Egon

/edit: Suchwort: Singleton

Das geht zwar schon in die richtige Richtung, aber richtig ist es noch nicht. Denn ich kann so z.B. keine Prozeduren aufrufen ohne wieder eine Klasse anlegen zu müssen.

Beispiel ausn VB

Public Module thisModule
    Dim Public mySet As DataSet = New DataSet;
    Sub Main()
        Dim userName As String = "Franz"
        MsgBox("Dein Name ist " & userName)
    End Sub
End Module

???
   DataSet mySet = new DataSet();
   public void Main()
   {
            string userName = "Franz";
            MessageBox.Show("Dein Name ist " + userName);
   }

???

Egal wo ich nun im Code arbeite (in VB sogar ohne Einbindung per Imports/Using) kann ich nun sowohl auf die Klasse MySet zugreifen, wie auch auf die Prozeudure Main

Nun, du arbeitest aber nicht in VB sondern in C#
Viele machen den Fehler zu C# zu wechseln, aber noch immer die Konstrukte einer anderen Sprache nutzen zu wollen. C# bietet sooo viele komfortable Dinge an, man muss sich nur ein bisschen umschauen bzw. ein paar Tutorials oder Artikel lesen und versuchen diese dann für die eigenen Probleme zu nutzen. Man sollte sich nicht fragen: "Wie habe ich das in VB genutzt", sondern viel eher "Wie kann ich mein Problem mit den von C# angebotenen Mitteln lösen"

Warum es in C# keine Module gibt genauso wie in VB ist schnell gesagt: Module so wie sie in VB vorkommen entsprechen nicht so richtig dem Gedanken der Objektorientierung und C# legt viel Wert auf Objektorientierung.

Der Singelton ist eine sehr gute Lösung für Bibliotheken zum Beispiel. Dafür muss nur ein Objekt pro Programminstanz erstellt werden, ich denke das ist verkraftbar. Eine andere Lösung wäre eine Klasse mit lauter statischen Funktionen und Properties, wenn dir das eher zusagt, wobei ich nicht ganz nachvollziehen kann warum du so bedacht darauf bist kein Objekt zu erstellen.

Lg
Preli

Hi,

um auf Deine ursprüngliche Frage zurückzukommen:

Kurze Frage für die die auch VB kennen:
In VB gibt es Module. Gibt es die auch in C#?

Nein.

Viele Grüße,

Golo

doch 🙂

VB.NET konnte das, was C# mit nichtinstanzierbaren Klassen erst seit C# 3.0 kann, schon immer. Ganz korrekt muesstest du die Klasse dann noch mit dem Attribut StandardModule kennzeichnen, um ein komplettes Aequivalent hinzukriegen.

Man sollte sich nicht fragen: "Wie habe ich das in VB genutzt", sondern viel eher "Wie kann ich mein Problem mit den von C# angebotenen Mitteln lösen"

Die von C# angebotenen Mittel sind aber fast 1:1 die von IL angebotenen Mittel, gleiches gilt fuer VB.NET, auch wenn die beiden Sprachen komplett anders aussehen sind sie letzten Endes von der Leistungsfaehigkeit und Semantik aequivalent. Die einzigen Unterschiede zwischen C# und VB.NET sind im wesentlichen:
*C# kann compilergenerierte Felder mit Attributen ausstatten *C# kann unsafe Code (ist aber kein grosser Vorteil, weil der eh nicht eingesetzt werden sollte) *VB.NET refenziert immer die VisualBasic.dll *VB.NET besitzt standardmaessig einige Operatoren (die in der VisualBasic.dll definiert sind), die man theoretisch auch mit C# benutzen koennte, was aber wiederum keiner wirklich macht *Visual Studio generiert bei VB.NET-Projekten noch allerhand teilweise recht nuetzlichen, teilweise aber auch Bullshit-Code

//edit: Aus dem Beispielcode wuerde ich herausnehmen, das du eigentlich VB.NET meinst (weil z.B. Verwendung DataSet). Wenn du aber wirklich VB meinst (bis einschliesslich VB6), dann sieht die Sache natuerlich ganz anders aus.

Noch eine Ergaenzung und Bitte an Taladan: Aendere mal bitte den Thread-Titel in die Richtung Module aus VB.NET in C# (bzw. aus VB6 oder was halt passt). Ansonsten koennte das zu Verwirrungen fuehren, da der Begriff Modul im Sinne von .NET allgemein was ganz anderes ist (siehe ..NET-Glossar).

@Onlinegurke:

Da hast Du die aussagen gründlich falsch verstehen wollen.
Es geht hier nicht darum, ob man so eine Herangehensweise nicht auch in C# nachbilden könnte ( static geht schon seit FW 1.0 ) sondern, das man es nicht machen sollte.

Natürlich kann ich in C# auch spagettiecode schreiben, goto's verwenden,
nur globale vars benutzen, und ständig doevents aufrufen, aber dann kann
man auch gleich in vb6 arbeiten, oder in csscript.

Das hat dann nichts mit echter Programmierung ( OOP ) in c# zu tun.

was kommt denn il-technisch raus wenn man in vb.net ein modul schreibt?

Es ist richtig. Das ist Code von VB.Net. Mir fehlt einfach die typisierungsbefehl. In VB.Net hat man eben jene "Klasse" mit Modul eingeleitet. Wie kann ich das in C# machen. Immerhin muß dies möglich sein, da ja auch verschiedene Namespaces Funktionen zur verfügung stellen, die nicht an eine Klasse gekoppelt sind bzw über diese Aufgerufen werden.

die methode möchte ich sehen, die nicht über eine klasse aufgerufen wird.

die methode möchte ich sehen, die nicht über eine klasse aufgerufen wird. Yup, ich auch.

@onlinegurke: es stimmt schon, dass VB.net und C# ähnlich "mächtig" sind, da ja alles in IL umgewandlet wird. Aber mit "von C# angebotenen Mitteln" meine ich ja genau die Sprachkonstrukte und OOP-designtechnische Möglichkeiten über die hier diskutiert wird.

Lg
Preli

Es werden aber genau die gleichen Sprachkonstrukte zur Verfuegung gestellt, d.h., sogar dieselben. Die Methoden eines VB.NET Moduls werden auch ueber Klassen aufgerufen, aber das sind Klassen wie System.IO.Path, die man gar nicht instanzieren kann (das es seit FW 1.0 statische Methoden gibt ist mir klar, aber statische Klassen war m.E. eine Neuerung von C# 3.0). Der einzige Unterschied ist jetzt, das diese Module noch mit einem Attribut (StandardModule, was wie gesagt in der Microsoft.VisualBasic.dll enthalten ist) gekennzeichnet ist.

Das verursacht, dass der Compiler bei einer Methode, die ohne Klasse dasteht, automatisch alle Module in allen eingebundenen Namensraeumen durchsucht ob diese Methode da existiert. Wenn sie existiert und eindeutig ist, dann nimmt er sie, ansonsten muss der Modulename [und evtl Namensraum] noch angegeben werden. Das ist so aehnlich, als wuerde man statt System.IO.Path.Combine() nur noch Combine schreiben.

Generell gilt, dass sowohl C#, als auch VB.NET (im Gegensatz zu manchen anderen .NET-Sprachen) IL voll ausnutzen (Was mit unsafe Code gemacht wird ist mir ehrlich gesagt schleierhaft)

@FZelle: Eben drum, man bildet nichts nach, man macht nicht nur das gleiche, sondern sogar das selbe.

@JAck30lena: Ich kann es im Moment nicht ueberpruefen, aber es sollte das gleiche rauskommen wie eine statische Klasse in C# mit dem Attribut StandardModule aus dem Namensraum Microsoft.VisualBasic.CompilerServices oder so

Und wie gebe ich nun ein Modul in C# an?
Und wofür steht IL 🤔?

IL steht für intermediate language (vergleichbar mit dem Bytecode von Java, wenn dir das mehr sagt). Ein .net Programm wird nämlich nicht direkt in Maschinencode übersetzt sondern eben in diesen IL.

Warum verwendest du denn eigentlich nicht statische Funktionen oder Singleton? Dass man nämlich den Klassennamen mitangeben muss ist nicht unbedingt ein Nachteil, sondern in meinen Augen ein Vorteil (übersichtlicher, leichter nachzuvollziehen, Konflikte werden vermieden, durch Intellisense sieht man gleich welche ähnliche Funktionen es noch in dieser Klasse gibt, ...)
Und das ist ja eigentlich der Hauptunterschied wenn ich das jetzt richtig verstehe. Von der Performance her dürfte auch kein Unterschied sein, denn um es wie onlinegurke auszudrücken: im IL kommt es dann ohnehin wieder aufs selbe raus 😉

Lg
Preli

im IL kommt es dann ohnehin wieder aufs selbe raus

jain. da muss man differenzieren. ich habe berichte gelesen, in denen bei bestimmten dingen in vb und c# anderer il-code generiert wurde, wobei die funktionalität dennoch die selbe war. aber diese unterschiede waren eher selten. deshalb meine frage, was als il rauskommt.

Hallo,

aber statische Klassen war m.E. eine Neuerung von C# 3.0

Seit 2.0.

Gruss
tscherno

Hallo Forum,

ich habe folgendes Problem:
Es besteht ein altes, riesiges VB-Projekt, welches über eine Mainform "gesteuert" wird bzw. alle Instanzen erzeugt ect.. Nun soll die VB-Mainform gegen eine in C-Sharp programmierte Mainform ausgetauscht werden.

Im Internet fand ich lediglich, dass ich ein neues C-Sharp-Projekt zu den bestehenden VB-Projekt hinzufüge, die Referenz des VB-Projektes dem C#-Projekt hinzufüge und den Namespace des VB-Projektes benutze. Nun kann ich wie erwartet Instanzen erzeugen ect. vorab die Frage: Macht das bisher alles so Sinn?!

Nun konkret zum Problem:
Das VB-Projekt benutzt Module zur Initialisierung der VB-Mainform, welche ja lediglich von C-Sharp nicht verwendet werden sollte bzw. gegen die objektorientierte Programmierweise entsprechen. Wie kann ich jedoch diese Module nutzen, falls wirklich nur die Mainform gegen eine in C-Sharp programmierte Mainform ausgetauscht werden soll ?!?!

Vielleicht weiß jemand konkreten Rat und vorab danke!

Gabriel

Es besteht ein altes, riesiges VB-Projekt, welches über eine Mainform "gesteuert" wird bzw. alle Instanzen erzeugt ect.. Nun soll die VB-Mainform gegen eine in C-Sharp programmierte Mainform ausgetauscht werden.

Wozu?

Das VB-Projekt benutzt Module zur Initialisierung der VB-Mainform, welche ja lediglich von C-Sharp nicht verwendet werden sollte bzw. gegen die objektorientierte Programmierweise entsprechen. Wie kann ich jedoch diese Module nutzen, falls wirklich nur die Mainform gegen eine in C-Sharp programmierte Mainform ausgetauscht werden soll ?!?!

Module sind lediglich static Classes, lassen sich also ganz normal mit ModuleName.Funktionsname aufrufen.

Hallo FZelle,

zu deiner Frage: Die Mainform soll ausgetauscht werden, da künftige Formen und Code nur noch in C-Sharp geschrieben werden sollen. Dabei werden in Zukunft oft Elemente verwendet, die VB gar nicht besitzt.

Zu deiner Antwort. Danke, aber das selbe dachte ich mir auch, dass ich auf die Member zugreifen kann. Jedoch ist das Module in meinem Namespace gar nicht sichtbar !?! D.h. ich kann gar nicht zugreifen, weil es nicht angezeigt wird. Ich habe alles probiert. Das Module als public deklariert, das Module als Klasse deklariert...ect.

Und nun weiß ich nicht mehr weiter...

Dabei werden in Zukunft oft Elemente verwendet, die VB gar nicht besitzt.

Und welche sollten das sein?

Wenn die DLL in der die Module enthalten sind auch als verweis eingebunden sind, solltest Du sie auch erreichen können.

Und welche sollten das sein?

Wir benutzen Measurement Studio für sämtliche Messverfahren. Mein Kollege meinte, dass es dort Klassen ect. gibt die nicht in der VB-Version verfügbar sind. Zu der Hauptfrage: Ist es sinnvoll ein Projekt mit verschiedenen Code zu haben?! Ich denke die Frage ist rhetorisch und somit NEIN! Aber verwendet man des Öfteren so ein Konstrukt ?!

Zu deiner Antwort:
Ich habe nachgeschaut, die Module sind nicht in einer DLL gebunden. Ich weiß somit nicht, warum ich nicht über Module.Member auf die Module zugreifen kann
Viele Grüße
Gabriel

Ja man hat das sogar ziemlich häufig, gerade wenn es Komponenten gibt die in VB.NET, C# oder Managed C++ eingekauft werden.

Aber das es klassen geben soll die man von VB.NET aus nicht benutzen kann, wäre mir neu.

Da man C# und VB.NET nicht in einem Projekt mischen kann ( zumindest in VS.NET ) müssen die Teile jeweils in getrennt zu kompilierenden Assemblies stehen.
Und somit musst du die Assembly mit VB.NET auch "nur" als Verweis einbinden.