Zitat:
- es nicht zu MS Standardtool's kompatibel ist obwohl es in MS VS 2010 läuft?
Das ist kein Problem von Prsim, sondern von MS. Auch hier sind manchen Sprachen gleicher, obwohl alle gleich sind
Mit F#-Projekten kommt Blend btw. auch nicht zurecht. Und F# wird inzwischen sogar als 'First Class Citizen' in der MS-Entwicklungswelt bezeichnet. Das ist wirklich kein Problem von Prism sondern vom Blend-Team bei Microsoft.
Bug Report einreichen ist das einzige was helfen kann.
Zu C#: Wenn man .NET ernsthaft entwickeln will (egal in welcher Sprache), sollte man dennoch mindestens C# auf jeden Fall kennen.
Auch wenn C# hinter Prism immer noch massiv hinterherhinkt - schliesslich haben die noch kein integriertes AOP, und so nette Dinge wie boolean-double-comparisons ( if (x < myVar < y) then... ). Auch Interface delegation und die vereinfachte Extension-Method Syntax ist etwas, was ich in C# schmerzlich vermisse, und zwar jedes mal wenn ich damit arbeite.
Die Frage ist also eher, soll man, nur weil Microsoft es nicht gebacken bekommt sein eigenes Projektformat zu lesen wenn in einem Attribut im
XML ein Wert drin steht, den sie nicht erwarten, auf den ganzen Sprachkomfort und die Fortschrittlichkeit von Prism verzichten?
Wir sind hier in der .NET Welt - also warum nicht z.B. die Business-Logik und auch das WPF bzw. Silverlight ViewModel komplett in Prism schreiben und ausschliesslich die Oberfläche die diese Objekte dann nur noch databindet in einem separaten C#-Projekt machen das ausser dem generierten keinen anderen Code hat? Das hilft sogar noch zusätzlich, das Projekt sauber zu halten indem man keinen Logik-Code in die Präsentationsschicht bringen kann.
Ich würde sagen nicht entweder oder, sondern ein ganz klares und: Jede Sprache dort einsetzen, wo es am meisten Sinn macht und am effizientesten ist.