wenn du nchar nimmst wird immer der Rest als Leerzeichen aufgefüllt, jedoch nicht bei varchar. Du solltest aber besser nvarchar benutzen, da nvarchar den String als Unicode abspeichert.
DependencyProperties sind in diesem Fall nur bedingt das richtige Schlüsselwort. DependencyProperties sind interessant wenn man selbst benutzerdefinierte Controls erstellt
du könntest TraceListeners verwenden. Dann fügst du den TraceListener einen von TraceListener geerbten Klasse an, welcher dem Programm den Consolen-Output mitteilt.
Ich habe das so gemacht, damit ich die Consolen-Outputs in eine Text Datei abspeichern kann.
bevor du dich auch in das Thema SQL-String zusammenflicken vertiefst, lies dir folgenden Artikel durch, denn so wie du es machst ist es ziemlich fehleranfällig und unsicher [Artikelserie] SQL: Parameter von Befehlen.
Nebenbei führst du deine SQL-Befehle überhaupt nicht aus. Aber das steht alles in den Links von inflames2k.
ich glaub hier geht komplett unter dass es hier um SelectedItems geht und nicht um SelectedItem. SelectedItems ist eben keine DependencyProperty und desshalb kann man auch nicht dagegen binden. Ich hatte das Problem auch mal. Ich glaub mich erinnern zu können, dass ich ein AttachedProperty programmiert habe, müsste aber heute Abend nachschauen.
warum brauchst du alle Kommastellen? Unter Double.ToString steht, dass standardmäßig nur 15 Stellen angegeben werden und diese bei Bedarf im format geändert werden kann.
Bitte zuerst immer in der Dokumentation nachschauen. Generell weißt diese auf spezielle Eigenschaften darauf hin.
mit "letzten beiden Daten" nehme ich an du meinst die letzten beiden Zeilen der originalen csv Datei.
Wie schließt du den StreamWriter, kann sein, dass du den falsch schließt und er die letzten Werte nicht in die Datei schreibt?
bis jetzt habe ich noch keine Speicherplatzbegrenzungen bemerkt.
Nein es ist nicht so wie bei Sourceforge oder GitHub abrufbar. Es ist ein privater TFS-Server.
Bezüglich Version control ist TFVC oder Git beim erstellen eines Team Projektes auswählbar.
Ja, man kann damit mit Visual Studio daraufzugreifen und auch Work Items/Bug/Backlog erstellen.
Ja, das stimmt. Auf den Entwicklerrechner wird es mit VS2012 mitinstalliert. Bei Kunden kann man, wenn man mit ClickOnce arbeitet bei der Installation auswählen dass LocalDB mit installiert wird. (auf jeden Fall glaube ich das, müsste es am Abend testen)
es gibt auch die Möglichkeit des LocalDB. Ich verwende dies auch in meinen Projekten als lokale Datenbank, da diese gegenüber SQLCe doch etwas mächtiger ist. D.h. LocalDb hat die Funktionalität eines SQL-Server Express.
Nein, es werden keine Dateien doppelt generiert. Der JIT entscheidet beim Programmstart ob dein Programm als 32Bit oder 64Bit Prozess gestartet wird. Dies hängt dann davon ab, welche CPU und Betriebssystemarchitektur du hast. Probleme hatte ich bisher keine, es sei denn du benutzt 3rd Party Assemblies welche in x86 kompiliert wurden, diese funktionieren dann nicht, und somit muss dein Programm auch x86 sein.
Was nach dem Ablaufen des Testzertifikates passiert habe ich keine Ahnung. Du könntet zum Testen, das Datum des PCs auf ein späteres Datum stellen. Da ich kein Code-Signing Zertifikat habe verzichte ich auch auf das Verwenden des Testzertifikates.
diesen Fehler habe ich auch einige male erhalten. Generell steht jedoch in den Fehlerdetails sehr genau was fehlt. Es kann sein, dass beim veröffentlichen etwas falsch gegangen ist, jedoch erscheint dieser Fehler auch, wenn sich der Schlüssel zum Signieren ändert.
bei diesem Problem greift die Code Policy. Du musst explizit angeben, dass Assemblies von Remotequellen volle Vertrauenswürdigkeit gewährt werden soll oder nicht. Dies erreichts du indem du in der App.config folgende Zeilen einfügst: