[vb.net - 3.5] Interop.MSWinsockLib.dll - Installation ?

[Pixel1001]

Hallo liebe Gemeinde,

bei der Verwendung des Winsock-Contols (Interop.MSWinsockLib.dll) erhalte ich nach dem Installieren (InnoSetup) folgende Meldung beim starten:

Fehler beim Start:

Creating an instance of the COM component with CLSID {248DD896-BB45-11CF-9ABC-0080C7E7B78D} from the IClassFactory failed due to the following error: 80040112.

Das 3.5-Framework ist natürlich installiert.

Installiere ich auf dem PC z.B. die kostenlose Vb.net 2008 Entwicklungsumgebung

funktioniert die Anwendung ohne Probleme. Also nicht einmal den Quellcode geöffnet, nur die Exe gestartet und es funktioniert.

Deinstalliere ich nun die Entwicklungsumgebung funktioniert die Anwendung weiterhin.

Ja, und nun?

Hat eine® einen Tip für mich?

Oder kennt jemand ein gutes Beispiel, wie die Kommunikation mit vb.net - Mitteln genau so gut (Event bei Dateneingang, Connect usw.) funktioniert?

Ach so, habe einige Bsp. für Consolenanwendung gefunden, wo eben nur einmal eine Verbindung aufgebaut wird, --> Daten gesendet werden --> Verbindung getrennt wird. Naja, ist nicht so Top, da jeder Client eine ID bekommt und dann den ganzen Tag mit der ID auskommen soll. :mod:

Wobei mich schon das Interop - Problem beschäftigt, es muss ja einen Trick geben. Eventuell fehlt ja bei der Installation eine Komponente?? Spricht ja aber gegen das Framework.

Pixel1001.

[Argbeil]

Bei der winSock reicht es nicht die Datei zu kopieren und zu registrieren es gibt da noch weiter Abhängigkeiten, hab ich aus alten VB6 Zeiten noch negativ in Erinnerung. Einfach mal googlen.

Zu der zweiten Frage: Die Kommunikation mit .NET Mitteln funktioniert generell deutlich besser als mit Winsock/COM. Es gibt da ziemlich viele Möglichkeiten, von System.Net.Sockets über Webservices und WCF ist das ein breit gestreutes Feld.

Was hast du denn vor?

[Pixel1001]

Hallo Argbeil,

nun habe ich mich dazu durchgerungen doch alles ohne Interop zu realisieren.

Es ist mein erstes Projekt in .net, habe bisher fast alles mit VB6 gelöst.

Hier wird ein Dienst benötigt, der ein Transponderschloss (Addimat) vom seriellen Port abhört und an einen Applikationsserver per TCPIP meldet. Dabei wird vom Server die Anmeldeinformation (Name usw.) zurück gegeben. Um nun am Clientrechner den Dienst zu überwachen bzw. Einstellungen vorzunehmen, wird eine hörende Verbindung (Listen) benötigt, die dann als GUI agiert.

Naja, nun läuft es Dank einer nachgebildeten Winsock-Funktion von

CodeProject: Winsock Revamped. Free source code and programming help.

Aber nun habe ich bei einigen Funktionen doch seltsame Effekte. Alles reagiert etwas weicher - eher wie von Java gewohnt. Schaue ich mir einmal die Firewall an bleiben beim Listen Ports noch eine Zeit offen, NetStat zeigt auch noch ein gewisses nachhängen von offenen Ports.

Aber ich gebe nicht auf und werde einwenig testen, nur dieses mal rennt einwenig die Zeit, und einen Dienst mit dem OCX für VB6 wollte ich im Jahr 2009 auch nicht mehr weitergeben.

Pixel1001

[Argbeil]

Interop ist auch überflüssig wenn es .NET seitig die entsprechenden Komponenten gibt.

Die Codeplex Klasse kenne ich nicht, deswegen kann ich auch zu dem Verhalten nichts sagen, du kannst aber alles mit der Socket Klasse aus dem Framework lösen. Die kann synchron oder asynchron verwendet werden und kann das gleiche was die WinSock Komponente kann, die verwenden unter die Haube die gleiche API.

[Pixel1001]

Ja, nur benögtigt das DURCHWÜHLEN der ganzen Informationen schon seine Zeit.

Bei einem gewissen Zeitdruck ist das schon ein Kostenfaktor, besonders dann, wenn bestimmte Funktionen unter VB6 mit 10 bis 20 Zeilen Code voll und stabil zum Erfolg führen.

:confused:

Nur mal so am Rande:

Alle reden davon, dass alles viel besser ist, naja das klingt immer so wie jetzt kannst du mit der Kaffeemaschine endlich ein Foto machen, nur rumdrehen darfst du sie nicht, da das Wasser ja raus läuft... aber dann kannst du ja noch die Stöpselklasse nutzen, die dieses Problem viel besser löst, ... kann ja mehrfarbig sein.

Aber dann kommt einer und sagt: Ich will doch nur Kaffee haben !?

Ja, der ist Out... der nimmt ja noch die API, die die neue Maschine auch nimmt.

Aber ich benötige ab jetzt die neue Kaffeemaschine.net, denn mein Kaffee soll auch noch auf dem Kaffeefilterserver2008 und mit dem Kaffee7 funktionieren. Über mein geistiges Eigentum mache ich mir schon lange keine Gedanken mehr, da ich vor meinem Spiegel auch nix vercrypte. Er soll ja reflektieren warum nicht auch meine Anwendung?

Der Trend ist ja erkennbar... jahrelang der Kampf der Elektronikindustrie für entspiegelte Mattscheiben, dann kam das TFT und es spiegelte nicht... aber so kann es ja nicht bleiben also: Schminkspiegel mit Tastatur und Internetanschluß. :uli Toll.

Übrigens, die alte Maschine kommt mit 1000W aus und die neue ist dann Green.net mit Farbdisplay 2.3 KW - aber 2.3 ist weniger wie 1000 . :upps

Also geht es los.

Liebe Grüße,

Pixel1001.

[Argbeil]

Da haste recht, 20 Zeilen Code benötigst du jetzt natürlich nicht mehr, unter .NET sollten es deutlich weniger sein.

Das mit der Kaffemaschine finde ich nur bedingt lustig, hört man aber immer wieder (früher war alles besser, haben wir schon immer so gemacht, ich will nichts neues lernen, objektorientierung braucht man nicht, ... ). Mit VB6 kannste das auch lösen, es läuft auch unter Win7. Ob das langfristig besser ist muss jeder selbst entscheiden.

[Pixel1001]

Also nicht falsch verstehen, der Weg führt nicht an .net vorbei, dass eine Umstellung auch manchen Ärger auf den Tisch bringt ist ja vorprogrammiert.

Ich betrachte viele Dinge eher Neutral...

Nur sollte nicht alles was da NEU auf den Markt kommt immer so Blind :cool: hingenommen werden. Ich denke nur an den Bereich Hifi-Highend nur wass Geld bringt wird vermarktet, ist richtig - hat den Namen MP3 - und klingt schlechter als eine CD, wobei Speicher im Jahr 2009 keine Rolle spielt.

Liebe Grüße,

Pixel1001.