Programm-Einstellungen

Hallo

Habe folgendes Problem:
Ich progge ein Programm, in dem man die Einstellungen für selbiges in einem extra dafür angelegtes Form einstellen kann. Diese werden dann per XML (XmlTextWriter) gespeichert.

Nun muss ich aber bei Programmstart auf die Einstellungen zugreifen können und zwar aus beiden Forms (also Hauptform und Einstellungen-Form). Naja jetzt könnt ichs zwar so machen, dass er in jedem Form die ganze XML einliest, aber ich glaube das iss nich Sinn der Sache.

Eine Lösung hätt ich vielleicht sogar, und zwar wenn ich die Daten in einer DataTable speichere, dann nach XML exportiere, diese beim Start wieder auslese in eine DataTable rein und dann muss ich halt dafür sorgen, dass man einen globalen Zugriff auf sie hat.

Was meint ihr dazu?

Und kennt jemand zufällig n gutes XML-Tutie? Die MSDN bringt mich da nicht wirklich weiter 🙁

Kommt eben darauf an, ob das Programm nach Änderung von Einstellungen neu gestartet werden soll, oder ob das on the fly funktionieren soll.

Wenn zweiteres: bau dir doch eine Methode, die dir das gewünschte ausliest und die du in eine statische Klasse wirfst:

public static string getParameter(string Parameter) {
  XmlDocument doc = new XmlDocument();
  doc.Load("myoptions.xml");
  XmlNode parameter = doc.SelectSingleNode("root/parameter");
  return parameter.InnerText;
}

Oder Du fügst Deinem Projekt eine Anwendungskonfigurationsfile hinzu. Da musst dich dann gar nicht mehr so wirklich drum kümmern.

Zu dem Thema guckst Du hier

Am besten wär schon "on the fly". Die meisten Einstellungen haben sowieso keinen direkten Einfluss auf das Programm selber (also Pfade und sowas).

Wegen der statischen Klasse:
Ich hab da selber noch keine Erfahrungen mit statischen Klassen, darum weiss ich auch nicht wie die funktionieren (und wie sie aufgebaut sind). Werd mir das ganze mal durch den Kopf gehen lassen, klingt mir aber nach ner ganz vernünftigen Lösung. Aber muss mir eh vorher mal die statischen Klassen anschaun.

Thx 👍

Statische Klassen können nicht mehrfach instanziiert werden. D.h. die gibts nur einmal.
In diesem Fall würdest ja auch nicht unbedingt ein Objekt davon benötigen, sondern du benötigst lediglich die Methode (Funktion).

Angenommen die Klasse heißt "Helper", dann machst du kein

Helper helper = new Helper();

sondern ein

Helper.MeineFunktion();

Und die arbeitet dann für dich.

Das war jetzt eine sehr einfach Erklärung. Ich kanns auch so, wie es in der OOP definiert ist, wird dir aber nicht weiterhelfen, wennst dich damit wenig auskennst, aber wenns gewünscht ist ... 🙂

Also wenn du dir viel Arbeit sparen willst, dann verwende Serialisierung zur Speicherung deiner Einstellungwn. Du machst dann einfach nur eine Art Property-Klasse, in der die Einstellungen in einer Instanz abgelegt werden und die über eine statische Property einer anderen Klasse zugänglich ist. Dann kannst dus mit wenigen Zeilen Code in einer Datei sichern und umgekehrt wieder laden.

Danke jetzt hab ichs kapiert. Also iss ne statische Klasse in etwa sowas wie in VB ein Modul...!? Auf jeden Fall vielen Dank für deine Hilfe!!

@NoOneKnows:
Hast du dafür auch ein Beispiel irgendwo, damit man sich das ansehen kann? Wär super 🙂

Wieso serialisieren? Dann kannst die Einstellungen nur von der Anwendung selber ändern, was nicht immer Sinn macht.

@nitronic:
Wenn die zu serialisierende Klasse in eine Art Typ-Bibliothek gesteckt wird kann sie auch von anderen .NET-Anwendungen verwendet werden.

@Krambo:
Hier ein kurzes Beispiel:

