SocketType.Raw ist für Administratoren vorbehalten, und seit WinXP SP2 auch mit Limitierungen belegt.

We have removed support for TCP sends over RAW sockets in SP2.
We surveyed applications and found the only apps using this on XP were people writing attack tools.

Ist grundsätzlich möglich, allerdings musst du bei deiner neuen Methode im OperationContract explizit einen Namen angeben:

[ServiceContract]
public interface IMyService
{
   [OperationContract]
   MyResult DoStuff(string myInput);
   [OperationContract(Name="DoStuffNew")]
   MyResult DoStuff(string myInput, int otherInput);
}

Dadurch wirds im WSDL anders benannt, und neue Clients bekommen auch den neuen Namen.

Wenn die Typen bekannt sind, die du dort übergeben und verarbeiten kannst (was ich mal annehme, weil du ja auch deine "getMessageForCode" kennst), könntest du das KnownTypeAttribute versuchen.

*Thread wieder ausgrab*
Doch interessant, dass ich scheinbar der erste bin, der WCF für sowas missbrauchen will. Bin inzwischen für was komplett anderes (aber doch mit ähnlicher API; Aufruf über URL, Response als Plain-Text) über einen ClientMessageFormatter ein wenig weiter gekommen:

class TextFormatter : IClientMessageFormatter
{
   public object DeserializeReply(System.ServiceModel.Channels.Message message, object[] parameters)
   {
      var reader = message.GetReaderAtBodyContents();
      var bufferReader = reader.GetType().GetProperty("BufferReader", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.FlattenHierarchy).GetValue(reader, null);
      var content = (byte[])bufferReader.GetType().GetProperty("Buffer").GetValue(bufferReader, null);

      return Encoding.Default.GetString(content);
   }
   [...]
}

Nach einigem Debuggen hat sich herausgestellt, dass ich über MessageBuffer.WriteBuffer und einen MemoryStream ganz Bequem an den Content der Message rankommen könnte...eigentlich. Funktioniert aber nur, wenn in der Message XML drin ist - und selbst dann hatte ich interessante Probleme mit dem Encoding, wo dann im fertigen String Zeichen waren, die ich von der Serverseite aus gar nicht geschickt habe (meist vermutlich falsch interpretierte Multibyte-Zeichen, sah am Ende nach kaputten Steuerzeichen aus).

Interesting Fact: Auch wenns kein XML ist, message.GetReaderAtBodyContents() funktioniert. Und auch interessant: der Reader (XmlUTF8TextReader) hat intern eine XmlAtomicTextNode, deren Buffer-Property meinen Reply drin hat - wie obige Lösung über Reflection zeigt.
Blöderweise ist das ganze nicht wirklich schön, und vermutlich auch nicht portabel - muss nur mal jemand hergehen und die Property umbenennen. Auch nach längerem Reflektorieren hab ich aber keine Möglichkeit gefunden, über die Methoden des XmlDictionaryReader an den Inhalt dieser Node zu kommen. Read() wirft eine Exception, MoveToContent() auch, und alle anderen ReadXxx Methoden (ReadString, ReadValueChunk, etc) liefern nur einen Leerstring - der Reader selbst bleibt im State "Initial" und macht nicht die geringsten Bewegungen in einen anderen ReaderState.

Um das ganze mal abzukürzen: Kennt jemand vielleicht eine sauberere Lösung als meine, mit der ich auch an den Byte-Content der Message rankomme?
Meine Überlegungen gingen auch schon in Richtung Streaming und StreamedResponse, weil da ja irgendwie auch alles durchkann und -kommt was sich auch nur irgendwie versenden lässt - leider auch ohne Erfolg.

Am schönsten wäre fast, wenn IMessage eine Methode Clone oder CreateNew zur Verfügung stellt, und das jeweilige Objekt es selber macht. Damit hast du keine Probleme, wenn mal neue Klassen dazukommen.

Wenn dich interessiert, was der Client schickt (so, wies tatsächlich über die Leitung geht), könnte dich vielleicht Wireshark (ehemals Ethereal) interessieren.
Wenn dich primär die Daten interessieren, kannst du auch per WCF Message Logging die SOAP Messages ausgeben lassen.

Beide Möglichkeiten erfordern keine Änderung an deinem Service, ist alles Konfiguration oder sowiso extern.

Schon mal nachgelesen, was in der CommunicationException drinsteht? Eventuell auch am Server dranhängen und die Exceptions einschalten.

Also wenn ich in mein Startmenü schaue dann haben das 98% aller Programme. Wieso auch nicht, es ist wesentlich komfortabler, finde ich zumindest.
Aber im Grunde ist das ja auch überhaupt nicht das Problem.

Microsoft Richtlinien empfehlen, keinen solchen Shortcut anzulegen. Der vorgesehene Weg, eine Applikation zu deinstallieren, ist über die Systemsteuerung.

In meinem Startmenü siehts irgendwie genau umgekehrt aus, 98% aller Programme haben keinen Uninstall Eintrag. Nur Notepad++ fällt bei mir scheinbar aus dem Rahmen.

Schreit ja fast nach Generics und Delegates.

Definiere dir eine neue Methode, die einen Typparameter hat und einen Delegate nimmt, der den Parameter verwendet:

private string MethodG<T>(T input, Func<T, string> transform)
{
   if (!logicHere)
      return "not logical at all";
   return transform(input);
}

public string Method1(int input)
{
    return MethodG(input, i => i.ToString());
}
public string Method1(string input)
{
    return MethodG(input, s => s.TrimLeft('0'));
}

Dank Type-Inference und Lambda-Expressions kann man damit doch einiges an Code einsparen.
Dein getString dürfte dem transform entsprechen, den Rest darfst du dir selbst erarbeiten 😃

Per Linq-to-XML kannst du XElement.Name verwenden. Über XSLT (und XPath) gibts die local-name() Methode (Beispiel "//Data/*[1]/local-name()")

Problem bei Pex ist oft, dass es bei etwas "komplexeren" Sachen oft schon ansteht und nicht mehr weiterkann (was mir oft passiert ist, bis ichs irgendwann mal sein gelassen hab: Parameter-Objekte, die mehrere andere Parameter zusammenfassen und im Vorfeld schon validieren). Und dort per Code und den von Pex benötigten Object Factories nachhelfen funktioniert(e) damals auch nicht ganz reibungslos.
Umgekehrt konnte ich aber mit CrashTest.net teilweise bessere Ergebnisse erzielen als mit Pex (hat manchmal die Parameter-Objekte richtig gemacht), war dafür ab und zu nicht ganz so stabil (bleibt hängen, reagiert nicht mehr oder stürzt auch mal mit einer unhandled Exception ab).

Um zu den Tests als Dokumentation, TDD und Co zurück zu kommen:
Was ich schon mehrmals gemacht habe, war die Anforderungsdokumente von Kunden und/oder Vorgesetzten als Test zu formulieren - damit ist mal sichergestellt, dass das funktioniert, was gefordert ist. Natürlich TDD-Style, erst den Test, dann implementieren. Im Anschluss kurz die Code-Coverage anschaun, ob irgendwas nicht durch den Test erwischt wurde; dafür schreib ich dann ggf. auch was (Alles natürlich unter der Vorraussetzung, dass die Anforderungsdokument auch einigermaßen das enthalten, was man braucht - und nicht was man denkt dass man braucht. Aber das Problem gibts überall und muss man irgendwo selber abschätzen können).

Für Fälle, die ich nicht kenne, schreibe ich logischerweise auch keinen Test. Vor allem: sollte so ein Spezialfall fehlschlagen, muss ich mit ziemlicher Sicherheit sowiso den Code anpassen und ggf. auch weitere Tests schreiben. Da halte ich es wie mit den Exceptions, don't catch what you don't expect.

Einen Punkt habe ich oben bewusst nicht erwähnt, den ich aber teilweise bei meinen Kollegen sehe oder zumindest schon mehrmals als Diskussionspunkt hatte:
Testet ihr (erfolgreiche) Fälle von Konstruktoren und Properties? Beispiel: Ctor setzt das Property "Name" auf den übergebenen Wert, Test mit

Assert.Equals(expected, new MyObject(expected).Name);

Oder es gibt eine automatische Property Name; testet ihr dort ob das Framework das richtige tut; zur Sicherstellung dass es sich auch in Zukunft so verhält (und nicht dass mal eine Validierung im set reinkommt, die alles kaputt macht):

class UnderTest { public string Name { get; set; } }
[...]
Assert.DoesNotThrow(() => underTestInstance.Name = expected);
Assert.AreEqual(expected, underTestInstance.Name);

Schon mal unter Project settings > Build > Advanced versucht, den Haken bei "Do not reference mscorlib.dll" zu setzen?

Ohne die Details von Excel-Export usw. zu kennen, würde ich dir mal den XmlNamespaceManager empfehlen. Mit den alten Xml-Technologien braucht man normalerweise das Teil, wenn man mit Namespaces arbeiten will.

Du könntest dir die Boot-Zeit merken, die dürfte sich auch nur einmal pro Boot ändern 😉
Findet man in der Registry, per WMI und diverse andere Wege.

Also, ich hab das kürzlich erst gebraucht um rauszufinden, für welche Architektur meine Oracle.DataAccess.dll gebaut wurde - lief nämlich nicht gemeinsam mit einer "Any" Applikation auf einem x64 System.

Anyways, schau dir mal AssemblyName.ProcessorArchitecture und Module.GetPEKind an. Ersteres reicht dir vermutlich.

VS2010 hat den sogenannten "Call Browser", der aufzeigt welche Methoden aufgerufen werden, und von welchen Methoden sie aufgerufen werden.
Allerdings glaube ich, dass der auf C++ beschränkt ist (dort gab es sowas auch schon in 2008, wenn ich mich recht erinnere). Heißt "Call Hierarchy" und kann per Rechtsklick auf eine Methode aufgerufen werden > "View Call Hierarchy".

Was spricht dagegen, die Binding.Converter-Property zu verwenden? XAML macht ja auch nix anderes, vermutlich frisst der Konstruktor das aber nicht in der Form.

Morgen!

Die prominenteste Anwendung von RTTI ist vermutlich die Serialisierung, auch wenn man das leicht vergessen kann. Member des Typs ermitteln, Metadaten-Attribute auslesen, persistierbares Format erzeugen und später wieder zurück zum Objekt...seis jetzt alleine zur Persistierung von Daten (Settings usw) oder einfach zur Übermittlung an verteilte Systeme (per Remoting, WCF oder ähnliches).

Sicher auch Praxisbezogen: Plugin-Architektur, wo per Assembly.Load und Co andere Assemblies geladen, nach bestimmten Typen durchsucht und in die eigene Applikation integriert werden (siehe diesbezüglich vielleicht auch gleich MEF (Managed Extensibility Framework) als Anwendung).

Von EQATEC gibts die kostenlosen Tracer und Profiler, die dir vielleicht weiterhelfen könnten.
Hab die damals kurz unter die Lupe genommen und als kostenlose Tools für Gut befunden, am Ende hat aber das Ants Bundle gewonnen.

Du mischst trotzdem zwei verschiedene Sachen.
Dein UserControl kann ja (bzw muss) im GUI-Thread laufen. Wenn du auf den Button klickst, schieb das ganze in den Background - die Kollegen BackgroundWorker und ThreadPool helfen dir da sicher weiter.

Ich denke, du gehst ein wenig falsch an das ganze heran...

Das Plugin sollte nie von sich aus entscheiden, dass es jetzt eine GUI anzeigt. Das sollte immer vom Host ausgehen; und das aus dem GUI-Thread.
Beispielsweise stellt dein Plugin eine Methode ShowGUI() zur Verfügung, die vom Host benutzt wird. Oder CreatePluginControl(), was dein eigenes UserControl zurückgibt und im Host entsprechend angezeigt wird.

Könnte vielleicht helfen, wenn du IEquatable implementiert. Allerdings wird das List<T>-interne Contains auch nicht viel anders machen als du. Was du allerdings haben willst ist eher ein Find; und das geht mit Predicate<T>.

Ich würde eher versuchen, die 3 nested Loops (while-for-for) zu vereinfachen.
Walkable sieht beispielsweise so aus, als ob du das "so nebenbei" schon für den nächsten Durchlauf mitberechnen könntest - ein look-ahead quasi. Wenn ich das Ding richtig verstanden habe, prüfst du die 8 Felder rund um das aktuelle - und zumindest 5 davon kennst du je nach Richtung bereits.

Mag sein, dass Ankh über diverse Extender-Provider Sachen macht, die dem Studio nicht gefallen - das Problem hatten wir auch mehrmals hier.

Nur hab ich das Problem mit der kaputten Intellisense/Cursortasten trotzdem (und ich meine, es auch zwischenzeitlich ohne Ankh gehabt zu haben, als der Patch noch nicht raus war).
Äußert sich dadurch, dass entweder keine Intellisense bekomme, im Gegenteil das komplette Intellisense Menü offen bleibt (und teilweise beim weitertippen sogar doppelt kommt) und sich ab und zu die Cursor Up/Down Tasten nicht mehr verwenden lassen (most likely auch weil Intellisense irgendwo hängt).

WinXP Pro SP3, VS2010RTM Pro, keine Plugins außer Ankh.

Klingt auf den ersten Blick nach einem Concurrency-Problem. Benutzt du mehrere Threads, oder hast möglicherweise einen ungünstigen InstanceContextMode gesetzt?

Schau dir auch den Trace genauer an; in der Ansicht "Graph" siehst du wann/wie welche Aufrufe getätigt wurden. Am besten lass sowohl Client als auch Server tracen, dann kannst du beide laden und siehst auch wie die Messages hin- und her gehen.

Ansonsten, wenn du keine Angst vor Code hast, kannst du dir über CSharpCodeProvider (ggf. mit CompilerVersion = v3.5 wenn du auch Linq willst) selber sowas bauen.
Intellisense gibts zwar keine, kann dafür aber mehr als nur 2.0 (schon mal versuch, im Immediate Window eine Lambda Expression zu verwenden? Das kann auch VS2010 noch nicht).

Hier is ein kleines Schnipsel diesbezüglich, was ich immer wieder aus dem Hut zaubere, wenn ich mal ein bisschen dynamisch Code ausführen will (REPL anyone?):

public static Action GenerateCode(string sourceCode)
{
	var prov = new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v3.5" } });
	var cp = new CompilerParameters()
	{
		GenerateExecutable = false,
		GenerateInMemory = true,
		IncludeDebugInformation = false,
	};
	cp.ReferencedAssemblies.Add("mscorlib.dll");
	cp.ReferencedAssemblies.Add("System.Core.dll");
	cp.ReferencedAssemblies.Add("System.ServiceModel.dll");

	var res = prov.CompileAssemblyFromSource(cp, @"using System; 
using System.Linq; 
using System.Text;
using System.Collections.Generic;
using System.ServiceModel;

namespace Dynamic 
{
	class Generated 
	{
		public static void Method()
		{
		" + sourceCode + @"
		}
	}
}");
	if (res.Errors.Count > 0)
		return null;
	else
		return (Action)Delegate.CreateDelegate(typeof(Action), res.CompiledAssembly.GetType("Dynamic.Generated").GetMethod("Method"));
}

Kann dann so verwendet werden:

Action writeLine = GenerateCode(@"Console.WriteLine(""test"");");
writeLine();

oder

Action doLinq = GenerateCode(@"var i = (from num in Enumerable.Range(1,10) where num % 2 == 1 select num).Skip(2).First();
Console.WriteLine(""Some number: {0}"", i);");
doLinq();

So, da hat der böse .de-Root Nameserver zugeschlagen, auf die Antwort durftest du jetzt 3 Stunden warten 😃

Mit kostenlosen Tolls kommste da nicht weit. Der Resharper kostet bisschen was, ist meiner Meinung aber auch das einzige brauchbare Refactoring Tool.

Kann ich nicht bestätigen. CodeRushX ist in der Hinsicht sehr flexibel und auch gut/einfach erweiterbar (über DXCore). Sollte man zumindest einmal versuchen, bevor man Geld in Sachen investiert, die am Ende doch nicht das tun, was man eigentlich braucht.

Muss aber auch zugeben, dass ich kein Freund von Resharper bin - hat mich seinerzeit nicht überzeugt und ist auch mit den aktuellen Versionen nicht wirklich meinen Anforderungen gerecht (zu viele Shortcuts für eigentlich ähnliche Sachen, die auch Context-abhängig klar sein dürften; zu viel Painting im Editor was ich eigentlich nicht will; irgendwie in Summe einfach "zu viel"). Ist aber bekanntlich Geschmackssache und das ist auch gut so.

Auf den ersten Blick würde sich CodeRush Xpress anbieten, der kleine (kostenlose) Bruder von CodeRush und der DXCore/Refactor! Serie.
Bietet viele Refactorings und kann über Plugins erweitert werden - was du willst (Code gruppieren) dürfte über CR_ClassCleaner möglich sein (nicht getestet, klingt aber stark danach).

Also wärs wohl besser doch wieder alles ins Hauptprojekt zu "verschieben" ?

Im Gegenteil, verschieb die Klassen, die du überall brauchst, in eine der Klassenbibliotheken; oder erstell eine weitere wenn sich durch die Trennung kein geeigneter Platz finden lässt.

Alternativ kannst du auch die Dateien per "Add as Link" ins Projekt einfügen, aber ich bezweifle dass das Sinn der Sache (abgesehen vom Architekturgedanken und DRY) ist.

Alternativ nimm im XAML die Height/Width Attribute vom Fenster weg - eventuell mit SizeToContent.

Nachdem du Code hast, der direkt Mono verwendet, hast du vermutlich auch entsprechenden Code für Windows, der das nicht tut, oder?
Ansonsten würde dir unter Windows doch ein Teil fehlen, der wie bereits angemerkt wurde nicht mitkopiliert wird/werden soll/kann.

Kannst du die Teile vielleicht entsprechend abstrahieren und ein Interface extrahieren, dass du unter Unix einfach eine andere Assembly als unter Windows verwendest?

Oder mal anders gefragt, was verwendest du aus dem Mono Namespace, was keine Entsprechung im .NET Framework hat? Mono ist ja an sich dazu gedacht, dass dieselbe Codebase auf allen Systemen gleich lauffähig ist.

Du könntest mal versuchen, folgendes Attribut über die partial class zu hängen:

[System.ComponentModel.DesignerCategory("")]

(Die vollständige Namensangabe inklusive Namespace ist kein Fehler, sondern Absicht; ist irgendeine Eigenheit des Designers)

Ich befürchte allerdings, dass er das dann für die gesamte Klasse übernimmt, und auch deine PrintOptions.cs mit dem Text-Editor öffnet...
Definiert deine AdditionalFunctions.cs auch deinen Basistyp, von dem abgeleitet wird?

Wenns nur drum geht, ein paar Dateien aus dem SVN runterzuladen (entsprechend einem svn export), dann tuts auch ein normaler WebClient (und ein bisschen Wissen im Bereich WebDAV - oder ein Packet Logger ala Wireshark). Hab ich beispielsweise gemacht, und mit ein bisschen Infrastructure sinds effektiv nicht mehr als knapp 100 Zeilen Code um eine Datei zu laden, die Repository-Struktur anzuzeigen oder an Properties der Files zu kommen.

Brauchst du mehr (Verwaltung der Sandbox, checkout/checkin, eventuell diff oder ähnliche Spielereien), wirst du an einer Library wie SharpSvn nicht herum kommen. Letztere kann aber auch als Source aus dem Collab-Repository geladen werden, wenn ich mich nicht irre...

Ich bin auch ein großer Fan der Lambda-Lösung, vor allem für NotifyPropertyChanged und Co.
Nur sollte dir dabei klar sein, dass zur Compile-Time ein Expression-Tree generiert wird; der bei jedem Aufruf ausgewertet werden muss:
http://blog.quantumbitdesigns.com/2010/01/26/mvvm-lambda-vs-inotifypropertychanged-vs-dependencyobject/
Das ganze ist dann möglicherweise langsam, wenn es häufig vorkommt.

Ich will die Lösung jetzt nicht schlecht machen, im Gegenteil, ich benutze sowas recht häufig. Nur sollte dir bewusst sein, dass es möglicherweise die Performance ein Stück nach unten drückt (kann man allerdings damit lösen, indem man das Ergebnis der Auswertung als string mitspeichert und den verwendet).

AnkhSVN ist ein Source-Control Provider, der sich direkt in VS integriert; TortoiseSVN hingegen ist eine stand-alone Applikation, welche sich direkt in den Explorer integriert.

Nachdem beides auf SVN basiert und damit auf dein Repository zugreifen kann, kannst du auch beide (gleichzeitig!) verwenden - Ankh über VS und Tortoise über den Explorer.
Einfach deine Doku zum Source-Code legen, per Tortoise > Add die Dateien in die Verwaltung aufnehmen und per Commit ins Repository schieben.
Wird zwar nicht im VS angezeigt, weils nicht Teil der Solution ist, wird dann aber bei einem Checkout der Sourcen mitgenommen.

Der Index (und auch der Count) sind nur auf den Buffer bezogen, den du als Parameter reingibst. Du kannst beispielsweise 10 Bytes (Count = 10) von einem 512-Byte Buffer rauskopieren, beginnend ab dem 100sten Byte (Index = 100).

Stream.Length ist vom Typ long, und der sollte doch für 40GB reichen.
Versuch, den Stream regelmäßig auf die Platte zu flushen, und eventuell chunked zu schreiben (z.b. immer 10KB pro Write-Aufruf) - letzteres ist vor allem bei Netzwerkzugriffen (UNC, Netzwerklaufwerk) zu empfehlen, weil dort der verfügbare Kernelspeicher des Zielrechners auch eine Rolle spielt.

Ok die Abfrage von this.DesignMode innerhalb des Konstruktors des UserControls hab ich schon ausprobiert. Leider mit negativen Ergebnis. Es ist wohl so, dass das DesignMode property ausgerechnet im Konstruktor von UserControls nicht funktioniert (also immer false zurückliefert).

Kleiner Hinweis am Rande, this.DesignMode funktioniert nicht im Konstruktor - logisch, weil das Objekt zu dem Zeitpunkt grade erst erstellt wird.

Hmm, so einfach (und vor allem Type-Safe) wird das dann nicht, wenn du mit einem Attribut alle Prüfungen erschlagen willst.

Könnte mir da was in der Richtung vorstellen:

public sealed class RangeCheckAttribute : Attribute
{
   private readonly IComparable _min;
   private readonly IComparable _max;
   public RangeCheckAttribute(IComparable min, IComparable max)
   {
      _min = min;
      _max = max;
   }
   public string Check(IComparable value)
   {
        if ((value.CompareTo(this._min) > 0) || (value.CompareTo(this._max) < 0))
            return "ÜBERSETZUNG";

        return string.Empty;
   }
}

Problem bei dem Ansatz ist, dass du _min = 23 _max = 4.2f und value = "Test" vergleichen könntest - ein paar Prüfungen mit GetType() und ein bisschen Exception-Werfing könnten da aber nachhelfen.

Implementier einfach das generische Interface - du kennst den Typ dort ja:

public sealed class IntRangeCheckAttribute : Attribute, IPropertyCheckAttribute<int>
{
    [...]
    public string Check(object owner, PropertyInfo propertyInfo, int value)
    {
        if ((value.CompareTo(this._minIntValue) > 0) || (value.CompareTo(this._maxIntValue) < 0))
            return "ÜBERSETZUNG";

        return string.Empty;
    }
}

An der Stelle ist T gleich int, drum wird aus dem dritten Parameter auch "int value", und nicht nur "T value".

Mein Code-Snippet hatte genau das Problem, wenn die Bilder größer wurden (>2 MB).
Bei kleineren hats funktioniert, weil GDI schneller war als das Dispose (oder so).

Wenn ich mir deinen verlinkten Artikel durchlese, geht es doch dort primär um das Laden von Bilder von der Festplatte.

Dem ist leider nicht so.
Versuch mal das hier:

using (var ms = new MemoryStream(imageData))
   return new Bitmap(ms);

Ich würde sagen, 50:50 Chance dass es funktioniert. Den Ansatz mit Image.FromStream hab ich noch nicht versucht (bzw. bisher nicht gefunden), drum kann ich dir net sagen obs dort auch auftreten würde.

Nichtsdestotrotz sollte den Link zumindest mal jeder gesehen haben, der in irgendeiner Weise mit System.Drawing zu tun hat; schon allein um zu wissen, was im Hintergrund eigentlich alles passiert.

Morgen!

Vielleicht kannst du dir ja was am Beispiel Value Clamping abschaun.

Besser wärs natürlich, wenn du den Typ schon als Typparameter reinbekommst, dann musst du auch nicht mit untyped Reflection rumspielen (und in dem Fall mit GetMethod mit MakeGenericMethod).

Stattdessen übertrage eine Byte-Array und wandle es bei Bedarf um in ein Image. Hier mal die Klasse die ich für solche Sachen immer nutze:

Bei sowas immer vorsichtig sein, nachdem System.Drawing intern immer noch auf GDI setzt, könnte es passieren dass du die nichtssagende "A generic GDI+ error occurred" Exception bekommst:
http://support.microsoft.com/?id=814675

Zitat "GDI+, and therefore the System.Drawing namespace, may defer the decoding of raw image bits until the bits are required by the image."
Bin mir nicht ganz sicher, ob das auch bei Image.FromStream der Fall ist, aber es kann definitiv passieren wenn du beispielsweise den Bitmap-Konstrutor verwendest, der einen Stream als Parameter nimmt.

Würde es nicht reichen, einen neuen Typ zu erstellen, der vom Quelltyp ableitet und explizit (nur) sagt, dass das Zielinterface implementiert wird (müsste dann zu Fehlern führen, wenn die Methoden nicht da sind). Danach einfach per FormatterServices.GetUninitializedObject ein Exemplar dieses Typs erzeugen und die Felder vom Quellobjekt reinkopieren.
Das würde m.E. dem Cast viel näher kommen. Das bisherige Vorgehen von Latent.Cast ist doch eher ein Convert. Oder?

...macht aber ein Problem mit sealed Typen, behaupte ich mal ohne es probiert zu haben (anonyme Typen sind nämlich sealed).

Grundsätzlich finde ich die Idee aber interessant, hatte schon mehrmals Fälle wo ein anonymer Typ gleich ausgesehen hat wie ein Interface.

Mahlzeit!

Wenn ich an einem Endpoint eine Klasse bereit stelle, ist diese dann eine Singleton Klasse? Oder wird von jedem Client dann eine eigene Instanz am WCF-Server erzeugt?

Kannst du an der Service-Implementierung festlegen - dort stellst du ein, ob pro Call oder pro Session eine neue Instanz angelegt wird, oder ob es nur eine Singleton-Instanz gibt die alles macht.
Stichwort ServiceBehavior und InstanceContextMode.

Machen Singleton Klassen unter WCF irgendwelche Probleme. Unter ASP.NET sind Singleton ja bekannt für die schönsten Bug suchspiele.

Kommt immer drauf an, wie sich dein Singleton verhält, wenn man von mehreren Threads drauf zugreift 😃
Ist nicht wirklich WCF-spezifisch das Problem; also wirds vermutlich auch wieder auf die Bug-Suchspiele herauslaufen, wenn der Singleton damit nicht zurechtkommt.

Ist ein IoC hinter dem WCF Contract eine gute Wahl, wenn man Singleton Instanzen verwalten möchte? Oder schadet das der Performance dann schon wieder extrem? Ich frage deshalb, weil ich eine Singleton Klasse für die Benutzerverwaltung dahinter schalten möchte, bei dem sich die Clients anmelden müssen und dann ein Token mit durch reichen sollen bei den Anfragen.

Eigentlich auch wieder wie beim Singleton selber, kann Probleme machen, muss aber nicht. Wenns nicht grade ein selber gestrickter IoC mit viel Reflection und ohne Caching ist, wirds vermutlich auch keine Probleme machen.

Für die Benutzerverwaltung bräuchte ich noch einen Tip, wie man das am besten umsetzt. Im moment weiß ich soviel, das man einen Credential der ChannelFactory mitgeben muss, von einem Benutzer, der auf dem Server existiert. Ob das die sicherste Lösung ist ( Transport Sicherheit etc ) mag ich mal noch zu bezweifeln.

Müssen tust du nicht. WCF Security sollte man zwar im Auge behalten, besonders wenns über unsichere Infrastruktur wie das Internet läuft, aber das muss nicht immer dasselbe sein wie deine interne Authentifizierung zu deiner eigenen Business Logik - können zwei verschiedene Sachen sein.
WCF stellt dabei sicher, dass die beiden Endpunkte (Client und Server) "echt" sind (per Zertifikat usw.), eine gesicherte Verbindung aufgebaut wird (Transport Security, z.b per SSL), keiner dazwischen eine Nachricht abfangen und mitlesen kann (Message Security, z.b per Verschlüsselung der Nachrichten) oder auch dass die Nachrichten tatsächlich ankommen (Reliability).
Ob der Client trotzdem bei dir Daten anfordern darf, muss letztendlich deine eigene Logik entscheiden (möglicherweise mit eigener Authentifizierung über Benutzername/Passwort, PKA oder ähnlichem).

Das sind jetzt mal so die Fragen, die mir eben durch den Kopf gegangen sind. Im moment bin ich noch am überlegen, wie ich den Server genau aufbauen soll. Gibt es da ein Pattern, was da am besten rein passt in die Thematik?

Im Optimalfall hast du einfach nur das Service-Interface (ServiceContract), der dem Client bereitgestellt wird. Und mit dem arbeitest du, als obs einfach ein Interface (und lokal) wäre. WCF wird dir (natürlich auch nur im Optimalfall) alles soweit verstecken, dass du nix von der Kommunikation im Hintergrund mitbekommst.
Patterns gibt es sicher, aber wie immer sollte man Patterns nur dort benutzen, wo sie auch Sinn machen; und nicht dort wo man denkt dass man ein Pattern benutzen sollte.

Gruß, BhaaL

Da fehlt entweder die address beim Endpoint, oder eine baseAddress.

Sind die entsprechende Services möglicherweise als Singleton konfiguriert, werden aber immer pro Aufruf erzeugt?
Zumindest bei WCF ist es so, dass du dem ServiceHost entweder eine Instanz mitgibst (die dann natürlich vor dem Start erzeugt wird - was den ersten Aufruf nicht bremst) oder diese dynamisch (beim ersten Aufruf eben) angelegt werden.
Wie das bei asmx ist, hab ich momentan nicht im Kopf, aber vermutlich wirds dort ähnlich ablaufen.

Hallo liebe C-Sharp Gemeinde!

Es ist mal wieder Zeit für eines der typischen "Bin ich der Erste der sowas versucht?!"-Topics.

Ausgangssituation sei folgendes XML:

<?xml version="1.0"?>
<!DOCTYPE root PUBLIC "-//test//DTD Some Xml DTD//EN" "">
<root>Some Trademark: &trade;</root>

Lade ich das ganze über XDocument.Load, logisch, gibts eine Exception: Reference to undeclared entity 'trade'.
Jage ich vorher HtmlUtility.HtmlDecode drüber, sind zwar die meisten Entities aufgelöst, unter Umständen sind aber exotische Entities drin, die HtmlUtility nicht kennt oder die komplett custom in der referenzierten XML-DTD deklariert wurden. In diesen Fällen, gleiches Ergebnis, Exception.
Vor allem mit dem Nachteil, dass die Eingabedatei möglicherweise in einem anderen Encoding abgespeichert wurde, und damit erst wieder ein händisches konvertieren mit sich bringen würde (oder das altbekannte Problem "kaputte Zeichen").
Im Grunde hätte ich gerne EntityHandling.DoNotExpand, was es blöderweise nicht gibt.

Mein alternativer Lösungsansatz ist nun folgender:

1. Einen eigenen XmlReader oder XmlResolver zu definieren, der Entities nach Text übersetzt. Das Entity "&trade;" sollte hier als Text "&trade;" wieder rauskommen.
2. XML wie gehabt bearbeiten.
3. document.Save(...). Nachdem die Information nicht mehr vorhanden ist, dass "&trade;" ein Entity ist oder war, wirds als normaler Text rausgeschrieben - und wer auch immer das XML danach liest, findet das unmodifizierte "&trade;" - und macht draus hoffentlich korrekt das Trademark Symbol.

Meine ersten Gehversuche über einen XmlReader sind gescheitert:

• Ändere ich bei NodeType == XmlNodeType.EntityReference den LocalName auf "&entity;", verschwindet das Ding komplett aus dem XML.
• Ändere ich den NodeType auf XmlNodeType.Text und überschreibe Value auf "&entity;", habe ich im Ergebnis "&amp;entity;" - auch falsch.

Andere Versuche über XmlResolver sind auch kläglich gescheitert, mangels Hilfestellungen wie man so ein Ding richtig implementiert - Trial&Error hat auch nicht wirklich zu einem Ablauf geführt, wo der Resolver nach einem Entity befragt wurde.

Drum meine Fragen an euch:

• Schon mal dasselbe Problem gehabt, und möglicherweise auch eine Lösung?
• Falls nicht, ihr aber Erfahrung mit Xml/Entities und XmlReader/XmlResolver habt (oder zumindest wisst wie man letzteres korrekt implementiert), wie könnte ich sinnvoll an dieses Problem herangehen?
  Workarounds ala "Machs als Text auf und ersetz die Entities" würde ich gerne vermeiden, da ich nie wissen kann welche Entities der Benutzer tatsächlich hat (hauptsächliche Herausforderung hierbei ist, dass ich selten bis gar nicht Zugriff auf DTD oder Schema habe, und die Entities vom Framework resolven lassen kann).

In diesem Sinne hoffe ich natürlich auf zahlreiche Antworten und bedanke mich schon mal zumindest fürs lesen.

• BhaaL

Warum denn unbedingt Regex?

DateTime dt;
if (DateTime.TryParseExact(input, "MM.yy", null, DateTimeStyles.None, out dt))
   Console.WriteLine("Year is {0}, Month is {1}", dt.Year, dt.Month);
else
   Console.WriteLine("Could not parse input");

Strg+Alt+Shift+O öffnet die Optionen, dort kannst du unter IDE > Shortcuts alles einstellen.
Was du suchst ist mit ziemlicher Sicherheit "SmartTag Execute".

Lösch mal unter %AppData% den Ordner Microsoft\VisualStudio. Wenn das nix bringt, die Ordner VSCommon und VSA gehören da auch mit dazu.
VisualStudio sollte aber reichen, da liegen die meisten Einstellungen drin.