Wir haben 70 Projekte in unserer Solution, Projekte sind mit dem TFS noch nie verschwunden, weder mit 2008, noch mit 2010.

Allerdings hatten wir sehr oft Probleme mit den "Solution Foldern" (die stellen ja kein echtes Verzeichnis dar). Aus diesen sind öfter mal einzelne Dateien verschwunden - aber auch nur aus der Solution selber, nicht aus dem Verzeichnis in dem sie tatsächlich liegen.

Wir verzichten inzwischen größtenteils auf die Solution Folder und haben ein einfaches Dummy Projekt, das nicht mitgebuildet wird. Dieses Projekt enthält die Dateien in der gleichen Struktur wie vorher die Solution Folder... seither keine Probleme mehr.

Hab schon mehrmals mit DotNetZip gearbeitet und gute Erfahrungen damit.

Was will ein Franzose mit einer Städteliste inkl. Bundesländern etc. auf Deutsch?
Deswegen gibt es diese Zuordnung zu einem bestimmten Land.

Was er als Franzose mit deutschen Texten will, ist ja seine Sache. Vielleicht hat er deutsche Kunden und will bei Adressen nicht französische/englische Namen für die deutsche Stadt hernehmen. Es ist ja definitiv so, dass es englische Übersetzungen gibt, zB "Munich" für "München"

Über den Ableitungsmechanismus kann auf internationalen Tabellen aber aufgesetzt werden.

Wenn das wiederum heisst, dass "GermanChemicalElements" von "ChemicalElements" abgeleitet ist und zB deutsche Bezeichnungen einführt, find ich das ein ziemlich cooles Feature 😃

Find ich grundsätzlich eine super Idee! Auf solche Probleme stößt man ja immer wieder.

Was mich ein bisschen stutzig mache ist der Unterschliedliche Datensource für unterschiedliche Sprachen, bzw Länder (zB chemische Elemente oder Postleitzahlen).

Ursache:
Der XmlSerializer serialisiert bei Klassen die von IEnumerable<T> erben nur die Entries.

Lösung:
Mach eine Klasse, welche die Liste, sowie die zusätzlichen Properties enthält und serialisiere eine Instanz dieser Klasse.

Tipp:
Erbe nicht von List<T> sondern besser von Collection<T>.

ich hab 8GB im Firmen PC - das ist zugegebenermassen etwas mehr als der Standard Benutzer hat - nämlich 8000x so viel wie dein Programm braucht... und du machst dir Sorgen um 100k die der Compiler sparen könnte?

leider kein Witz:

public static class AttributeNames
{
// gekürzt, ca 30 string Konstante, zb:

        /// <summary>
        /// Currency
        /// </summary>
        public const string Currency = "Currency";
     
// und dann:

        /// <summary>
        /// M
        /// </summary>
        public const string M = "M";

        // was ist das? Boss von James Bond?
}

Wir machens für unsere Software so, wie Hotte es beschreibt.

Drei Kunden mit jeweils einer kundenspezifischen Culture und Resourcen. Klappt einwandfrei.

Deine IsEmpty() Implementierung macht genau das Gegenteil der .Any() aus System.Linq... Alternativ könntest du einfach

if (!collection.Any()) aufrufen...

Einige sind schon genannt worden, ich hab noch

SoapUI
zum einfacheren Testen von WebServices. Damit kann man dann auch Requests für WebMethoden absetzen, die komplexe Parameter haben.

Hallo,

ich bin vorhin über das Projekt XInclude.NET mit dem XIncludingReader zur unterstützung von <xi:include> gestolpert, und finds recht interessant.

Es geht darum den XmlReader so zu erweitern, dass man damit includes in einer Xmldatei definieren kann, die dann beim laden direkt verarbeitet werden. Man kann also (Teile) anderer Xml Dateien dynamisch einbinden.

Allerdings hat sich seit 2007 praktisch nichts mehr getan, es gibt nur 2 Checkins.

Kennt das Projekt jemand?
Ist es vielleicht sogar komplett ins .NET Framework integriert worden?
Gibts ein alternatives Projekt an dem aktiver entwickelt wird?

Kennt jemand etwas vergleichbares?

TFS 2010, beim versuch, ein Verzeichnis einzuchecken, in dem nichts geändert wurde ist auch wirklich absolute Vorsicht geboten!

Verdana, 11pt

ja, da sind die Zeichen unterschiedlich breit, aber das stört nicht.

Wenns an der XmlSerialisierung liegt, kannst du statt StringDictionary folgende probieren
(nicht getestet, from scratch):

public class MyStringDictionary : KeyedCollection<string,string>
{
  protected override string GetKeyForItem(string item)
  {
     return item;
  }
}

damit kannst du dann auch mit myDict["bla"] zugreifen.

Du kannst statt Dictionary<TKey, TItem> eine Ableitung von KeyedCollection<TItem> machen. Die ist dann serialisierbar, und hat auch schnellen Zugriff über den Key.

Das geht auch eine Ebene weiter. Wir entwickeln kundenspezifische Software, und haben ein paar deutschsprachige Kunden. Die Standardsprache der Anwendung haben wir auf de-DE festgelegt.

Ein paar Kunden wollen aber ihre Texte anderslautend, weil sie intern ein eigenes Wording verwenden. Also haben wir eine zusätzliche Culture definiert und im System registriert: de-DE-Kunde1, und Resourcen angelegt, in denen nur die Strings enthalten sind, die sich vom Standard unterscheiden. Das gleiche haben wir mit de-DE-Kunde2 gemacht. Funktioniert gut bisher.

Die Klasse Mitarbeiter behinhaltet Mitarbeiter, Angestellte, Vorgestzte, Chefs , Putze, Hilfskraft, Azubi etc.
Es gibt wohl hoffentlich eine Basisklasse Mitarbeiter von der die anderen erben?

Sieht für mich eher so aus, als wäre gemeint, dass die Benutzer die Mitarbeitertypen anlegen und einem Mitarbeiter dann einen Typ zuweisen. Daher ist zur Compilezeit nicht bekannt welche Typen es gibt...

Was ich sagen will, unter dem Begriff "Typ" muss man nicht gleich System.Type verstehen.

Aber vielleicht ist auch beides möglich:

class Mitarbeiter {}
class Chef : Mitarbeiter {}
class Putze : Mitarbeiter {}
// und
class UserdefinedType : Mitarbeiter {}

Was einem OR-mapper vielleicht am nähesten kommt ist der XmlSerializer.

Der hat halt keine Features wie LazyLoading, aber mappt er das Xml auf Objekte und zurück.

Ich glaub du willst eigentlich IXmlSerializable implementieren, nicht ISerializable...

Versuchs mal im PostBuild event mit zukopieren.

Kannst du den probing Pfad auf deinen erweitern?

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

siehe MSDN

also wenn du nicht nur im forum einen tippfehler hast, dann ist das xml invalid. die spitze klammer von

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

wird nirgends geöffnet.

xmlns sind üblicherweise attribute, nicht content eines elements.

...
TheGear war schneller 😃

