Hallo LastGentleman,

übergibst Du während der Laufzeit Access-Objekte als Parameter an Methoden der eingebundenen .NET-Assembly?
Falls ja, wird Access nicht beendet, weil noch Verweise darauf existieren (COM-Objekte können erst zerstört werden, wenn der letzte Verweis gefallen ist). COM-Objekt innerhalb von .NET-Code auf null zu setzen, genügt nicht. Der COM-Verweis lebt solange weiter, bis er vom Müllsammler abgeräumt wird. Du musst immer Marshal.ReleaseComObject verwenden, um den COM-Verweis unter der Haube freizugeben.

Hallo tequila slammer,

falls Deine Anwendung nicht übers Internet, sondern nur im LAN kommuniziert, kannst Du das einfacher und schneller mit Remoting machen. Bei Remoting brauchst Du keine Proxies, sondern arbeitest mit gemeinsamen .NET-Typen, die beide Anwendungen kennen.

Hallo stephaaan,

Word ist absolut ungeeignet, um Rechnungen, Lieferscheine, Angebote etc. zu erstellen. Sowas solltest Du besser mit Microsoft Reports machen (ist seit Visual Studio 2005 standardmäßig eingebaut; Nicht mit Crystal Reports verwechseln). Visual Studio bringt bereits einen sehr komfortablen WYSIWYG-Editor für Microsoft Berichte mit (Siehe Screeenshot).

Detaillierte Hilfe dazu findest Du hier: http://msdn.microsoft.com/de-de/library/bb885185.aspx

Microsoft Berichte kannst Du auch in Webanwendungen rendern lassen. Außerdem kannst Du die Berichte Standardmäßig in Excel, Tiff oder PDF exportieren (mit einem Klick im Viewer). Im Vergleich zur Word-Fernsteuerung ist es locker 1000 x schneller und benötigt mindestens 5 x weniger Systemressourcen.

Mit Word kannst Du Breife, Romane, Fachartikel oder z.B. eine Diplomarbeit schreiben, aber für Rechnungen ist Word wirklich nicht Erste Wahl.

Hallo zusammen,

schön dass Euch mein Remoting-Helfer so gut gefällt. Trotz WCF bevorzuge ich nach wie vor Remoting als Technologie für verteilte Anwendungen.

@jeansen: Den Timeout kannst Du über die Channelsettings auf dem Client festlegen:

// Timeout auf 30 Sekunden festlegen
channelSettings["timeout"] = (uint)30;

@bvsn: Events solltest Du nicht unbeacht einsetzen, da Du bei verteilten Anwendungen immer damit rechnen musst, dass einer der beteiligten PCs plötzlich offline geht. Wenn der Client sein Event-ABO aber vorher nicht beendet hat, versucht der Server ihn trotzdem zu benachrichtigen. Dies versucht er, bis er einen Timeout bekommt. In der Standardeinstellung würde das bedeuten, dass die Server-Anwendung bei jeder Event-Benachrichtigung 30 Sekunden lang einfriert.
Man kann aber trotzdem Events verwenden, muss allerdings immer auf Offline-Clients prüfen. Mit der nötigen Vorsicht und der Tatsache im Hinterkopf, dass man mehrere Anwendungsdomänen hat, sind Events mit Remoting also völlig in Ordnung. Hier findest Du Infos über mögliche Event-Implementierungen mit Remoting und ihre Vor- und Nachteile http://www.codeproject.com/KB/IP/remotingandevents.aspx
Events funktionieren auch grundsätzlich mit dem Remoting-Helfer.

probier es mal so:

Array enumValues = Enum.GetValues(enumType);

Du könntest die XML-Daten mit XSLT in XSL:fo (Standard zu Beschreibung von Drucksachen mit XML) umwandeln. XSL:fo wiederum kannst Du mit nFOP ganz leicht in PDF umwandeln. Hier steht, wie das geht: http://www.codeproject.com/KB/dotnet/nfop.aspx

Hier findest Du ein Tutorial zu XSL:fo :http://www.w3schools.com/xslfo/default.asp

Hallo Matthias27,

Dein Code enthält einen Fehler!
Du rufst Dispose auf der DataTable auf, obwohl Du sie dem Grid als Datenquelle zugewiesen hast. Man ruft Dispose nicht auf, weil man Angst vor dem Task-Manager hat, sondern dann, wenn man eine Ressource nicht mehr braucht. Wenn die DataTable als Datenquelle des Grids eingestellt ist, dann brauchst Du die DataTable ganz offensichtlich noch und solltest sie nicht entsorgen.

Es wäre besser, die DataTable als Klassenvariable anzulegen. Du solltest die DataTable dann erst in der Dispose-Methode des Formulars disposen.

Statt eine Dispose-Orgie im finally-Block zu veranstalten, solltest Du besser using verwenden (das ruft Dispose am Ende des Blocks automatisch auf).

using (OleDbConnection con = new OleDbConnection(conString))
{
    // Mach tolle Datenbanksachen ....
}

