Forenbeiträge von Rainbird Ingesamt 3.728 Beiträge
In der englischen Indigo MSDN-Dokumentation steht:
With the release of "Longhorn", ASP.NET provides a system-wide facility for managing application domains and operating system processes. This allows "Indigo"-based services to be activated on demand based on messages that arrive on any properly configured transport. "Indigo" has built-in support for TCP, HTTP, and interprocess communication (IPC) transports. "Indigo" hosting allows applications to be associated with uniform resource identifier (URI) suffixes much like the IIS model for mapping URI suffixes to virtual roots. Unlike IIS, however, "Indigo" is not tied to a particular transport protocol or programming model.
Genaueres weiss ich momentan auch nicht. Ich werde es posten, wenn sich mein Wissensstand ändert.
Hallo,
das folgende Schulungsvideo von Ralf Westphal finde ich für den Einstieg in .NET Remoting super. Es werden die wichtigsten Konzepte anschaulich erklärt und man bleibt nicht mit "gefährlichem Halbwissen" zurück.
http://www.microsoft.com/germany/msdn/nettv/folge1.mspx
Folderder Artikel sollte eventuell verbleibende Fragen klären:
http://www.microsoft.com/germany/msdn/library/net/DasNETRemotingFrameworkEntwicklungVerteilterApplikationenAufBasisDesNETFrameworks.mspx
P.S der Link funktioniert nur, wenn er direkt in Browser eingegeben wird. Sorry, ging nicht anders.
Hallo Schattenkanzler,
Mit Multithreading solltest Du Dich auskennen. Mach es lieber gleich mit den richtigen Technologieen. Mit C# ist Multithreading recht einfach anzuwenden.
der folgende deutsche MSDN-Artikel dürfe Dir weiterhelfen:
http://www.microsoft.com/germany/msdn/nettv/folge7.mspx
Schau Dir auch mal das Schulungsvideo an:
Eine CORBA Interoperabilitätsschicht ist meines Wissens nach nichts geplant. Indigo wird Dienste wie Enterprise Services, Webservices, Reliable Messaging (MSMQ) und Webservice Security besser integrieren. Im Prinzip nichts neues, außer dass künftig alles über ein einheitliches .NET 2.0 Programmiermodell verfügbar ist. Damit wird die Entwicklung einfacher.
Folgender MSDN-Artikel stellt Indigo und die Neuerungen kurz vor:
Wenn Du Indigo schon mal ausprobieren möchtest, kannst Du Dir die Beta 1 RC kostenlos ziehen (Indigo wird es nicht nur für Longhorn geben, sondern auch für XP und Windows 2003 Server):
Zum Hosting: Indigo-Webservices können in eigenen Anwendungen gehostet werden (ähnlich .NET Remoting / Java RMI) oder in den neuen Windows Activation Services (Hat nichts mit der Produktaktivierung zu tun) aufgehängt werden. Vermutlich ist das mit dem Komponentendiensten-Katalog unter Windows vergleichbar.
Komponenteneigenschaften wie z.B. Transaktionsunterstützung, Objektpoolgröße etc. werden wie bei Enterprise Services Komponenten als Attribute im Code bzw. in einer XML-Konfigurationsdatei pro Webservice gepflegt.
ES-Komponenten werden zwar als COM+ Komponenten angelegt, haben aber ansonsten nix mit COM am Hut (Vorrausgesetzt man setzt nur Bibliotheksanwendungen ein). ServicedComponents sind nicht für COMInterop registriert. Das lässt sich einfach beweisen.
[COMVisible(false)]
public class MyComponent : ServicedComponent
{
// ...
}
Obwohl diese Klasse explizit keine COM Schnittstelle hat, funktioniert sie trotzdem als COM+ Komponente.
Enterprise Services werden bald durch Indigo (Longhorn) abgelöst. Momentan sind sie aber noch Stand der Dinge. ES ist momentan die skalierbarste, sicherste und performanteste Lösung für verteilte Anwendungen im Windows Umfeld. Eine gute Übersicht über ES bietet das folgende Schulungsvideo:
http://www.microsoft.com/germany/msdn/nettv/folge3.mspx
Remoting ist tatsächlich zum einfachen Aufruf von entfernten Objekten gedacht. Um die Sicherheit muss sich der Programmierer selbst kümmern (im Gegensatz zu ES). Ein .NET Remoting Host ist eben kein Application Server. Implementiert wird das als sogenannte Senken, die im Channel verankert werden. Habs aber noch nie gemacht.
Der Overhead beim Remoting hält sich in Grenzen wenn Du binäre Serialisierung verwendest. Bei XML Serialisierung bläht sich alles auf. Eine Methode auf einem anderen System über eine LAN-Verbindung dauert auf jeden Fall VIEL länger als ein prozessinterner lokaler Aufruf. Daran sollte man beim entwickeln verteilter Anwendungen immer denken. Klotzen anstatt Kleckern heißt die Deviese. Events über Remoting sind generell nicht ratsam. Auch bei ES nicht. Über Internet sowieso nicht. Zu langsam.
Binäre TCP-Channels sind generell nicht Firewall freundlich, da extra Ports geöffnet werden müssen etc. Bei einer Anwendung mit vielen Benutzern an unterschiedlichen Standorten sollte man das bedenken.
Hier ein kleines Video zu Remoting: http://www.microsoft.com/germany/msdn/nettv/folge1.mspx
Wenn Deine Anwendung Internet fähig sein soll, solltest Du WebServices verwenden. Das ist ein offener internationaler Standard. Für Webservices gibt es ein extra Sicherheitspaket für .NET 1.0/1.1 (In .NET 2.0 ist es von vorne herein integriert). Alle werden bald Webservices verwenden, um ihre Clients mit der Geschäftslogik zu verbinden, denn Indigo basiert auf Web Services.
EDIT: Diese Informatioenen sind mittlerweile überholt. Indigo heißt jetzt WCF und wurde mit dem .NET Framework 3.0 veröffentlicht. Remoting unterstützt seit Version 2.0 nun auch Authentifizierung mit Kerbeos oder NTLM2. Die Aussage dass Indigo (WCF) auf Webservices basiert, ist so auch nicht ganz richtig. WCF ist die aktuelle Technologie, um Webservices zu schreiben, würde es besser treffen.
Wenn es eine geschäftskritische Anwendung mit Windows Forms ist, würde ich Enterprise Services nehmen. Damit hast Du einen vollwertigen Anwendungsserver für Deine Anwendung. Egal ob es 10, 500, 1000 oder 10.000 gleichzeitige user sind, mit einer Enterprise Services Architektur wird Deine Anwendung nahezu grenzenlos skalierbar.
Weltweit agierende Unternehmen mit vielen Standorten benötigen eine zuverlässige Infrastruktur. Damit wäre bei ES mit Message Queueing und verteilten Transaktionen genüge getan. Webservices sind für ES auch kein Problem. Ein Klick im Komponentendienste Tool von Windows reicht, um eine COM+ Komponente über SOAP ansprechbar zu machen.
Viele Entwickler schreiben haufenweise Code für Dinge wie Transaktionshandling, obwohl ES das alles schon bietet. Zum Nulltarif. Der Entwicklungsmehraufwand beim coden der Komponenten hält sich auch in Grenzen. Das meiste wird von Attribute im C# Code abgedeckt.
Als Technologie für aufstrebende Unternehmen sind ES auf jeden Fall einen Blick wert. Ebenfalls zu empfehlen ist der BizTalk Server 2004. Der gibt Unternehmen die Flexibilität Geschäftsprozesse und Geschäftsregeln grafisch zu modellieren und schnell zu ändern.
Hallo,
ich habe demnächst das Vergnügen, eine größere Anwendung mit ServicedComponents (COM+) zu entwicklern. Die Theorie hab ich bereits verinnerlicht. Ich hab aber noch keine größeren Projekte damit gamcht. Hat jemand Erfahrung mit COM+ und kann mir vielleicht ein paar Tipps geben?
Wie verwalte ich am besten Konfigurationsdaten für Komponenten (z.B. ConnectionStrings)?
Wie ermittle ich die optimale Objektpoolgröße für gepoolte Objekte?
Übernehmen transaktionale Komponenten automatisch Transaktionen, die innerhalb von BizTalk Server 2004 Orchestrations gestartet wurden?
Wie sollten Komponenten und COM+-Anwenungen am Besten versioniert werden?
ja, mach ich.
War blöd von mir.
Kommt nicht wieder vor.
Hoffentlich kommen wir künftig trotzdem gut miteinander aus.
Hallo javabunch,
was meinst Du mit speichern wer gerade angemeldet ist. Du kannst jederzeit Environment.UserName aufrufen, um den Namen des aktuell angemeldeten Benutzers zu erfahren. Weisst Du nicht, wo und wie Du am Besten die Benutzerrechte für Deine Anwendung ablegen sollst?
Eine verschlüsselte XML-Datei etc. ist dafür bestens geeignet. Wenn Deine Anwendung im Netzwerk läuft, solltest Du aber eher eine SQL-Datenbank bzw. ActiveDirectory zur Speicherung der Sicherheitsinformationen verwenden.
Ich würde dem ASP.NET Benutzer keine Rechte auf der Datenbank geben. Der ASP.NET Benutzer ist grundsätzlich nicht vertrauenswürdig.
Besser einen speziellen Benutzer für den Datenbankzugriff anlegen. Das kann auch ein SQL-Server interner Benutzer sein. Mit dem SQL-Benutzer "sa" kannst Du Dich an der Datenbank anmelden und neue Benutzer anlegen. Mit Kommandozeilentools konnte ich mich noch nie anfreunden. Du kannst das auch mit Microsoft Access machen (ADP-Projekt anlegen , Deine Datenbank auswählen, Menü Extras -> Sicherheit -> Datenbanksicherheit) wenn Du keinen Enterprise Manager hast.
Wenn Du SQL-Benutzer anstatt Windows-Benutzer zum Anmelden an der Datenbank verwendest, musst Du natürlich Deinen ConnectionString ändern.
Du hast den Sinn von MDI (Multipe Document Interface) nicht richtig verstanden. Ein MDI Formular dient als Container für andere Formulare. Auf dem Hauptformular plaziert man keine Buttons im MDI-Bereich. Man dockt am oberen Rand ein MainMenu und eine ToolBar an. Menüs des MDI-Child der gerade den Fokus hat, werden standardmäßig in der Menüleiste des Hauptformulars angezeigt. Das ist das Verhalten, das man mit MDI erreichen möchte.
Wenn das für Deinen Anwendungsfall nicht passt, dann verwende SDI (Single Document Interface). Um viele Details überischtlich in einem Formular darzustellen, verwendest Du am besten Register.
Orientiere Dich an Anwendungen die jeder kennt (z.B. Word, Excel, Windows-Explorer), wenn Du Oberflächen bauen willst, die von den Benutzern akzeptiert werden sollen. Für Menüs gibt es z.B. ein extra Steuerelement. Das solltest Du auch benutzen. Dann sehen Deine Menüs wie bei den meisten Windows-programmen aus. Benutzer Deiner Software werden sich besser zurechtfinden, wenn die Bedienung intuitiv ist.
Hallo,
das geht mit dem ByteFX.Data Paket.
http://sourceforge.net/projects/mysqlnet/
.NET bzw. Mono hat ein standardisiertes Modell für den Datenzugriff. Deshalb können ohne größeren Aufwand neue Datenbanken angebunden werden. Solche Provider bestehen immer aus Connections (Verbindungen), Commands (Befehle) und Data Adapters (Synchronisierungskomponente). Der Provider für MySQL bzw. PostgreSQL im ByteFX.Data Paket fühlt sich deshalb genauso an, wie zw. System.Data.OleDb.
Es gibt ein DataGrid für ASP.NET WebForms und eines für Windows Forms. Das Web DataGrid sollte unter Mono kein Problem sein.
Windows Forms sind momentan immer noch etwas problematisch bei mono. Unter Windows wird zum zeichnen der Fenster intern das Windows-API aufgerufen. Natürlich steht das Windows-API unter Linux nicht zur Verfügung. Ein Ansatz, um trotzdem in den Genuss von Windows Forms zu kommen, ist WINE. Alternativ gibt es eine Windows.Forms Implementierung die alle Fenster mit einer Vector Engine zeichnet. Letztere Möglichkeit ist für die Zukunft sehr vielversprechend. Leider befindet sich diese Version noch in der Entwicklung und sollte deshalb momentan noch nicht produktiv eingesetzt werden.
Hallo,
in der Datenbank wird das Bild als Byte[] gespeichert. Folgender Code ließt die gespeicherten Bilddaten aus einer DataTable und erzeugt daraus ein Bild (Bitmap-Objekt):
// Bildrohdaten aus dem Datenbankfeld lesen
byte[] imageRawData=(byte[])table.Rows[0]["Datenbankfeldname"];
// Bildrohdaten in einem MemoryStream öffnen
MemoryStream stream=new MemoryStream(imageRawData);
// Bild aus den Rohdaten erzeugen
Bitmap myPic = new Bitmap(stream);
Genauso einfach kann man ein Bild in der Datenbank ablegen. Hier das Beispiel:
// Neuen MemoryStream öffnen
MemoryStream stream=new MemoryStream();
// Bilddaten in den MemoryStrem schreiben
myPic.Save(stream, ImageFormat.Jpeg);
// Bildrohdaten in der Datenbank ablegen
table.Rows[0]["Datenbankfeldname"] = stream.ToArray();
Die Bilddaten werden mittels Bitmap.Save in einen MemoryStream geschrieben. Dabei muss das Bildformat angegeben werden (z.B. JPEG). Mit dem MemoryStrem kannst Du die Rohdaten über die Methode ToArray als byte[] in die DataTable schreiben.
Hallo,
Entweder Du verwendewst ODBC anstatt OLEDB (Namesprache System.Data.Odbc) oder Du baust Dir eine Komponente, die Verbindungen verwaltet. Die Connectionstrings könnten z.B. in einer XML-Datei gespeichert werden.
Hallo,
wenn Deine Anwendung ihre Daten auf einem SQL Server speichert, bietet sich SQL Server CE für den PDA an. Die Daten können zwischen dem großen SQL Server und der CE Version repliziert werden. Große XML files würden evtl. den Arbeitsspeicher des PDS zu sehr belasten und die Verarbeitung mittels XmlReader macht nicht wirklich Spaß.
Infos zum SQL Server CE findest Du im MSDN unter:
Ich hab wohl irgendwas falsch gemacht. Sorry.
Bei den nächsten Beiträgen klappts bestimmt besser 😄.
Dann hab ich wohl was falsch gemacht.
Tut mir leid!
Hi,
Du musst TableStyles und ColumnStyles verwenden, damit das geht. Angenommen Du hast normale Textspalten (DataGridTextBoxColumn) als ColumnStyles festgelegt. Jedes DatagridTextBoxColumn-Objekt hat eine TextBox-Eigenschaft. Über diese Eigenschaft kann der **BackColor **gesetzt werden.
So müsste es rein theoretisch klappen. Ich bin jetzt noch nicht dazu gekommen, es auszuprobieren. Sag bescheid, wenns doch nicht klappt.
Hallo,
die GroupBox unterstützt nur einfache Datenbindung. Das heißt, daß ein bestimmter Wert an eine beliebige Eigenschaft der GroupBox gebunden wird. Es gibt aber keine Eigenschaft Value oder etwas vergleichbares bei der .NET GroupBox. Die GroupBox gibt auch keine Datenbindung an RadioButtons weiter etc. GroupBoxen sind nur Container für andere Controls. Bei RadioButtons ist allerdings sichergestellt, dass in einer Gruppe von RadioButtons immer nur einer "Checked" ist. Das hat aber nichts mit der GroupBox direkt zu tun. Es funktioniert z.B. auch mit einem Panel.
Die Arbeitsweise von Access ist nicht direkt auf .NET Projekte übertragbar. Du wirst wohl eine Funktion schreiben müssen, die entsprechend dem Tabellenfeld den richtigen RadioButton auf Checked=true setzt.
Für DataGrids gibt es die Möglichkeit **ColumnStyles **zu programmieren. Auf diese Weise können spezielle Controls für die Darstellung einer Zelle ins DataGrid eingebracht werden. Ich habe z.B. schon datenabhängige Symbole und ComboBoxen in ein Datagrid integriert. Aber eine vernüftige Navigation durch eine komplexe Hierarchie lässt sich damit wahrscheinlich nicht machen.
Ich würde ein TreeView für die Navigation verwenden und die Detailansicht mit dem DataGrid synchronisieren. Es kann auch lohnend sein, aus dieser Kombination ein UserControl zu machen. Dann kann man es immer wieder einsetzen (Stichwort wiederverwendbarer Code).
Hi,
Du könntest Dir auch einen .NET Remoting Host bauen und Deine Geschäftslogik dort ablaufen lassen. Den Host kannst Du z.B. auf dem SBS Server laufen lassen, wenn kein separater PC dafür zur verfügung steht. Natürlich muss das .NET Framework dort installiert werden. Das sollte aber kein problem sein.
Dann schau doch mal bitte im Themenbereich "ADO.NET" ins Thema "Datenbanken". Dort musste ich einen Beitrag in 3 Beträge aufteilen, weill ich beim speichern ständig die Meldung "Mehr wie 1.000.000 Zeichen sind nicht möglich" bekam. Ich wurde dort gleich vom Moderator angemeckert, warum ich nicht in einem Beitrag poste.
Du sagst, dass es das Problem nicht gibt und der Moderator Noodles sagt, ich soll gefälligst in EINEM Beitrag posten.
Ich stell mir grad vor, wie es ist, wenn man komplexere Codebeispiele veröffentlichen will. Die kommen sehr schnell über die Längenbegrenzung.
Vielleicht bin ich auch ein alter Labersack und habe deshalb solche Probleme.
Ich wollte in einem Beitrag posten. Leider kam die Meldung "Mehr wie 1.000.000 Zeichen nicht möglich". Es geht nicht. Ich musste den Text in verschiedene Beiträge aufsplitten. Ich habe diese Längernbegrenzung bereits im entsprechenden Themenberich kritisiert.
Leider zeigt niemand Verständnis für mein Problem. 1.000.000 Zeichen ist nicht viel. Warum ist die Beitragsgröße überhaupt beschränkt? In anderen Foren habe ich des öfteren solch große Beiträge gepostet und es gab nie Probleme.
Sorry, aber Eure Begrenzung der Nachrichtenlänge ist bescheiden. Wenn man etwas nur halbwegs ausführlich erklären will, muss man 3 Beträge erstellen, weil es in einen nicht passt.
Festplatten sind doch billig. Vor 15 Jahren hätte ich das verstanden.
Die Funktion kannst Du aufrufen, sobald das TableNewRow-Ereignis der betroffenen DataTable (Datenquelle für das DataGrid) gefeuert wird. Auf diese Weise hast Du sofort einen gültigen ID und musst nur wenige Bytes vom DB-Server abrufen, anstatt die ganze Tabelle neu abzurufen.
Eine Möglichkeit ist, die automatische Vergabe von IDs in der Datenbanktabelle abzuschalten. Dann musst Du Dich aber selbst darum kümmern, dass neue Datensätze einen eindeutigen Schlüssel bekommen. Üblicherweise verwaltet man in solchen Fällen die Schlüssel in einer separaten Tabelle. Dann musst Du Dir nur eine Funktion bauen, die in der zentralen Schlüsseltabelle den höchsten ID um 1 erhöht und diesen ID zurückliefert. Um ganz sicher zu gehen, dass bei gleichzeitigen Zugriffen keine doppelten Schlüssel vergeben werden, solltest Du eine Transaktion verwenden.
...
Während der Benutzer den neuen Datensatz im DataGrid editiert, besteht keine Verbindung zur Datenbank. Deshalb kann das DataGrid auch unmöglich den Autowert bekommen. Beim speichern der Änderungen durch den DataAdapter wird der neue Datensatz in der Datenbank angelegt und enthält einen Autowert. Da aber zum abrufen der Daten ein SELECT ausgeführt werden muss, ist der Autowert erst nach dem erneuten laden sichtbar.
... weiter nächster Beitrag