using System;
using System.IO;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Serialization.Formatters.Binary;

namespace TestSerialisierung
{
	[Serializable]
	public class Properties
	{
		private int			mMember1		= 0;
		private string		mMember2		= null;

		public Properties(int m1, string m2)
		{
			mMember1 = m1;
			mMember2 = m2;			
		}

		public int Member1
		{
			get { return mMember1; }
			set { mMember1 = value; }
		}


		public string Member2
		{
			get { return mMember2; }
			set { mMember2 = value; }
		}
	}

	class Program
	{
		public static void Main(string[] args)
		{
			BinaryFormatter formatter = new BinaryFormatter();
			// oder		
			//SoapFormatter formatter = new SoapFormatter(); // benötigt zusätzlichen Verweis auf System.Runtime.Serialization.Formatters.Soap.dll
			formatter.AssemblyFormat = FormatterAssemblyStyle.Simple; // Keine Versionierung, erspart benutzerdefinierte Serialisierung

			Properties myProperties = new Properties(123, "test");

			using (FileStream file = new FileStream(@"c:\myProperties.dat", FileMode.Create))
			{
				formatter.Serialize(file, myProperties);
				file.Flush();
			}

			myProperties = null;

			using (FileStream file = new FileStream(@"c:\myProperties.dat", FileMode.Open))
			{
				myProperties = (Properties) formatter.Deserialize(file);
			}
		
			Console.WriteLine(myProperties.Member1);
			Console.WriteLine(myProperties.Member2);
			Console.ReadLine();
		}
	}
}

schau doch, ob du deine einstellungen nicht den konventionen der *.config-dateien unterwerfen kannst...
dann brauchst du dich ums auslesen überhaupt nicht mehr zu kümmern und kannst stattdessen an jeder beliebigen stelle der anwendung die einstellungen über "ConfigurationSettings" auslesen.

grtz
chief

@NoOneKnows:
Das Beispiel von dir gefällt mir sogar noch besser. Da werden die Daten ja binär gespeichert, was ich schlussendlich auch mal wollte (nur bin ich dann auf XML gestoßen).

Was ich aber da dran nich so gut finde: wenn ich viele Properties habe, dann wird der Aufruf ja elends lang 🤔

Aber sonst sicher ne gute Möglichkeit muss ich gleich ma testn 🙂

@Chief:
Nee ich möchte unabhängig von der config sein. Am besten binär speichern...