.NET-Anwendungen haben eigentlich keine Speicherlecks. Falls doch, kannst Du es im Task-Manager nur schwer erkennen. .NET 4.0 soll da Abhilfe schaffen. Da wird Speicher erst dann reserviert, wenn er auch wirklich gebraucht wird. Task Manager-Paniker können dann aufatmen.

Dein Code enthält noch einen Fehler!
Sowas hier, tut man nicht:

string strSql = "SELECT Auftrag, Taetigkeit FROM Taetigkeiten WHERE Datum="
          + "#" + dt.Month + "/" + dt.Day + "/" + dt.Year + "#";

Man verwendet stattdessen parametrisierte Abfragen (Im SQL-Code Fragezeichen als Platzhalter setzen und in der Reihenfolge der Platzhalter die Werte als Paramater dem Command zufügen). Das schützt vor SQL-Injection-Angriffen und ist zudem schneller, da das RDBMS so eine höhere Chance hat den Ausführungsplan der Abfrage im Cache wiederzufinden.

string strSql = "SELECT Auftrag, Taetigkeit FROM Taetigkeiten WHERE Datum=?"

Den Designer gibts zum Nachinstallieren: Microsoft Report Viewer-Add-On für Visual Web Developer 2008 Express Edition

Das Paket heißt zwar "...Viewer-Add-On", enthält aber auch den Designer.

Den SQL Server 2008 Express gibt es auch in einer aufgebohrten Version (ebenfalls kostenlos) mit Volltextsuch-Modul und mit Reporting Services (plus 2008er Report Designer). Microsoft® SQL Server® 2008 Express with Advanced Services

Komischerweise wird diese Version mit "Advanced Services" kaum beworben.

Hallo Telefisch,

das sieht gut aus. Ich würde allerdings fast jede Zeile kommentieren. Das ist bei Reflection-Code besonders wichtig, da es für Kollegen (oder auch einem selbst, wenn man ein halbes jahr später nochmal damit zu tun hat) viel leichter ist, den Code zu verstehen.

Eleganter wird es nicht. Reflection sieht meistens nicht elegant aus. Das ist eben so. Das stört den Endanwender und meistens auch den Chef nicht, wenn es am Ende funktioniert.

Schön dass Du es doch selber hinbekommen hast.

Hallo dba,

folgendes Tool eignet sich hervorragend, um Webanwendungen und Webdienste zu debuggen: http://www.fiddler2.com/fiddler2/

Hallo itstata,

vermutlich meinst Du Fiddler: http://www.fiddler2.com/fiddler2/

Damit kannst Du sehen, was über HTTP(s) tatsächlich übertragen wird. Das schließt natürlich auch SOAP-Nachrichten ein.

Ja

Hallo proggerr,

Word ist ist nicht ideal, um Rechnungen zu schreiben (auch wenn das sehr viele Leute tun, weil sie es nicht besser wissen). Visual Studio hat seit Version 2005 einen hervorragenden Report Designer. Damit kannst Du Rechnungen frei gestalten und mit den entsprechenden Daten verknüpfen. Reports werden im RDL Format gespeichert und können sowohl in einem Windows.Forms- als auch in einem ASP.NET-Viewer angezeigt und nazürlich gedruckt werden. Außerdem lassen sich RDL Reports standardmäßig als PDF, TIFF oder Excel-Datei exportieren.

Solche Reports werden wesentlich schneller gerendert, als das mit Word möglich wäre. Code musst Du auch fast keinen schreiben.

Folgende Seite sollte DIr weiterhelfen: http://msdn.microsoft.com/de-de/library/bb885185.aspx

Hallo stephaaan,

ich verstehe nicht ganz. Was für Textfelder sind das in Word? Felder, Seriendruckfelder, Windows.Forms 2.0 Controls, .NET Controls, ActiveX-Controls? Word ist sehr allgemein. Wo genau willst Du die Daten aus dem CRM-System den reinschreiben. Direkt in ein Word-Dokument? In vordefinierte Seriendruck-Felder? In Positionsrahmen? In Textmarken?

Wie Du siehst, kann man mit Word ziemlich viel machen und fast überall gibt es irgendwelche Felder. Bitte beschreibe genauer, was Du machen willst. Was soll am Ende dabei herauskommen? In welcher Form liegen die CRM-Daten vor?

Hallo moe123,

Du musst die Makro-Sicherheit in Excel (Menü Extras) niedriger einstellen. Wenn Dir das nicht sicher genug ist oder Du das selber nicht beeinflussen kannst, musst Du die VBA-Makros mit einem Zertifikat digital signieren und der Signatur vertrauen. Dann verschwindet die Meldung ganz von allein.

Hallo Mr.Irish.Bastard,

offenbar wurde für Exchange bzw. Outlook eine Richtlinie erlassen, die Massenzugriffe blockiert. Manche Firmen bzw. deren Admins machen sowas, um DDOS-Angriffe zu vermeiden.

Das würde aber auch so nicht richtig funktionieren. Für 10 Kontakte im Testsystem ja, aber wenn z.B. mal 1000 Kontakte zu synchronisieren sind, kannst Du Kaffee trinken gehen, wenn Du das so über Outlook-COM-Automatisierung machst. Das ist einfach zu lahm dafür.

Du solltest besser direkt auf den Exchange Server zugreifen.