Also welchen DI Container man verwendet ist unabhängig vom DI selber. Der Wechsel auf einen anderen DI Container (zB von Spring auf Autofac) sollte minimaler Aufwand sein: das hoffentlich einzige was betroffen ist, ist die Configuration und die erst-instanzierung (wahrscheinlich ein Servicelocator, oder auch eine Integrations dll für ASP oder WCF (zB autofac).

Das ganze DI, IoC, SL Thema wurde bei uns auch eingeführt als kaum wer Ahnung davon hatte, und es wurde zudem von demjenigen nicht gut erklärt. Trotzdem sind die Applications die wir direkt damit angefangen haben um Faktoren besser wartbar, obwohl das ganze eher suboptimal eingesetzt wird.

Mehr Aufwand wars dennoch nicht.

Aus dem ergibt sich für mich: Besser schlecht einsetzen, als gar nicht.

Natürlich sollte man immer abwägen ob eine Technik Sinn macht oder nicht. Auch DI wird nicht immer sinnvoll sein, mMn aber meistens schon.

Ich finde einfach nicht, dass es zusätzliche Arbeit verursacht (eher spart es Zeit). Deshalb seh ich auch nicht, warum ich es nicht verwenden sollte. Bei mir ist es Standard.

2 Sachen:

1.
ja, auch bei unserem Projekt ist DI eingesetzt und verwenden bei unterschiedlichen Kunden per unterschiedliche Implementierungen eines Interfaces, ohne irgendwas neu zu kompilieren, einfach per Xml Konfiguration. Es muss also nicht unbedingt sein, dass man bei einem Kunden "irgendwann mal was austauschen will". Kann auch gleichzeitig unterschiedlich in Verwendung sein.

2.
ja, auch bei uns ist es zum Großteil eher der Testbarkeit der einzelnen Units wegen so geschrieben. KISS und YAGNI sehe ich dabei nicht verletzt, weil ichs ja für die Tests bereits jetzt durchaus brauche (-> YAGNI) und andererseits gerade dadurch die Tests so simpel wie möglich (KISS) bleiben.

ja so:

AufrufEinerMethodeDieEinDictionaryAlsParameterBekommt(
   new Dictionary<String,Object> { { "username","Peter" } }
);

es sind je 2 geschwungene nötig. die erste fürs Dictionary<> die zweite fürs KeyValuePair<>.

die Express ist per default so eingestellt, dass im Debug ordner die Debug version liegt und im Release ordner die Release Version

-> F5 -> Debug
-> F6 -> Release

Achtung Blasphemie:

Wenn ich ein Control sehe das disabled (mit Grauschleier) ist, dann versuch ich nicht rumzuclicken, weil ich ja seh dass es nix bringt.

Wenn das Control aber enabled ist, schauts so aus als könnt ich was clicken und bin verwirrt, wenn dann nix geht.

Warum also der Aufwand?

du kannst auch die PID in den dateinamen reinformatieren

<appender name="LogFileAppender" type="log4net.Appender.FileAppender">
    <file type="log4net.Util.PatternString" value="log-file-[%processid].txt" />
</appender>

(gefunden auf log4net faq)

Der XmlSerializer hat einen Konstruktor mit "Type[] extraTypes". Da kannst du beim Erstellen des Serializers programmatisch Klassen dazufügen. Welche das sind wirst du per Reflection rausfinden müssen.

Find ich ein interessantes Projekt, ich versteh das als dynamisch erstellten Adapter (Adapter Pattern). Den könnte man zwar für jede (ausgenommen anonyme) Klasse auch selber schreiben, aber damit gehts schneller.

Interessant wären noch die Performanceunterschiede des Adapters im Vergleich zum Original bzw zu einem "handgeschriebenen" Adapter.

Im Setter von

public double dDNumthree

wird der value Parameter nicht verwendet. Das kann zwar gewollt sein, ist es aber in 99.999% der Fälle nicht.

Ist der Geschwindkeitsunterschied spürbar bei einer Client <-> Serveranwendung?

Bis zu 1000 Clients sind an einem Server.

premature optimization is the root of all evil

Trifft voll zu, hier wird in 99% der Fälle die meiste Performance nicht im List<T> verloren gehen sondern am Kabel.

Mein Traum wär ein 24"er mit 200 dpi (gibts sowas überhaupt)... da wär das auch noch recht klein.

So mach ichs auch

Man kann aber nicht mehrere Links in verschiedene (Netzwerk-) Verzeichnisse in die Leiste legen. Die erscheinen dann alle in der Jumpliste vom Explorer. Das find ich auch besser: Rechtsclick auf den Explorer und man hat alle Verzeichnislinks auf einen Blick ohne erst alle Fenster schließen zu müssen.

Zugegeben, ich musste mich erst dran gewöhnen...

Eigenes Verzeichnis erstellen und die Links da reinschieben hilft nicht? Dann könnte man die Problembehandlung eingestellt lassen...

Hab selber keine Links am Desktop 😃

Oder einfach den Hintergrund der Textbox einfärben 😉

An sich eine einfache und gute Methode. Textfeld rot hinterlegt bedeutet "Fehler", wobei du dann irgendwo hinschreiben solltest, was der Fehler ist -> und dann ist der ErrorProvider wieder besser.

Überleg auch ob Farbenblinde damit zurechtkommen müssen...

Würden in dem Fall die TypeConverter was bringen? Wenn man den registriert müsste man theoretisch mit

  System.Convert.ChangeType(color, typeof(HsvColor));

konvertieren können. Ich hab allerdings praktisch keine Erfahrung damit.

edit: Methodensignatur fixed.

Optimierungen des C#-Compilers

ad 1) der C#-Compiler könnte optimierten IL-Code ausgeben anstatt den Code nur nach IL zu übersetzen. Also zB mehr Inlining, Schleifenmanipulationen, etc.
Vorteil: Das Programm läuft schneller und dem JITer könnte arbeit weggenommen werden.
Nachteil: Im Reflektor ist der Code nicht mehr so gleich wie dem Quellcode (sofern das wichtig ist, bei yield schauts zB auch ganz anders aus)

Dass das nicht der C# Kompiler "voroptimiert" liegt daran, das dieser nicht weiss, auf welchem Prozessor der Code laufen wird (abgesehen von 32/64 bit). So kann der JITer nämlich noch intensiver optimieren. ZB wenn er die Größe der L1 und L2 Caches kennt...

