Wie meinst du das mit dem getrennt kompilieren?
Eine eigene DLL wo nur die Ressource enthalten ist?

Satelliten-DLLs bekomme ich wohl mit meinem C# Express nicht hin 😦

Du meinst sicher diese Thematik: Exemplarische Vorgehensweise: Erstellen von verwalteten Satelliten-DLLs

Die Idee ist gut - allerdings zerhakt er mir dann im Resources.designer.cs den Namespace auf das Projekt in dem ich es als link eingefügt habe - d.h. im ursprünglichen Projekt funktioniert es nicht mehr 😦

Ahoi, ich habe in einer Projektmappe mehrere Projekte. In einem der Projekte habe ich eine Resources.resx, in der Bilder gespeichert sind für Buttons.

Wie ich aus den anderen Projekten per Code auf die Inhalte der Resources.resx zugreife ist klar und funktioniert auch soweit. Meine Frage bezieht sich auf die Einbindung im GUI von VS c# express.

Wenn ich im Projekt der Resource-datei per GUI einem Button ein Bild zuweisen möchte habe ich die Bilder in einer Liste und kann sie vorab sehen (Vorschau).

Wenn ich das aus einem Anderen Projekt dieser Mappe heraus mache, klappt das nicht.

Geht das überhaupt und wenn ja, wie?

Es ist halt eine "Komfort-Funktion", das Bild "aussuchen" zu können und nicht elementar wichtig...

ich habs wieder gefunden...:

OleDbConnection con = new OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\Resources\dbKosten_design.accdb;Persist Security Info=True");
DataContext db = new DataContext(con);
Table<tblBuchung> Buchung = db.GetTable<tblBuchung>();

d.h. du übergibst dem dataContext die OLE-DB-Connection, dann geht das Füllen der Objekte.
Wie gesagt - insert, update und delete leider nicht!

Die Daten einlesen (per select) funktioniert...
indem du einfach eine oledbconnection aufbaust und diese dann an das EF übergibst als Verbindung...
Ich weiß nicht mehr genau, wie ich das gemacht hatte - auf jedenfall lief das im Endeffekt nicht über OLEDB sondern über die SQLCE Schnittstelle, die ja von EF unterstützt wird.

Allerdings ist die Syntax nicht ganz gleich, sodass insert, update und delete nicht funktionierten, weil angeblich ein ";" im sql statement gefehlt hat.... aber die Funktionen sind ja alle geschachtelt in der DLL: EntityFramework ...
Wenn man Die DLL per Disassambler irgendwie auflösen und bearbeitbar machen kann, könnte man unter Umständen das Ding so umbauen, dass es Funktioniert...

Mir persönlich war das zu aufwändig und ich habe alles per Hand gebaut...
also EF beiseite gelegt und Echte Pocos gebaut per OLEDB.
Also auch ohne dataset und den kram.

Wer austeilen kann, muss das aber auch in beide Richtungen tun... und somit möchte ich dir hiermit für deine jetzt einleuchtenderen Worte danken und ein Lob austeilen 😃 .
Wieder ein bissl mehr Licht im Dunkel.

Ich bin gerade am Überlegen, ob ich gemäß meiner Vergangenheit (PHP+MySQL Entwickler) die Beziehungen der Tabellen einfach mal nicht vom EF erfassen lasse und mich lieber selber in der Business-Schicht darum kümmere...
Also das EF als reinen Class-Filler bzw. Updater/Extender/Terminator im DAL missbrauche...

Offenbar ist mein Gefühl "zu viel Steuerung aus der Hand zu geben" tatsächlich richtig.
Es läuft einfach alles nicht so, wie ich mir das denke.
Das EF denkt mir zu viel! Das soll doch aber DUMM sein 😛

1. ich benutze EF 4.1
2. ich pfusche nicht am Schema rum sondern habe das Modell nach meiner DB erstellen lassen...
   Wenn es das Modell ist, was du mit Schema meintest...