Je nach eingesetzter Exchange Version hast Du allerdings die Qual der Wahl zwischen unzähligen APIs, die sich im Funktionsumfang überschieden. Hier eine Übersicht: http://www.msxfaq.de/code/index.htm

Hallo Mr.Irish.Bastard,

das Outlook-Objektmodell hat einige Beschränkungen und ist in verbindung mit öffentlichen Ordnern nicht unbedingt das stabilste. Ich möchte Dir deshalb empfehlen, sowas mit Redemption (http://www.dimastr.com/redemption/) zu programmieren. Die Dokumentation dazu findest Du hier: http://www.dimastr.com/redemption/

Redemption funktioniert unabhängig von Outllook und kapselt direkt die MAPI von Windows (MAPI ist auch die Basis von Outlook). Outlook-Objekte können sogar in Redemption-Objekte gecastet werden. Mit Redemption hast Du den Exchange Server im Griff.

Öffentliche Ordner werden in der nächsten Exchange Server Version (also die nach 2007) ohne direkten Ersatz wegfallen. Deshalb würde ich mir überlegen, ob es sinnvoll ist, neue Projekte noch darauf aufzubauen. Die Nachfolgetechnologie für zentrale Informationsablage heißt SharePoint. Größere Sachen würde ich definitiv nicht mehr auf öffentlichen Ordnern aufbauen.

Hallo Telefisch,

ich helfe Dir gerne weiter, aber ich mach' Dir nicht die Hausaufgaben. Die Technologie für Späte Bindung heißt Reflection. Hier steht alles darüber, was Du wissen musst: http://msdn.microsoft.com/en-us/library/cxz4wk15.aspx

Es ist gefährlich, sich Code von jemand anderen schreiben zu lassen und diesen dann in einem Projekt zu verwenden, ohne ihn selber verstanden zu haben. Spätestens wenn die Anwendung gewartet oder erweitert werden muss, fällst Du damit auf die Nase. Arbeite Dich lieber in die entsprechenden Technologieen selber ordentlich ein. Nur wer sich weiterentwickelt, hat auf Dauer Erfolg. In wirtschaftlich schlechten Zeiten ganz besonders.

Hallo steefen.h,

hast Du es schonmal mit Outlook Redemption versucht?

http://www.dimastr.com/redemption/

Damit kommt man an so ziemlich alles ran, was die MAPI hergibt. Die Outlook Version spielt dabei keine Rolle.

Nein, leider nur für Office 2007.

Hallo demien,

soweit mir bekannt, kannst Du auf private Warteschlangen nicht entfernt zugreifen.

Warum implementierst Du die MSMQ-Kommunikation von Hand?
Mit WCF geht das wesentlich einfacher und DU musst Dich um die ganzen Details nicht kümmern.

Du solltest Dir wirklich überlegen, ob das nicht der bessere Weg für Dein Projekt ist: http://msdn.microsoft.com/de-de/library/ms731089.aspx

Hallo GIGGS,

die Ausnahme wird geworfen, da IData nicht eindeutig ist. Dem Proxy fehlt die Information, in welchen Typ er das Objekt deserialisieren soll. Du musst an dieser Stelle eine konkrete Klasse angeben. WCF arbeitet intern mit Nachrichten und nicht mit Objekten. Deshalb gelten Regeln für Objektorientierte Programmierung nicht für WCF.

Weitere Infos zur Übertragung von Auflistungen mit WCf, findest Du hier: http://msdn.microsoft.com/en-us/library/aa347850.aspx

Es gibt aber trotzdem eine Möglichkeit, beliebige Daten über eine Dienstoperation zurückzugeben. Statt einen konkreten Typ anzugeben, kannst Du Message als Rückgabetyp verwenden. Eine Message ist eine WCF-Nachricht und kann alles mögliche enthalten. Hier findest Du weitere Infos über Message: http://msdn.microsoft.com/en-us/library/ms734675.aspx

Deine genannte Literatur habe ich bereits bestellt, mal sehen welchen Nutzen ich daraus ziehen kann.

Das von mir erwähnte Buch dreht sich hauptsächlich um Enterprise Services (die .NET-Implementierung von COM+). Remoting ist nur ein Teilbereich in diesem Buch. Auch ist das Buch schon einige Jahre alt und bezieht sich noch auf .NET Version 1.x. In .NET Version 2.0 wurden aben bei Remoting einige Erweiterungen/Verbessungen/Facelifts eingebaut, die einige im Buch beschriebene Einschränkungen aufheben. Zum Beispiel war die Absicherung von Remoting-Anwendungen bei .NET 1.x nur über HTTP und mit IIS als Host möglich. Seit .NET 2.0 lässt sich Remoting auch über den TcpChannel ganz einfach mit Windows-Sicherheit absichern. Inwieweit das auf mono übertragen werden kann, weiss ich nicht.

Trotzdem ist dieses Buch sehr nützlich, weil praxisorientiert. Ein Blick in die MSDN zwecks der .NET 2.0 Features möchte ich Dir aber empfehlen.

Hallo JayKore,

ob die Remoting-Implementierung von mono genauso stabil, schnell und hochwertig ist, wie die original Microsoft Implementierung, kann ich leider nicht sagen, da fehlt mir jeglicher Erfahrungswert. Meine letzten mono-Tests (vor zwei Wochen) habe ich beendet, als ich bemerkte, dass weder DataGrid noch DataGridView (Windows.Forms) auch nur annähernd verwendbar sind und selbst bei Standard-Szenarios ständig Ausnahmen werfen. Deshalb habe ich persönlich meine Zweifel, was Qualität der mono-Implementierung angeht. Mag sein, dass dies für Remoting im speziellen nicht zutrifft, aber das kann ich - wie gesagt - nicht beurteilen. Im original .NET Framework 2.0 von Microsoft läuft Remoting aber definitiv super. Bei mono würde ich auf jeden Fall vorher intensiv testen. Hier noch Infos zur Kompatibilität von mono- und .NET-Remoting: http://go-mono.com/forums/#nabble-td22451273.

Was die Skalierbarkeit (spricht mögliche gleichzeitige Clients) angeht, sollten bei serverseitiger SingleCall-Aktivierung und ensprechender Hardware 1000 Clients kein Problem sein. Remoting verwendet den Standard-ThreadPool, der standardmäßig maximal 20 gleichzeitige Threads zulässt. Dieser Wert lässt sich aber verändern.
Wenn Du einen großen Angstzuschlag drauflegst, kannst Du immer noch 500 Clients locker bedienen. Bei SingleCall werden Ressourcen schnellst möglich wieder freigegeben und auch Multi-Core-CPUs gut ausgenutzt, da jeder Aufruf in einem eigenen Thread bearbeitet wird.

Clemens Vasters redet in seinem Buch http://www.amazon.de/NET-Enterprise-Services-Clemens-Vasters/dp/3446221530 gar von locker 2000 Clients für Remoting und das auf Basis von .NET 1.1, wo man die Größe des Thread-Pools noch nicht erhöhen konnte.

Es kommt natürlich immer auf die Anwendung im Speziellen an.

Wenn Du einen einfache Loader.EXE hast, die sich neue DLLs und sonstige Dateien über Remoting zieht und alles in einer neuen Anwendungsdomäne ausführt, hast Du einen robusten Update-Mechanismus. Da sehe ich in Verbindung mit Remoting keine Probleme. Wichtig ist nur, dass Du die Versionsprüfung für Remoting-Aufrufe deaktivierst, da die Remoting-Clients sonst nur mit Servern reden, auf denen haargenau die selben Versionen der Assemblies installiert sind. Schaltet man die Versionsprüfung ab, kann z.B. auch ein älterer Client mit einem aktualisierten Server kommunizieren, solange dieser die Schnittstelle des ursprünglichen Dienstkontrakts nicht verletzt.

Remoting ist übrigens für die Verwendung im LAN gedacht und nicht für Kommunikation übers Internet! Funktioniert zwar, aber WCF ist da eindeutig die geeignetere Technologie. Eine WCF-Implemntierung für mono bietet das olive-Projekt. In wie weit das schon produktiv nutzbar ist, weiss ich allerdings nicht.

Hallo daprodigy,

vermutlich hat die Webservice-Assenbly nicht die nötigen CAS-Rechte. Du solltest die Assembly signieren und ihr den Berechtigungssatz Fulltrust zuweisen.

Im Übrigen, kann ich einen Server auch in einer Zeile mit einem erdachten "SocketHelper" erstellen.

Da muss ich - genau wie jaensen - anmerken, dass man natürlich alles nachbauen kann, aber mit welchem Aufwand? Ist das dann betriebswirtschaftlich sinnvoll? Falls Du kein Hobby-Entwickler bist, solltest Du Dir immer die Frage nach der Wirtschaftlichkeit Deiner Projekte stellen. Ein eigenes RPC-System mit Sockets aufzubauen, obwohl es mit Remoting, WCF, ASP.NET Webservices, MSMQ und Enterprise.Services bereits hochwertige RPC-Lösungen für die verschiedensten Anforderungen und Schwerpunkte gibt, fällt unter die Rubrik "Neuerfindung des Rades".

Es gibt nur sehr wenige Fälle, in denen die direkte Socket-Programmierung angemessen und sinnvoll ist. RPC gehört nicht dazu.

Mal ganz ehrlich überzeuge mich. Das kann ich nicht garantieren, aber zum nachdenken werde ich Dich bestimmt bringen. Das ist schon der halbe Weg zur Überzeugung.

Ich möchte einen Remoting Server über den ich remote objekte aller angeschlossenen clients sowie des servers abrufen kann.

Das ist nicht sinnvoll, da sonst die Businesslogik auf dem Server z.B. direkt auf Windows.Forms-Instanzen oder Textboxen etc. zugreifen würde, die auf diversen Clients geöffnet sind. Die Geschäftslogik hat mit UI-Objekten nichts zu schaffen. Das gilt unabhängig von RPC und daran gibt es auch nichts zu rütteln.
Trotzdem ist jeder Remoting-Client auch gleichzeitig ein Remoting-Server (wenn Du statt TcpClientChannel und TcpServerChannel auf beiden Seiten immer TcpChannel - welcher bidirektional arbeitet - verwendest). Du kannst jederzeit Objekte vom Client an den Server übergeben. Diese kannst Du dann vom Server aus verwenden. So kann der Server auch seine Clients fernsteuern. Dein Wunschtraum jedes Objekt auf dem Client vom Server aus anzusprechen, ist mit Remoting sogar ohne weiteres möglich. Der Server muss die Objekte nur kennen (d.h. vom Client eine Referenz darauf übergeben bekommen).

Ich möchte callbacks wenn asynchron abgearbeitete remote Aufrufe beendet sind, parallel aber schon andere abarbeiten (egal ob auf einem angeschlossenen client oder server). Auch das ist gar kein Problem mit Remoting:

using System;
using System.Runtime.Remoting.Messaging;

/// <summary>
/// Beschreibung der Signaur für Rückruffunktionen.
/// </summary>
public delegate void AsyncWorkCompleteEventHandler(bool success);

/// <summary>
/// Ermöglicht dem Aufrufer des asynchronen Arbeitsdienstes 
/// sich über fertig abgearbeitete Aufrufe benachrichtigen zu lassen.
/// </summary>
public class AsyncWorkDoneNotifier : MarshalByRefObject
{
	/// <summary>
	/// Ereignis: Asynchroner Aufruf verarbeitet.
	/// </summary>
	public event AsyncWorkCompleteEventHandler AsyncWorkComplete;
	
	/// <summary>
	/// Feuert das AsyncWorkComplete-Ereignis, wenn Abonnenten vorhanden sind.
	/// </summary>
	[OneWay]
	public void OnAsyncWorkComplete(bool success)
	{
		// Wenn Abonnenten für AsyncWorkComplete vorhanden sind ...
		if (AsyncWorkComplete!=null)
			// Ereignis feuern
			AsyncWorkComplete(success);
	}
}

/// <summary>
/// Schnittstelle für den asynchronen Arbeitsdienst.	
/// </summary>
public interface ISomeAsyncService
{
	/// <summary>
	/// Mach was asynchrones und rufe den Aufrufer zurück, wenn Du fertig bist.
	/// </summary>
	/// <param name="notifier">Benachrichtigungsobjekt</param>
	[OneWay]
	void DoAsyncWorkAndCallbackWhenDone(AsyncWorkDoneNotifier notifier);	
}

Ich möchte außerdem, daß ich auf das byte genau zählen kann was übertragen wurde oder eine Möglichkeit wann es passiert, und ich möchte eine perfekte, absturzsichere Kommunikation und Verbindungswiederaufnahme zwischen den angeschlossenen Systemen. Ich möchte individuell auf Verbindungsabbrüche zwischen den teilnehmern reagieren können.

Sogar das ist bei Remoting drin. Du kannst eigene Kanalsenken (engl. channel sinks) schreiben. Das ist eine Art Low-Level-Plugin welches es Entwicklern ermöglicht, die bestehende Remoting-Infrastruktur zu erweitern. Mit Kanalsenken hast Du direkten Zugriff auf den Datenstrom, der übers Netzwerk geht und könntest so auch die genaue Anzahl der übertragenen Bytes ermitteln. Außerdem kannst Du so auch auf verbindungsspezifische Ereignisse wie Verbindungsabbrüche etc. reagieren. Dann hast Du auch noch die Möglichkeit eigene Remoting-Proxies zu erzeugen. Damit hast Du im Griff, wann Aufrufe abgeschickt werden.

Allerdings ist es nicht trivial Kanalsenken und eigene Proxies zu schreiben. Aber immer noch besser, als alles von Hand mit Sockets. Aber auch für solche Low-Level-Dinge gibt es eine exzellente fertige Lösung. Die heißt nicht Remoting, sondern WCF. WCf kannst Du wesentlich einfacher erweitern als Remoting, da die Erweiterungen als Behaviors (quasi Aspektorientiert) implementiert werden.

Fazit: All Deine Wünsche könntest Du mit Remoting realisieren. Noch besser vielleicht mit WCF, da Du ein Mensch zu sein scheinst, der gerne die komplette Kontrolle über die Kommunikation hat. Aber eine eigene RPC-Implementierung rechtfertigt dieser Kontrollzwang noch lange nicht.

P.S.: Ich setze Remoting seit über fünf Jahren in kleinen und großen Projekten ein und hatte noch NIE irgendeinen Absturz der Remoting-Infrastruktur und auch noch NIE einen Verbindundungsabbruch (es sei denn jemand hat am PC das Netzwerkkabel rausgezogen, oder den Remoting Server-Dienst beendet). Deine Ängste, Remoting sei nicht stabil, sind also völlig unbegründet.

Hallo alexanderfrey,

wenn Du Outlook 2007 verwendest, kannst Du die Outlook-Inspektorfenster komplett verändern: http://msdn.microsoft.com/en-us/library/bb226713.aspx

Ich persönlich sehe Remoting als reines Rumgekasper mit intransparenten Verhaltensweisen. Es erscheint mir für viele Aufgaben zu kompliziert zu ein. Dein Ansatz ein ganzes Objekt zu übertragen ist mir daher auch sehr symphatisch. Dafür bräuchtest Du auch nicht den remoting overhead. das bekommst Du mit Sockets einfacher hin.

Quatsch! Wo hat Remoting viel Overhead?
Wie viel Code musst Du für eine Socket-Implementierung schreiben und wie viel für eine Remoting Implementierung? (Denk mal genau nach und dann sag' nochmal mit Socket bekommt man was schneller hin)
Wenn es sein muss, kannst Du bei Remoting einen TCP-Server mit einer Zeile Code haben. Bitteschön: Remoting-Helfer

Wenn Du die Kommunikation absichern willst, hat Du mit Sockets noch wesentlich mehr Aufwand. Remoting kann das alles schon.

Hier ein etwas komplexeres Beispiel, was man mit Remoting machen kann: .NET Applikationsserver

Sei ehrlich, sieht das aus, wie rumgekaspert?

Könnt ihr mir da mit einem Lösungsansatz helfen?

Verwende lieber ein fertiges Kommunikations-Framework wie z.B. WCF. Da sind solche Probleme bereits vortrefflich gelöst. WCF ist seit Version 3.0 Bestandteil des .NET Frameworks. Wenn Du aus irgendwelchen Gründen noch mit .NET 1.x oder 2.0 arbeiten musst, kannst Du z.B. Remoting verwenden (ebenfalls im .NET Framework enthalten).

Alles zu Fuß mit Sockets implementieren ist in den meisten Fällen absolut unnötig und am Ende oft fehleranfällig, da es keine triviale Angelegenheit ist.

Hier findest Du eine Anleitung, wie Du mit ADO.NET auf MySQL 5 zugreifen kannst: http://www.codeplanet.eu/tutorials/csharp/5-verbindung-zum-mysql-server-mit-csharp.html

Genau. Auch wenn Du Deine Anwendung für Office 2000 schreibst, heißt das nicht automatisch, dass es mit höheren Versionen funktioniert. Wenn Du wirklich versionsunabhängig sein willst, musst Du alles mit Reflection machen (also ganz ohne PIAs und überhaupt ohne Verweise).

Hallo muecke,

wenn mehrere Benutzer gleichzeitig mit der Datenbank arbeiten, funktioniert das zwar grundsätzlich auch mit JET (Access), aber wesentlich bessere Leistung und Stabilität hättest Du da mit dem SQL Server.

Hier Codebeispiele zum Ansprechen von Access-Datenbanken über ADO.NET: http://msdn.microsoft.com/de-de/library/dw70f090.aspx#_OleDb

Wenn Du für das Projekt auch einen SQL Server (Express) einsetzen kannst, solltest Du diesen Access vorziehen.

Hallo steffen_dec,

es ist nicht nötig, einen Zusatndsautomaten in C# selber zu schreiben, da das .NET Framework 3.0 (und höher) bereits eine fertige Implementierung davon hat. Besser bekommst Du es selber bestimmt nicht hin: MSDN: Erstellen von Statuscomputern mit Windows Workflow Foundation

Dann hast Du Excel 2007 nicht installiert, sondern Excel 2000. Für Excel 2000 gibt es keine PIAs. Du musst mit den von Visual Studio generierten Standard-Interop-Assemblies vorlieb nehmen, wenn Du Excel 2000 fernstuern willst. Die Namensräume sind da allerdings ganz anders. Statt "Microsoft.Office.Interop.Excel" heißt der Excel-Stammnamensraum dann einfach nur "Excel".

Ich schlecht beim Thema Windows-Messages bleiben, wenn das, was der Themenstarter machen eigentlich will, mit Windows Messages nicht funktioniert, sondern mit NTFS.

Ähm, warum so einen Aufstand machen? InfoPath kann doch standardmäßig. Du musst nur folgendes AddIn herunterladen und installieren:
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=4d951911-3e7e-4ae6-b059-a2e79ed87041

Per Code kannst Du das dann so ansprechen:

XDocument document = infoPathApp.XDocuments.Open(@"c:\test.xml", (int)XdDocumentVersionMode.xdCanOpenInReadOnlyMode);

document.View.Export(@"C:\test.pdf", "PDF");

Das Ganze funktioniert übrigens auch mit Word, Excel, PowerPoint und Co.

Druckertreiber fernzusteuern ist in meinen Augen eine wackelige Frickel-Lösung. Deshalb weg damit.

Was haltet ihr von dieser Art Kommunikation und macht das Sinn für eine solche Anwendung?

Ich halte davon garnichts! Warum einen eigenen Webserver schreiben? Das ist Quatsch. Der IIS hat hervorragende .NET-Unterstützung und ist sehr leistungsfähig und zuverlässig (Seit Version 6.0).

Mit WCF hast Du ein fertiges Kommunikations-Framework, an dessen Qualität und Leistung Dein selbstgebasteltes vermutlich nicht mal annähernd ranscnuppern kann. Warum dann viel Zeit und Mühe investieren, um Infrastruktur-Code für die Kommunikation zu schreiben? Steck Deine Enerieg lieber in die Lösung des eigentlichen fachlichen Problems, statt ein 968sten Mini-Webserver und die 45671ste RPC-Implementierung selber zu basteln.

WCF ist nicht schwer zu erlernen (wenn man sich auf die - für das aktuelle Projekt relevanten Funktionen - beschränkt). Außerdem ist es komfortabel, schnell und flexiebel. Den IIS brauchst Du dazu auch nicht. WCF ermöglicht mit Self Hosting das Hosten von Services in beliebigen .NET-Anwendungen (z.B. einem Windows-Dienst).

Der GC kann zwei Betriebsmodi: Workstation und Server.

Für den Windows-Dienst kann (muss nicht) es die Leistung der Anwendung erhöhen, wenn Du den GC auf Servermodus umstellst. Das geht ganz einfach über die App.config: http://msdn.microsoft.com/en-us/library/ms229357.aspx

Der Servermodus ist allerdings nur für Mehrprozessor-Systeme empfohlen. Da QuadCore CPUs aber keine Seletenheit mehr sind, macht es Sinn, über den Servermodus nachzudenken.

Windows-Dienste verfallen nicht in einen speziellen Idle-Modus, nachdem sie Zeit zum wiederanlaufen bräuchten. Zumindest habe ich noch nie derartiges gehört und auch solche Phänomene noch nicht erlebt.

Das mit dem Neuanfordern war nur so eine Idee. Das musst Du ja nicht machen. Du kannst Die Nachrichten auch aus der Queue abarbeiten, wie sie reingekommen sind. Dann musst Du auf jeden Fall keine Timeouts als Drossel misbrauchen. Der Clients wird über eine Queue em ehesten in der Lage sein, alle Nachrichten anzunehmen, die an ihn gesendet wurden. Wenn der bzw die Worker-Threads mit den Berechnungen zu lange brauchen und die zeitnahme Verarbeitung geschäftskritisch ist, dann würde ich in die Kiste noch zusätzliche CPUs, und bei Bedarf mehr RAM einbauen.

Wenn der Client nicht nachkommt, solltest Du die Nachrichten zuerst in eine Warteschlange (Queue) laden und von dort mit einem Worker-Tream abarbeiten. So machen das die allermeisten Business-Systeme, die schnell viele Daten verarbeiten müssen.

Ich würde die Nachrichten dann eventuell mit einem Zeitstempel versehen und eine Zeitlimit festlegen in welcher der Client die Nachricht verarbeitet haben muss. Wenn es zu einem Stau kommt, wird so verhindert, dass der Client Berechnungen mit Nachrichten macht, deren Daten nicht mehr aktuell sind. Im Falle eines Staus würden aufgelaufende Nachrichten, die nicht im Zeitlimit verarbeitet wurden, gelöscht und neu vom Server angefordert.

Aber Hand aufs Herz, das gibt es alles schon fix und fertig und nennt sich MSMQ. Besser bekommst Du es sehr wahrscheinlich auch nicht hin.

HQL muss - ähnlich wie ESQL beim ADO.NET Entity Framework - erst in den SQL-Dialekt des Ziel-RDBMS umgewandelt werden. Das kostet Zeit. Objekte müssen erzeugt und gemappt werden. Auch das kostet Zeit. Der Ressourcenverbrauch ist im vergleich zu direkten ADO.NET-Commands und ADO.NET-DataReader enorm hoch. Natürlich nimmt man das gerne in kauf und es muss ja auch nicht schlecht sein.

Im konkreten Fall passt einfach die Argumentation nicht. Bei der Kommunikation umständliches Streaming mit zusätzlichem Kommunikationsoverhead einzubauen, um den Speicherverbrauch auf dem Server zu senken, klappt einfach nicht, wenn man man mit NHibernate das komplette Abfrageergebnis (was in diesem Fall wohl sehr groß sein kann) in eine Objektliste (und damit in den Arbeitsspeicher) schaufelt. Wenn, dann müsste man mit Paging arbeiten, was aber in Sachen Tempo trotzdem bei weitem nicht an einen DataReader herankommt.

Hallo jaensen,

schön dass Dir der Remoting-Helfer von Nutzen ist. Für die kleinen knusprigen RPC-Features morgens halb zehn in Deutschland ist die Komponente genau richtig.

Hallo electromeister,

ich weiss nicht, welche PIAs Du installiert hast, aber mit diesen hier funktioniert es auf jeden Fall: http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&DisplayLang=en

Du musst Administrator sein, um PIAs zu installieren.

Du gehst nach Installation der Office 2007 PIAs folgendermaßen vor, um einen Verweis auf Excel in Dein Visual STudio Projekt einzufügen:*Rechtsklick auf Verweise *"Verweis zufügen ..." im Kontextmenü auswählen (Es erscheint dann nach kurzer Zeit der Dialog zur Verweisauswahl) *Registerkarte COM anklicken *In der Liste der COM-Verweise nach "Microsoft Excel 12.0 Object Library" suchen und auswählen *OK klicken

Visual Studio erkannt automatisch, dass für den zugefügten COM-Verweis PIAs installiert sind und verwende die PIAs, statt eigenen Interop-Code zu erzeugen.

Dann kannst Du über den Namensraum Microsoft.Office.Interop.Excel loslegen und Deine Messwerte füllen.

Außerdem gibts hier noch zwei fertige Snippets, wie Du Daten ins Excel exportieren kannst:
Excel-Export ohne Excel (Snippet)
Excel: DataTable mittels OLEDB in Excel-Dokument exportieren

Damit solltest Du weiterkommen.

Hallo Luigi,

da schau her: http://blogs.msdn.com/infopath/archive/2004/04/19/116314.aspx

NHibernate lädt aber das komplette Abfrageergebnis in den Hauptspeicher des Server. Wenn es nun 4000 Datensätze sind, werden von NHibernate 4000 Objekte in einer Liste erzeugt (Da hast Du dann Deine 300MB). Streaming hier einzusetzten wäre deshalb voll für die Katz´ und würde statt Nutzen nur zusätzlichen Overhead erzeugen (Viele kleine Pakete machen mehr Verpackungsmüll als wenige große). Von Reduktion der Serverlast keine Spur.

Anders würde es aussehen, wenn Du das Abfrageergebnis über einen DataReader abrufen würdest. Da werden (ähnlich wie bei einem XML-SAX-Reader) nur die Datensätze in den Speicher geladen, die pro Intervall aus dem DataReader gelesen werden. Du könntest z.B. 100 Datensätze lesen und diese gleich in den WCF-Stream schicken, dann die nächsten 100 und so weiter. Der Server müsste so immer nur 100 Datensätze zur selben Zeit im Speicher halten. Das würde die Serverlast reduzieren.

Performanz und OR-Mapping (NHibernate) passen nicht zusammen. Mit OR-Mapping bist Du flexibel und komfortabel unterwegs, aber eben nicht schnell! Mit direktem Datenzugriff über properitäres SQL des verwendeten RDBMS und einem DataReader bis Du nicht so flexibel und auch nicht komfortabel unterwegs, aber verdammt schnell.

OR-Mapping ist deshalb nicht falsch, aber nicht geeignet um Abfrageergebnisse zu streamen. Ohne Streaming wird Deine Anwendung definitiv schneller sein außerdem weniger komplex (was die Wartungsfreundlichkeit erhöht).

Die Frage ist auch nicht nur "Wie viel Speicher wird auf dem Server pro Anfrage benötigt?", sondern auf "Wie lange wird der Speicher belegt?". Eine Anfrage wird vermutlich in maximal 200ms abgearbeitet sein. Wie viele Clients arbeiten gleichzeitig mit dem System und wie oft rufen die Clients die Diestbuch-Datensätze eines Tages ab? Eher alle paar Minuten, als jede Sekunde, oder?

Generell klingt Dein Ansatz durchdacht und plausibel. Kommt es aber nicht zu Verzögerungen, wenn Du ab und zu auf Timeouts warten musst? Wie oft kommt es denn im Schnitt zu solchen Timeouts, nach denen Du die Übertragungsmenge neu berechnen musst?

Wie holst Du die Datensätze aus der Datenbank? Über DataReader?

Das net.tcp-Binding von WCF ist sehr performant und Du musst Dich um die ganze Interna nicht kümmern. Ich vermute sogar, dass WCF mit binärem net.tcp-Binding performanter ist, als Deine Eigenentwicklung und dabei wesentlich stabiler, sicherer und skalierbarer ist (Besonders deshalb, weil Du von Dir selbst sagst, Dich mit der Interna nicht gut auszukennen - was keine Schande ist).

Oder gibt es einen wirklich triftigen Grund, warum Du das alles selber machen willst/musst? Overhead minimieren ist kein triftiger Grund, da auch fertige Kommunikations-Werkzeugkästen wie WCF oder Remoting kaum Overhead haben (ausgehend von binärer Serialisierung und propritärer TCP-Übertragung).

Ein eigenes Kommunikations-System mit serialisierten Nachrichten zu bauen, bedeutet, das Rad neu zu erfinden, da es genau das bereits mehrfach im .NET Framework gibt (Remoting, Enterprise.Services, System.Messaging, WCF). Es gibt viele Leute, die Ihre Client-Server-Kommunikation mit Sockets selber schreiben. Ich denke, dass das Not invented here syndrom oft eine Rolle spielt.

Hallo honkman16,

hast Du statt "Add Web Service Reference" vielleicht versehntlich "Add Service Reference" verwendet? In diesem Fall wird ein WCF Client statt eines ASP.NET Webservice Clients erzeugt. Der WCF Client funktioniert etwas anders, als man das von ASP.NET Webdiensten gewohnt ist.

Das "alte" System sollte über "Add Web Service Reference" aber trotzdem noch ohne Änderung funktionieren.

Im 3.5er Framework ist allerdings WCF die empfohlene Technologie, um Webdienste zu schreiben. Informationen, wie Du Deine ASP.NET Webdienste auf WCF migrieren kannst, findest Du hier: http://msdn.microsoft.com/en-us/library/ms730214.aspx
http://msdn.microsoft.com/en-us/library/aa738737.aspx

WCF ist definitiv ein Mehrwert. Eine Migration ist in vielen Fällen zu empfehlen.