Hallo loks.
Richtig. Ich habe meinen Fehler gefunden.
Das war das was ich bisher gemacht habe.
var persons = _dbContext.Persons;
persons.Add(new Person("Peter"));
var x = persons.FirstOrDefault(); // hier erhalte ich nun den Peter zurück.
Dann hatte ich umgestellt. Und nicht mehr getestet.
Vielen Dank.
Erstmal den String nach den "Markern" durchsuchen, und ne Liste der Marker basteln.
Dann den 1. "Code" inkrementieren. Wenn's nen Overflow gibt den nächsten Code inkrementieren. Wenns da wieder nen Overflow gibt wieder den nächsten Code usw. Und wenns keinen nächsten Code mehr gibt ist man fertig.
Eigentlich recht einfach. Und das ohne dass man die Anzahl der Marker irgendwie festlegen müsste.
Die Softwareersteller sind einfach nur böse, wenn sie ihre Programme auch verkaufen wollen und für unlizensierte
Testanwender sich etwas einfallen lassen.
Zum Thema: Es geht - wie mehrfach geschildert - auch für .NET mit ausreichendem Schutz gegen unerwünschte Manipulation.
Die Wartbarkeit des Programmes muss darunter nicht leiden. Die Prüfung eines Lizenzschlüssels ist einfach zu handhaben und sollte
mit einem Disassembler nicht sofort erkennbar sein. Alle Lösungswege dafür machen jedoch etwas zusätzliche Mühe.
Achso. Und natürlich an alle dies interessiert noch einmal die vollständige Methode (bzw. Klasse) zum Auslesen:
// Verweis zu System.Core.dll
using System.Linq;
public static class Resources
{
public static byte[] GetResource(string tag)
{
System.Resources.ResourceReader rr = new System.Resources.ResourceReader(System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream(System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceNames()[0]));
string str;
byte[] file;
rr.GetResourceData(tag, out str, out file);
System.Collections.Generic.List<byte> fileList = file.ToList<byte>();
fileList.RemoveRange(0, 4);
file = fileList.ToArray();
return file;
}
}
Tag ist dabei der Name der Resource. Wenn man die Datei also mit
ResourceWriter rw = new ResourceWriter("files.resources");
rw.AddResource("yodo", File.ReadAllBytes("file-in.txt"));
hinzufügt muss man bei tag "yodo" angeben.
Hinweis: Das ganze ist lediglich für die Nutzung mit einer Resources-Datei ausgelegt, aber einfach für mehrere Dateien erweiterbar.
Bennisen schrieb:
Ich dachte das ich das mit der Vererbung mal ausprobiere, da ich noch nicht lange programmiere :).
Zum einen können das später recht viele Werte sein die initialisiert werden müssen. So hätte ich das voneinander getrennt um einen Überblick zu haben. Hatte auch vorher alles in einer Klasse nur fand ich es irgendwann unübersichtlich.
Das widerspricht aber der Idee der Vererbung. Wie µ schon sagte reicht es da eine Schiffsklasse zu basteln und die nur mit richtigen Werten zu fuellen.
Wenn du Vererbung ueben willst, dann mach das lieber an einem konkreten und sinnvolleren Beispiel. Die Gefahr die jetzt naemlich besteht ist, dass du die Verwendung komplett falsch uebst und verinnerlichst und spaeter immer wieder falsch anwendest.
Ja, ziemlicher Unfug. Wenn Du das in echten Programmen machst wirst Du unheimlich viel Müll im Speicher produzieren.
List<Test> Werte_berechnen(int Wert)
{
List<Test> lTemp = new List<Test>();
if(Wert <= 0)
return new List<Test>(); // Warum hier new List() ? Man könnte ebenso infach lTemp zurückgeben.
//Irgendwas
//lTemp wird mit Werten gefüllt
return lTemp;
}
public main()
{
int iWert;
List<Test> lWerte= new List<Test>(); // Das ist Unfug. Hier wird eine unnötige neue Liste angelegt die gleich in der nächsten Zeile ersetzt wird
lWerte = new List<Test>(Werte_berechnen(iWert)); // Auch das ist Unfug. Du bekommst eine Liste zurück und erzeugst eine neue Liste in die der Inhalt der alten Liste kopiert wird
}
Aufgeräumt sähe das so aus:
List<Test> Werte_berechnen(int wert)
{
List<Test> temp = new List<Test>();
if(wert <= 0) return temp;
//Irgendwas
//temp wird mit Werten gefüllt
return temp;
}
public main()
{
int intWert;
List<Test> werte = Werte_berechnen(intWert);
}
Und versuch am besten Dir diese komische Naming Konvention gar nicht erst anzugewöhnen...
ja, sry -.-
Habs jetzt so ähnlich gemacht, nur dass Proc die gemeinsamen Daten weiterleitet, so dass foo nur Proc als Parameter übergeben bekommt, anstatt beide.
Willst du nicht eher
private void txtbox_TextChanged(object sender, EventArgs e)
{
OnTextboxTextChanged(EventArgs.Empty);
}
?!!
P.S. Deine HandleTextboxTextChanged-Methode ist nur dann sinnvoll, wenn du die Parameter wegläßt:
private void HandleTextboxTextChanged()
{
OnTextboxTextChanged(EventArgs.Empty);
}
So kannst du dann in der oberen Methode dann auch einfach diese aufrufen!
PPS: Wenn du noch mehr Details dazu wissen willst, dann kannst du dir mal meinen Artikel Kommunikation von 2 Forms anschauen, der u.a. auch Ereignisse behandelt.
Ich habe ein Objekt vom Typ System.ServiceModel.Channels.Message, das eine XML enthält. Mit Envelope-, Header-, Body-Knoten etc.
Wen ich dieses Objekt an einen WCF-Service verschicke, dann werden im Header zwei Knoten hinzugefügt: <Security> und <To>.
Gibt es jetzt auf WCF-Seite einen Weg, diese Message wieder so umzuwandeln, dass sie inhaltlich identisch ist mit der ursprünglich eingegebenen XML?
Irgendeine Funktion RemoveMetadata oder so, die bewirkt, dass die XML, die mir in Message.ToString() ausgegeben wird, wieder exakt denselben Inhalt hat (Formatierung mal ausgenommen) wie die XML, die ich auf Clientseite per XmlReader in das Objekt geschoben habe?
Oder muss ich die XML rausextrahieren, wiederum in einen XmlReader laden und diese Knoten dann manuell entfernen? Das fände ich nicht so optimal, denn wer weiß, welche Knoten unter welchen Umständen beim Versand der Daten noch da reinkommen würden, an die ich jetzt gar nicht denke.
werkla4 schrieb:
Jemand eine Idee wie ich das Problem lösen kann?
Hi werkla4,
wenn Du ein kompilierbares Minimalbeispiel in Form eines VS-Projekts zur Verfügung stellst, würde ich es mir übers Wochenende mal anschauen.
Grüße