Und ja, es ist leider schwer zu lesen, wenn man nicht schon einige Jahre Erfahrung hat auf dem Gebiet und ein "uberUsorXXX" ist... !!!1111einself

Und die Fehlermeldung sagt eindeutig, dass SQL Compact eben KEIN automatisches generieren von Werten kann !!! Oder ist die Fehlermeldung anders zu interpretieren?
Das klingt für mich verdammt danach, dass er den Wert nicht automatisch eins hoch setzen kann.

Und wenn du irgendwie sauer sein solltest - oder genervt von meiner Dummheit/Unwissenheit oder sonstigen dir missfallenen Sachen, lass das mit dem Antworten lieber. Oder sei zumindest so konstruktiv, eine Lösung anzubieten...

Und wie bekommt man das nun gebacken?
Ich scheitere ja schon an einem einfachen Insert...

Entities db = new Entities();
category newCat = new category();
newCat.categoryID = db.category.Max(x => x.categoryID) + 1;
newCat.categoryName = textBox1.Text;
newCat.categoryParentID = null;
newCat.categoryDesc = "bla";

db.category.Add(newCat);
db.SaveChanges();
textBox1.Text = "";

Dass SQL CE kein Autoincrement kann, ist ja schonmal lächerlich ....... aber warum ich diese Exception dann auch noch bekomme, wenn ich den Wert bereits vorgebe?!?
Und sogar wenn ich im Model StoredGeneratedPattern von Identify auf None setze 😦

Es geht hier um EF 4.1 in Kombination mit einer SQL Compact File.
Und zwar ist im Netz weitläufig bekannt, dass es wohl Probleme gibt beim Aufruf von .SaveChanges(), wenn Tabellen betroffen sind, die mehrere Abhängigkeiten untereinander haben...
Ein Workaround hier ist das getrennte speichern der beiden betroffenen Tabellen...

Genauergesagt tritt beim Ausführen folgende Exception auf: Google-Suche nach "Unable to determine a valid ordering for dependent operations."

Zu deutsch:> Fehlermeldung:

Es kann keine gültige Anordnung für abhängige Vorgänge ermittelt werden. Abhängigkeiten sind aufgrund von Fremdschlüsseleinschränkungen, Modellanforderungen oder vom Speicher generierten Werten möglich.

Leider funktioniert in meinem Fall der Workaround nicht, da ich nur 1 Tabelle habe, die auf sich selbst referenzieren kann.

categoryID
categoryName
categoryDesc
categoryParentID

categoryParentID ist entweder 0 (dann ist es die oberste Ebene des Baumes) oder entspricht der categoryID eines Objektes, dessen es dann untergeordnet ist.

Im Internet habe ich einige Mitleidende Personen gefunden - aber leider keine Lösung 😦
Habt ihr einen Ansatz?

**
UPDATE**
Wenn ParentID Nullable ist und beim Anlegen eines neuen Datensatzes die Parent ID auf "null" gesetzt wird statt 0, scheint es zu laufen.

Aufgrund von sooo vielen unproduktiven Stunden habe ich nun entschieden, mein Projekt vorerst OHNE O/R-Mapper zu machen - sondern mit echten Abfragen auf DAL Ebene.

Ich mache jetzt einen Schritt nach dem Anderen.
Das ganze Thema wird mir nämlich gerade zu komplex.

Wen der genaue Grund interessiert:
Ich war nun mehrere Stunden beschäftigt herauszufinden, warum ich im EF4.1 einfach gewisse Methoden nicht habe (z.B. .Find() und .Load())... Ich gebs jetzt vorerst auf!
Und NEIN, ich habe die Lösung noch immer nicht.

Hier noch ein Link auf wiki für eine kleine Übersicht an eingebetteten Datenbanken, die direkt mit der Software verteilt werden könnten:
Eingebettetes Datenbanksystem