edit:
Hab das Teil mal getestet gefällt mir recht gut. Aber ich glaub ich mach mir da in die Klasse gleich ne ganze Methode, die schreibt und eine, mit der ich nen Member bekomme (ohne dass ich das im Programmcode nochmal schreiben muss 😁

@NoOneKnows:
Ja, das weiß ich wohl. Es kommt drauf an was man machen will. Ich steh eher auf Offenes. Daher gefällt es mir nicht dass die Daten binär abgelegt werden. In manchen Fällen ist es die bessere Variante, wenn schnell per Notepad (whatever) darauf zugegriffen werden kann.

Das war der Punkt den ich meinte.

@nitronic:
Wenn man den SoapFormatter für die Serialisierung verwendet kann man trotzdem mit einem beliebigen Texteditor Änderungen vornehmen. Soap orientiert sich an XML und demnach ist der Aufbau relativ leicht verständlich. Aber trotzdem ist Vorsicht geboten, da man sich die Daten auch zerschießen kann, wenn man nicht weiß was man tut 🙂

Sorry dass ich eure Diskussion unterbreche habe aber noch ne Frage und zwar:

Gibts da irgend nen Formatter, bei dem man den Text in der Datei nicht mehr lesen kann? D.h. dass die Sachen so ne Art verschlüsselt gespeichert werden oder muss man das selber machen?

Guckst du hier 😉
Im grundegenommen mußt du einfach nur einen CryptoStream zwischenschalten. Aufwand ebenfalls gegen Null:

using System;
using System.IO;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Serialization.Formatters.Binary;
using System.Security.Cryptography;

namespace TestSerialisierung
{
	[Serializable]
	public class Properties
	{
		private int mMember1 = 0;
		private string mMember2 = null;

		public Properties(int m1, string m2)
		{
			mMember1 = m1;
			mMember2 = m2;
		}

		public int Member1
		{
			get { return mMember1; }
			set { mMember1 = value; }
		}


		public string Member2
		{
			get { return mMember2; }
			set { mMember2 = value; }
		}
	}

	class Program
	{
		public static void Main(string[] args)
		{
			TripleDESCryptoServiceProvider trippleDesProvider = new TripleDESCryptoServiceProvider();

			trippleDesProvider.GenerateIV();
			trippleDesProvider.GenerateKey();

			ICryptoTransform encryptor = trippleDesProvider.CreateEncryptor();
			ICryptoTransform decryptor = trippleDesProvider.CreateDecryptor();

			BinaryFormatter formatter = new BinaryFormatter();
			// oder        
			//SoapFormatter formatter = new SoapFormatter(); // benötigt zusätzlichen Verweis auf System.Runtime.Serialization.Formatters.Soap.dll
			formatter.AssemblyFormat = FormatterAssemblyStyle.Simple; // Keine Versionierung, erspart benutzerdefinierte Serialisierung

			Properties myProperties = new Properties(123, "test");

			using (FileStream file = new FileStream(@"c:\myProperties.dat", FileMode.Create))
			{
				CryptoStream cryptoStream = new CryptoStream(file, encryptor, CryptoStreamMode.Write);
				formatter.Serialize(cryptoStream, myProperties);
				cryptoStream.Close(); // ganz wichtig!
			}

			myProperties = null;

			using (FileStream file = new FileStream(@"c:\myProperties.dat", FileMode.Open))
			{
				CryptoStream cryptoStream = new CryptoStream(file, decryptor, CryptoStreamMode.Read);
				myProperties = (Properties) formatter.Deserialize(cryptoStream);
			}

			Console.WriteLine(myProperties.Member1);
			Console.WriteLine(myProperties.Member2);
			Console.ReadLine();
		}
	}
}

sehe ich da was falsch oder müsste man nicht den key der des-verschlüsselung irgendwo speichern oder dem user mitteilen ? sonst kann man doch beim nächsten mal das ding nicht mehr laden, oder ?

@Fabse:

Stimmt sonst isses ne asymetrische Verschlüsselung und das bringt mir da ja nix. Also Key (sind glaub ich 2) muss gespeichert werden, aber das ist ja kein Problem...

Hi!

Also ich benutze zum Speichern von Daten meine Bibliothek für Ini-Dateien. Ich verwende es genau wie du. In der einen Form werden Einstellungen vorgenommen, in der anderen wird auf diese Einstellungen zugegriffen.

Ich habe es so gemacht das ich eine Klasse habe in der die Einstellungen gespeichert sind. Diese werden von der Hauptform geladen. Nach dem laden über meine Bibliothek werden diese in ein Objekt meiner Klasse für die Einstellungen geschrieben. Wenn die Form mit den Einstellungen geladen wird, dann übergebe ich das Objekt einfach. Da ich mC++ verwende habe ich den Vorteil das ich ohnehin Zeiger verwende und dadurch, direkt das Objekt verändern kann, wenn der Benutzer die Einstellungen speichert. Sprich ich muss die Einstellungen nicht an den Aufrufer zurückgeben, sondern kann einfach weiter arbeiten.

Somit brauche ich kein globales Objekt für die Einstellungen und kann diese jederzeit verändern, indem ich einfach den Zeiger auf das lokale Objekt übergebe.

Code-Hacker

du arbeitest zwar mit pointern, aber in c# wird sowieso sogut wie alles als referenz auf das objekt übergeben. dein ansatz wäre unter c# der gleiche!

man müsste nur weniger schreiben, weil man ne menge von den "*" sparen würde 8)

Hi!