Wenn man den Typ einer Variablen erst rausbekommt, wenn man zu ihrer Deklaration hinnavigiert oder erst mit der Maus auf den Variablennamen fahren muss, um deren Typ zu bekommen, hält enorm auf.

Letztlich heißt das doch, dass der Typ der Variablen aus ihrem Namen hervorgehen sollte.

Das könnte man noch einen weiteren Schritt weiterpinnen:

Wenn eine Methode so lang ist, dass man nicht ohne übermässiges Blättern zur nächstbesten Variablendeklaration in dieser hinkommen kann um ihren Typ zu erfahren, ist sie ein Kandidat fürs aufteilen. Daher braucht man die Variablen nicht ungarisch benennen, weil man den Typ eh praktisch auf einen Blick sieht, ausgenommen man verwender var. (Ausserdem sieht der Code dann für andere an C# gewöhnte Entwickler nicht ungewohnt aus.

Offtopic: In der Unterstufe habens mir noch beibringen wollen "25 Zeilen, nicht mehr", das war genau das was auf eine Bildschirmseite passt... Lustig mit VS2010 kann man mit Strg-Mausrad die Schriftgröße ändern... also wieviel Zeilen sind das dann? Die Zeiten ändern sich halt. Die meisten Methoden sind witzigerweise ohnehin kürzer.

Wenn eine Methode schon recht viele Parameter hat, diese in einer Klasse zusammenzufassen (sofern das passt), und eine Instanz der Klasse als Parameter zu verwenden. Das kann dann auch übersichtlicher sein, kommt aber immer auf den Fall draufan.

Andere Möglichkeit: Keinen Parameter, sondern ein Property in der Klasse erstellen, und dieses vor dem Aufruf setzen. Dann ist aber weitere Vorsicht geboten, zB wenn mehrere Threads auf die gleiche Instanz zugreifen (oder noch schlimmer, wenn das ganze Konstrukt static ist). Man muss auch bei allen Verwendungen aller Overloads aufpassen, dass man das Property löscht, wenn mans nicht braucht.

Beides hat seine Vor- und Nachteile.

Wenn das so ein langes Script ist, macht es vielleicht mehr Sinn, eine Stored Procedure draus zu machen, dann brauchst du im Code mehr oder weniger nur noch den Namen dieser.

Jo, die application hat auch 185 dlls - wobei ca die hälfte davon nach dem Schema geht und der Rest was ganz anderes ist.

Keiner hat gesagt, dass man alle 100 Projekte in einer Solution haben muss. Die sind ja untereinander nicht abhängig.

Das sind eine Menge kleiner Solutions mit ein paar (<10) dlls drinn.
Irgendwo gibts dann noch Clients die diese konsumieren und wirklich viele Referenzen haben.

NochnEdit:
Da schreiben aber auch gut 10-15 Leute seit 4 Jahren dran...

Nachdems hier immer mehr um Schichten geht und weniger um die eigentlichen Namespaces...

Ich hab hier grad einen Fall in dem nach Variante 3 gruppiert wird:

eine dll mit dem ServiceContracts (interface)
Product.dll

je eine dll für Model, View und ViewModel
ProductModel.dll
ProductViewModel.dll
ProductView.dll

ebenso für Customer
Customer.dll (ServiceContracts)
CustomerModel.dll
CustomerViewModel.dll
CustomerView.dll

Das wäre einer Erweiterung der Variante 2.

edit:
das hab ich für hierher angepasst.
tatsächlich gehts mehr in die Richtung:

XxxRepository.dll (für Datenzugriff)
XxxDomain.dll (DomainObjekte)
XxxContract.dll (interface)
XxxService.dll (WCF-Service)

Diese haben keine Abhängigkeiten zu den
YyyRepository.dll
YyyDomain.dll
YyyConstract.dll
YyyService.dll

Auf diese Art kann man alle einzeln austauschen. Wären alle Repositories in einer dll, alle Domains in einer und alle Services in einer... dann nicht 😃

Wenns schon ein primitiver Typ sein muss würde sich int oder noch besser uint eignen:

192.168.0.1

192 = 0xC0
168 = 0xA8
0 = 0
144 = 0x90

-> 0xC0A80090

Aber im Hinblick auf IPv6 ist das wahrscheinlich trotzdem keine gute Idee.

VS wird beim MVP für ASP.NET wahrscheinlich von selber die erste Variante wählen, weil es nicht entscheiden kann, welche Teile thematisch zusammengehören. Ich bevorzuge Variante 2. Thematisch find ich übersichtlicher.