Ich werde es nun erstmal mit SQL CE probieren, da es zum Entity Framework kompatibel ist.
Zuerst werde ich heute testen, ohne SQLMetal die dbml-File zu generieren (auf eine SQL Server 2008R2 express file).
Dann werde ich den Quell-String in der app.config ändern und die DB exportieren als sdf (SQL CE-File).
Da ich gestern sowieso die DBML-File schon per "normaler" SQL-Server express file erstellt habe, ist das für mich der einfachere und offentlich schnellere Weg.

Ah ok, es war mir nicht bewusst, dass SQL Compact eine Stand-Alone Lösung ist.
Danke für den Hinweis.

Nun mal generell die Frage...
Eigentlich möchte ich die Software auch an Verwandte usw. weitergeben und deswegen in diesem Projekt weg von diesem DB Kram... Was bleibt mir da als Alternative?
Excel und XML?
Daher je eigentlich auch der ursprüngliche Plan mit der accdb file: einfach das access framework druff und fertig...

Ist schon sehr ärgerlich, da ich aktuell einfach einen Kompromiss finden muss zwischen EINFACH und UNGEBUNDEN...

Klar ist das mit dem OR-Mapper wirklich eine Erleichterung... aber die Software wird somit unflexibel, was die Verteilung angeht...

Ich habe jetzt mal bissl rumgespielt...
Es ist wirklich genau das was ich gesucht habe!
Genauer: ich benutze dbcontext quasi nur als verbindungsschicht zur DB-File die dann einige Operationen für mich übernimmt, die ich nun nicht von Hand programmieren muss.
Ich habe also die Flexibilität, die ich brauche. Ich werde die abfragen dennoch in Interfaces packen, um mein striktes Schichtenmodell zu bekommen.

Mal sehen, ob ich das so hinbekomme, wie ich mir das denke!
Für einen Anfänger aber sicher eine gute Übung!

Ich arbeite momentan also statt auf einer accdb datei auf einer sql server file.
Ich muss sagen, dass der DBContext-Kram aber extrem langsam auf einer SQL Server file ist.
Direkt auf dem Server arbeiten ist ja leider nicht 😦

Bei meinem Haushaltsbuch-Projekt ist es halt so, dass ich direkt bei Programmstart fast alle Daten eingelesen haben muss, weil sofort im "Dashboard" Auswertungen, die letzten Buchungen usw. zu sehen sind.

Evtl. werde ich die Wartezeit mit einem splash-screen umgehen oder sowas... mal sehen.
Erstmal Funktionalität herstellen!

Vielen Dank für deinen Link, gfoidl...
Das hat mich wirklich weitergebracht!
Aber hier hat MSDN auch wirklich mal ein tolles Beispiel 😃

Ich habe jetzt mal etwas mit Linq to SQL rumgespielt...
Zuerst habe ich die Accdb file in den sql server 2008 R2 express importiert, die Beziehungen eingetragen und dann ein Projekt gestartet und etwas experimentiert...

Was mich stört: eigentlich ist doch diese zentrale Datei der Linq to SQL Klasse ein Mischmasch aus DataAccess Layer und dem Vertikalen Model-Layer?!?
Bekommt man das jemals entkoppelt?

Ich traue es mir zumindest nicht zu.
Aber aufgeben will ich mein 3-Layer (+ 1 vertical Layer) System eigentlich nicht ...
Aber verdammt bequem ist Linq to SQL schon - im Gegensatz zu "selber bauen"!

L2S ist sicher eh viel zu overpowered für meine Belange... eigentlich will ich nur jedes objekt einzeln updaten, eintragen oder löschen und listen aus gleichen objekten auslesen...

Alles was mit Verknüpfungen und Statistiken, Berechnungen usw. zu tun hat machen andere Layer (BL bzw der vertikale Model-Layer für die Verknüpfungen)