Hmmm....stimmt. Aber wen es stört, der kann es ja auch zurückgeben, was zumindest dann wichtig ist, wenn man die Daten vor der Änderung im Hauptprogramm selbst nochmal irgendwie mit den Daten nach der Änderung abgleichen muss, was aber denke ich ziemlich selten der Fall sein wird.
Was die '*' betrifft, die muss man ja nie schreiben, außer bei der Deklaration (es sei dann man programmiert Pascal-Style). Wirklich scheiße ist eigentlich an C++/CLI das man die ganze Zeit den Pfeiloperator verwenden muss, was eigentlich alles so hässlich macht. Gott sei Dank wird die Syntax für C++/CLI 2.0 schöner.

Code-Hacker

Hi, ich habe ein ähnliches Problem auch mit Serialisierung gelöst. Hierbei geht es
darum das ein Formular seine Position, Größe und Anzeigemodus aus einer Datei
liest bzw. darin schreibt. So findet der User seine Form genau so wieder wie er sie
verlassen hat. Es hat mir so einen Spaß gemacht das ich daraus eine Komponente
gebastelt habe die automatisch ein Form kontrolliert.

Hier der Code für die Parameter-Klasse:

using System;
using System.Windows.Forms;

namespace Sero.Forms
{
	/// <summary>
	/// Zusammenfassung für XmlFormData.
	/// </summary>
	public class XmlFormData
	{
		public int Top;
		public int Left;
		public int Width;
		public int Height;
		public FormWindowState WindowState;

		public XmlFormData()
		{
			this.Top = 0;
			this.Left = 0;
			this.Width = 0;
			this.Height = 0;
			this.WindowState = FormWindowState.Normal;
		}

		public XmlFormData(System.Windows.Forms.Form form)
		{
			this.Top = form.Top;
			this.Left = form.Left;
			this.Width = form.Width;
			this.Height = form.Height;
			this.WindowState = form.WindowState;
		}

		public void SetFormProperties(System.Windows.Forms.Form form)
		{
			form.Top = this.Top;
			form.Left = this.Left;
			form.Width = this.Width;
			form.Height = this.Height;
			form.WindowState = this.WindowState;
		}
	}
}

Hier der Code der Komponente:

using System;
using System.IO;
using System.Xml.Serialization;
using System.Windows.Forms;

namespace Sero.Forms
{
	/// <summary>
	/// Zusammenfassung für XmlFormController.
	/// </summary>
	public class XmlFormController : System.ComponentModel.Component
	{
		protected DirectoryInfo Directory;

		private bool enabled = true;
		public bool Enabled
		{
			get
			{
				return this.enabled;
			}
			set
			{
				this.enabled = value;
			}
		}

		private System.Windows.Forms.Form form;

		public System.Windows.Forms.Form Form
		{
			get
			{
				return this.form;
			}
		}

		public XmlFormController(System.Windows.Forms.Form form)
		{
			this.Directory = new DirectoryInfo(Application.StartupPath + @"\XmlSettings");
			if(!this.Directory.Exists)
			{
				this.Directory.Create();
			}
			this.form = form;
			this.form.Load += new EventHandler(form_Load);
			this.form.Closed += new EventHandler(form_Closed);
		}

		public void LoadFromFile(string fileName)
		{
			XmlSerializer serializer = new XmlSerializer(typeof(XmlFormData));
			try
			{
				TextReader reader = new StreamReader(fileName);
				XmlFormData formData = (XmlFormData)serializer.Deserialize(reader);
				reader.Close();
				formData.SetFormProperties(this.Form);
			}
			catch
			{
				this.SaveToFile(fileName);
			}
		}

		public void SaveToFile(string fileName)
		{
			XmlFormData formData = new XmlFormData(this.Form);
			XmlSerializer serializer = new XmlSerializer(typeof(XmlFormData));
			TextWriter writer = new StreamWriter(fileName);
			serializer.Serialize(writer, formData);
			writer.Close();
		}

		public string GetFileName()
		{
			return this.Directory.ToString() + @"\" + this.Form.GetType().ToString() + ".xml";
		}

		private void form_Load(object sender, EventArgs e)
		{
			if(this.enabled)
			{
				this.LoadFromFile(this.GetFileName());
			}
		}

		private void form_Closed(object sender, EventArgs e)
		{
			if(this.enabled)
			{
				this.SaveToFile(this.GetFileName());
			}
		}
	}
}

Das ist im Prinzip das gleiche was du machen willst, nur mit dem Unterschied das
du die Parameter manuell in einem Dialog setzen musst.

Vielleicht gefällt ja jemandem die Idee! 🙂

Viele Grüße

Roland

@Fabse:
Dies war nur ein Beispiel 🙂 Natürlich muß man den 64-Bit Initialisierungsvektor und den 192-Bit Schlüssel im Programm hinterlegen...

@KRambo:
Ne, Tripple DES is ja keine asymetrische Verschlüsslung. Das würde in diesem Fall eh kein Sinn machen, da es so oder so möglich wäre die Daten wieder lesbar zu machen.

Was mir noch net so ganz klar ist, ist das mit dem Initialisierungsvektor. Tripple DES ist bekannterweise eine 192-Bit Verschlüsslung. Trotzdem lassen sich die Daten auch nur mit dem richtigen Initialisierungvektor entschlüsseln. Wäre es dann nicht eigentlich eine 256-Bit Verschlüsslung? Kenne mich mit der Thematik nicht so aus...

@NoOne:

Ich weiss dass 3DES keine asymetrische Verschlüsselung ist, wenn man jedoch den Schlüssel nicht speichert, ist es so ne Art asymetrische Verschlüsselung, da man dann nicht mehr (oder sehr schwer) wieder entschlüsseln kann.

Hier ein wenig mehr zum Thema: http://www.computerlexikon.com/begriff.php?id=986

Hm jetzt hab ich noch ein Problem wegen der Verschlüsselung:

Wie bekomm ich da gültige Keys? Mit den Generate-Methoden kann ichs nicht machen, da die ja einen generieren, der jedoch net gespeichert werden kann, da die Funktion ja nix zurückgibt. Und wenn ich der Key bzw. IV-Eigenschaft einen Schlüssel (per

ASCIIEncoding.ASCII.GetBytes("1234567")

) mitgebe, dann sacht er:

Ungültige Schlüssellänge
(aber erst bei Ausführung)

Lieg ich da falsch, dass die Keys 56 Bit sein sollten? Das wären ja 7 Zeichen wo iss also sein Problem?

Edit:
Hab die Lösung bereits:
Der Key MUSS zwischen 16 und 24 Zeichen enthalten, sonst gehts nicht. Also zwischen 128 und 192 Bit 8o

Hmm

Sorry für die Doppelpostings ich versuch nur den Thread etwas hochzuschieben, damit man weiss dass ich noch ne Frage habe 🙂

Und zwar:
Das Beispiel von NoOneNows funktioniert zwar, jedoch nur wenn ich speichern und laden der Datei im selben Programm mache.

Habe jetzt nämlich das Problem, habe ein Programm, das soll die Datei schreiben und das andere Programm soll die Datei wieder lesen. Wenn er jedoch zu der Stelle kommt:

myProperties = (Properties) formatter.Deserialize(cryptoStream);

dann stellts ihn auf und er sacht:

Nicht behandelte Exception des Typs 'System.Runtime.Serialization.SerializationException' ist aufgetreten.

Zusätzliche Beschreibung: Die Assembly xy kann nicht gefunden werden.

Statt xy steht natürlich was anderes drin, nämlich die Assembly vom Programm, dass die Datei schreibt. Was mir nicht ganz verständlich ist: Warum will er denn die Assembly haben?

Habe bei beiden Programmen diesselbe Klasse für die Einstellungen genommen (einfach kopiert und dann hinzugefügt) und auch die Aufrufe dürften stimmen. Hat beim andern Proggie (wo lesen / schreiben in einem drin ist) tadellos funktioniert.

Weiß zufällig jemand warum? 🙁

Original von KRambo
Habe bei beiden Programmen diesselbe Klasse für die Einstellungen genommen (einfach kopiert und dann hinzugefügt)

ein unding!gleichen code an mehreren stellen ist ganz dolle böse! lager das in eine dll aus. außerdem löst das vielleicht sowieso dein problem, ansonsten kann ich dir da nich wirklich helfen.