Ich habe nur Visual Studio 2010 Express C#... das scheint eine Einschränkung zu sein, OR-Mapper zu finden.
Ich habe leider nicht das Geld für die Professional Version.

Hat jemand einen Tipp?

Zur Not werde ich wohl erstmal LINQ-2-SQL verwenden... wenn das denn accdb files unterstützt und unter Express läuft...

EDIT: im Express kann ich zwar eine LINQ-TO-SQL Klasse erstellen und ein OR-Designer macht sich auf - aber wenn ich Itema aus der eingebundenen Accdb in den designer ziehen will, kommt eine Meldung über einen nicht unterstützten Drittanbieter 😦

Wie du schon richtig geahnt hast:
Ich habe im** DataAccess-Layer** ein Interface und die entsprechende .cs datei zum holen der Daten aus der accdb-Datei nach dem Schema der Klasse aus dem vertikalen Model-Layer.
Und zwar für jede Tabelle einzeln. Also eine Interfacedatei und eine Worker-Datei je Tabelle.

Der Business-Layer sorgt für die Sortierung und Eintragung von Sondersachen...
Z.B. bei "Kategorien" habe ich den Sonderfall, dass sie multidimensional / rekursiv sind, wie auch immer man das sagen will...
Kategorie hat also ein Feld ParentID, was besagt, dass eine unendliche tiefe oder breite Baumstruktur vorhanden sein kann... durch nur diese eine Tabelle

Zuerst hatte ich die oberste Ebene belassen (ParentID = 0) und der Klasse Kategorie eine Property in Form wieder eines Dictionary<int ID, Kategorie KategoObject> gegeben, sodass die Kindobjekte sich tatsächlich in den Mutterobjekten befunden haben und eine ECHTE struktur entstanden ist - nicht mehr nur eine Verweis-Struktur.
Mittlerweile habe ich das geändert in eine Methode getChilds mit dem Rückgabetyp des Dictionary<int ID, Kategorie KategoObject>.
D.h. die Kindobjekte werden nun nur geladen, wenn sie wirklich benötigt werden.

Im Presentation-Layer / View hole ich mir anhand von Interfaceobjekten die Dictionarys z.B. über getKategorien() -> normale Liste bzw. getKategorienDimensional -> Liste mit ECHTER Struktur / also kindobjekte nicht auf gleicher Ebene wie Elternobjekte. Die implementierung der get-Funktionen ist im Business-Layer - abgerufen wirds aber per interface vom View!

Dort arbeite ich quasi mit den Dictionarys der datensätze, welche ja die Rückgaben der Getter vom BL sind.

Wobei ich das Listen-Stricken usw. auch nochmal ausgelagert habe in extra CS-Files - d.h. das mache ich nicht direkt im frmMain.cs-code!
Um einfach in anderen Fenstern auch einfach darauf zugreifen zu können usw.

Ich hoffe man kann das einigermaßen verstehen...

Allerdings habe ich soeben beschlossen, mir erstmal ein paar O/R-Mapper anzusehen und dann einen Solchen zu verwenden.
Ich hoffe, ich muss mich dafür nicht schämen.

Bei mir läuft aktuell auch der Kopf heiss... Daher hänge ich mich hier an das Thema einfach mal ran.

Ich habe viele Jahre non-OOP in PHP programmiert...
Seit einigen Wochen versuche ich mich an c#

Extrem geholfen zum Grundverständnis des "Handwerkzeugs" haben mir folgende videos: http://www.j3l7h.de/videos.html#a3
Zum Thema Application Design wollte ich mich gerne am 3-Schichten Modell orientieren mit einer Vertikalschicht für Klassendefinitionen und Klassenübergreifende Interfaces.
HowTo: 3-Tier / 3-Schichten Architektur

Aktuell gehe ich so vor:
Ich habe Klassen für die entsprechenden Datensätze und baue mir aus den Klassen mit Hilfe von Datenbankanfragen (auf eine accdb-Datei) meine Objekte.
Also ich möchte quasi zur Laufzeit tatsächlich nur mit Klassen-Instanzen arbeiten.
Allerdings scheint das ein enormer Aufwand zu sein. Gerade auch mit dem 3-Schicht System.
Die Objekte schmeiße ich dann in ein Dictionary<int, KLASSE> wobei das int gleichzeitig die KLASSE.id ist.

Ist das soweit korrekt oder habe ich hier schon den 1. Denkfehler?
Ich lese immer nur was von Listen usw... aber wie kommt man dann denn an die einzelnen Objekte ran, ohne immerzu die ganze Liste durchzugehen mit Schleifen und nach der Objekt ID zu suchen?!?

Ich komme jedenfalls gerade ins Zweifeln, ob ich einen falschen Denkansatz habe bzw. ob es "Fertiglösungen" dafür gibt (wie die hier oft beschriebenen O/R-Mapper) oder ob es einfach mal Tatsache ist, dass es so heiden viel Arbeit ist.

Ich habe auch noch keinen Ansatzpunkt, wie ich das mit dem Zurückschreiben in die DB realisieren soll.

Vielleicht was es etwas zu hoch gegriffen, als 1. Projekt gleich auf 3 Schichten zu setzen seufz.

Ach ja, ich bin gelernter Anwendungsentwickler aber leider bisher ohne echte Praxis in OOP bzw. Windows-Programmierung allgemein.

Erstmal ein Fehler: im letzten Codeblock soll itemX.IDID natürlich itemX.ID heissen...

Ich habe sowieso das 1. Mal interfaces verwendet für das 3-Layer Konzept.
Aber dass mit das hier auch helfen kann, hab ich natürlich nicht realisiert.
Ich werde es probieren.
Danke!

EDIT:
Hat wunderbar funktioniert... ausser dass die Zeile heissen muss
return ((IHasID)item).ID().ToString();

Weil Interfaces ja keine Attribute sondern nur Methoden vorraussetzen.
Also hat nun jede Klasse ein ID() implementiert, welches die unter anderem Namen gespeicherte ID (KategoID, PostenID, KontoID) per ID() als int ausibt.

Vielen Dank nochmal!

Hallo,
ich habe an diverse Comboboxen usw. Objekte (diverse Klassen) gebunden.

Ich möchte nun eine allgemeine Funktion zum ID-Erkennen aus dem gebundenen Objekt.

Funktioniert - macht aber für jede Klasse eine eigene Funktion nötig:

Der Aufruf sieht z.B. so aus:

bla = getKategoIdFromSelected(cbKatego.SelectedItem);

Die Funktion sieht so aus:

private string getKategoIdFromSelected(Object item)
{
     Kategorie itemX = (Kategorie)item;
     return Convert.ToString(itemX.ID);
}

D.h. ich weiß, alle an die Funktion übergebene Items aus Listen sind definitiv Kategorie.
Ich brauche also noch solche Funktionen für Posten, Konto ... und und und ...

Meine Idee war daher die Konvertierung zu dynamisieren anhand des mitgelieferten Types, der vorher ermittelt wird mit .GetType()

Leider funktioniert der dynamische Typumwandler nicht so wie ich will 😦
Der Aufruf für die allgemeine Funktion über alle Klassen könnte dann sein:

bla = getIdFromSelected(cbKatego.SelectedItem.GetType(), cbKatego.SelectedItem); 

In der Funktion könnte stehen:

private string getIdFromSelected(Type type, Object item)
{
      type itemX = (type)item;
      return Convert.ToString(itemX.ID);
}

Leider funktioniert das so nicht...
Ich muss dazusagen, dass ich relativ frisch in c# dabei bin - allerdings haben diverse Google-Suchen und MSDN nicht helfen können.

Edith meint: Sicher könnte man die Funktion auch je nach Typ überladen, aber ich wills NOCH Effizienter 😃