vielleicht will er ja mit derselben klasse wieder gelesen werden, du bietest ihm aber nur die gleiche klasse an, was ihm vielleicht nicht reicht. (blinde vermutung)

aber zip dateien zb lassen sich ja auch mit jedem proggi wieder entpacken...seltsam

Naja klar dass mehrfacher Code nur bedingt empfehlenswert ist, jedoch schreibe ich erst mal das Programm fertig (soll auch funktionsfähig sein) und lager erst dann die Sachen aus, wenn ich sicher weiss, dass alles funktioniert.

Um das gehts aber auch gar nicht. Ich werde auf jeden Fall mal ne Testanwendung machen, wo ich das ganze dann mal teste (mit dll), vielleicht klappts ja dann wenn ich ihnen nur eine Klasse gebe!

Edit:
Jup mit DLL funzt es. Hab da zwar noch n paar kleine Probleme damit, aber funktionieren tuts grundsätzlich schonmal 🙂

Thx

Original von KRambo
Naja klar dass mehrfacher Code nur bedingt empfehlenswert ist, jedoch schreibe ich erst mal das Programm fertig (soll auch funktionsfähig sein) und lager erst dann die Sachen aus, wenn ich sicher weiss, dass alles funktioniert.

Keine gute Taktik 😉

Ansonsten hat Fabse recht, du mußt wirklich die selbe Klasse aus der selben Assembly referenzieren. Er speichert immer den zugehörigen Assemblynamen bei der Seriailisierung.

Hab ich ja auch jetzt 🙂

Nur hab ich momentan noch ein Problem: Wie kann ich ausserhalb der DLL nun auf die Eigenschaften zugreifen? Das kennt er ja nun nur intern in der DLL, wenn ich die Funktion da reingepackt habe!?

du fügst eine referenz auf dein projekt(deine dll) hinzu und, falls die namespaces anders sind, dann musste die auch mit using einfügen oder wahlweise immer hinschreiben.

du hast da sicherlich keine funktion drin, sondern ein oder mehrere klassen mit methoden! auf public methoden und variablen und eigenschaften hast du von außen zugriff, auf andere nicht. solltest du eigentlich kennen. wo ist dein problem?

wenn du erstmal die referenz eingefügt hast, ist es quasi egal, ob die eine *.cs datei der klasse zur dll oder zum exe-projekt hört. zumindest in dem eingeschränkten kontext, dass sie von keiner anderen anwendung genutzt werden soll/kann).

Hm hab ich wahrscheinlich falsch verstanden.

Hab jetzt die Klasse mit den Properties in die DLL ausgelagert und versucht auch die Funktionen zum De/Encoden reinzupacken. Funzt wie gesagt zwar grundsätzlich, aber ich bekomm da keinen Zugriff auf die Properties.

D.h. ihr habt gemeint, nur die eine Klasse auslagern, die er zum Serialisieren braucht, damit er auf dieselbe zugreift, oder? Werds demnächst dann so probieren...

Kleines Missverständnis 8o

Noch was: Referenzierungen sind mir wohl bekannt, auch auf welche Member in Klassen ich zugreifen kann (public). Trotzdem danke für die Erklärung 🙂

Was mir aber noch aufgefallen ist: Wenn ich nen OpenFileDialog über die DLL aufrufe, dann ist der Aufruf ein Stück langsamer als wenn er in der EXE ist.

Hm habs mal so probiert wie ich oben geschrieben hatte, also nur die Klasse zum Serialisieren ausgelagert in ne DLL. Bringt mir aber immer noch den obigen Fehler (Assembly xy nicht gefunden)....

Hmmm dann muss ich wohl oder übel die Methoden zum De/Encrypten auch auslagern, wie ichs zuerst gemacht habe denn dann gehts. Nur iss dann auch das Problem, dass ich zwar innerhalb der DLL auf die Properties zugreifen kann, aber nicht im Programm selber 🙁

Und das nächste Problem: Da es keine statischen Klassen in C# 1.0 gibt, macht es das ganze noch schwieriger...