Quel est le cas de coin le plus étrange que vous ayez vu en C # ou .NET? [fermé]

Je collectionne quelques cas d'angle et des casse - tête et j'aimerais toujours en savoir plus. La page ne couvre vraiment que les bits et bobs du langage C #, mais je trouve aussi les choses de base .NET intéressantes aussi. Par exemple, en voici une qui n'est pas sur la page, mais que je trouve incroyable:

string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));

Je m'attends à ce que pour imprimer Faux - après tout, "nouveau" (avec un type de référence) crée toujours un nouvel objet, n'est-ce pas? Les spécifications pour C # et l'interface CLI indiquent que cela devrait. Eh bien, pas dans ce cas particulier. Il imprime True et l'a fait sur chaque version du cadre avec lequel je l'ai testé. (Je ne l'ai pas essayé sur Mono, certes ...)

Juste pour être clair, ce n'est qu'un exemple du genre de chose que je recherche - je ne cherchais pas particulièrement une discussion / explication de cette bizarrerie. (Ce n'est pas la même chose que l'internement de chaîne normal; en particulier, l'internement de chaîne ne se produit normalement pas lorsqu'un constructeur est appelé.) Je demandais vraiment un comportement étrange similaire.

D'autres joyaux se cachent là-bas?

Je pense que je vous ai montré celui-ci auparavant, mais j'aime le plaisir ici - cela a pris un peu de débogage pour retrouver! (le code d'origine était évidemment plus complexe et subtil ...)

    static void Foo<T>() where T : new()
    {
        T t = new T();
        Console.WriteLine(t.ToString()); // works fine
        Console.WriteLine(t.GetHashCode()); // works fine
        Console.WriteLine(t.Equals(t)); // works fine

        // so it looks like an object and smells like an object...

        // but this throws a NullReferenceException...
        Console.WriteLine(t.GetType());
    }

Alors, quel était T ...

Réponse: tout Nullable<T>- comme int?. Toutes les méthodes sont remplacées, sauf GetType () qui ne peut pas l'être; il est donc converti (encadré) en objet (et donc en null) pour appeler object.GetType () ... qui appelle null ;-p

Mise à jour: l'intrigue s'épaissit ... Ayende Rahien a lancé un défi similaire sur son blog , mais avec where T : class, new():

private static void Main() {
    CanThisHappen<MyFunnyType>();
}

public static void CanThisHappen<T>() where T : class, new() {
    var instance = new T(); // new() on a ref-type; should be non-null, then
    Debug.Assert(instance != null, "How did we break the CLR?");
}

Mais il peut être vaincu! Utiliser la même indirection utilisée par des choses comme la télécommande; avertissement - ce qui suit est du mal pur :

class MyFunnyProxyAttribute : ProxyAttribute {
    public override MarshalByRefObject CreateInstance(Type serverType) {
        return null;
    }
}
[MyFunnyProxy]
class MyFunnyType : ContextBoundObject { }

Avec cela en place, l' new()appel est redirigé vers le proxy ( MyFunnyProxyAttribute), qui revient null. Maintenant va te laver les yeux!

Arrondissement des banquiers.

Celui-ci n'est pas tant un bug ou un dysfonctionnement du compilateur, mais certainement un cas étrange ...

Le .Net Framework utilise un schéma ou un arrondi connu sous le nom d'arrondi bancaire.

Dans l'arrondi des banquiers, les 0,5 sont arrondis au nombre pair le plus proche, donc

Math.Round(-0.5) == 0
Math.Round(0.5) == 0
Math.Round(1.5) == 2
Math.Round(2.5) == 2
etc...

Cela peut entraîner des bogues inattendus dans les calculs financiers basés sur l'arrondi arrondi plus connu.

Cela est également vrai pour Visual Basic.

Que fera cette fonction si elle est appelée as Rec(0)(pas sous le débogueur)?

static void Rec(int i)
{
    Console.WriteLine(i);
    if (i < int.MaxValue)
    {
        Rec(i + 1);
    }
}

Répondre:

• Sur JIT 32 bits, cela devrait entraîner une exception StackOverflowException
• Sur JIT 64 bits, il devrait imprimer tous les nombres dans int.MaxValue

En effet, le compilateur JIT 64 bits applique l'optimisation des appels de queue , contrairement au JIT 32 bits.

Malheureusement, je n'ai pas de machine 64 bits à portée de main pour vérifier cela, mais la méthode remplit toutes les conditions pour l'optimisation des appels de queue. Si quelqu'un en a un, je serais intéressé de voir si c'est vrai.

Attribuez ceci!

C'est celui que j'aime demander lors des fêtes (c'est probablement pourquoi je ne suis plus invité):

Pouvez-vous compiler le morceau de code suivant?

    public void Foo()
    {
        this = new Teaser();
    }

Une triche simple pourrait être:

string cheat = @"
    public void Foo()
    {
        this = new Teaser();
    }
";

Mais la vraie solution est la suivante:

public struct Teaser
{
    public void Foo()
    {
        this = new Teaser();
    }
}

C'est donc un fait peu connu que les types de valeurs (structs) peuvent réaffecter leur thisvariable.

Il y a quelques années, lorsque nous travaillions sur un programme de fidélité, nous avions un problème avec le nombre de points accordés aux clients. Le problème était lié à la conversion / conversion double en int.

Dans le code ci-dessous:

double d = 13.6;

int i1 = Convert.ToInt32(d);
int i2 = (int)d;

est-ce que i1 == i2 ?

Il s'avère que i1! = I2. En raison des différentes politiques d'arrondi dans Convertir et convertir l'opérateur, les valeurs réelles sont les suivantes:

i1 == 14
i2 == 13

Il est toujours préférable d'appeler Math.Ceiling () ou Math.Floor () (ou Math.Round avec MidpointRounding qui répond à nos exigences)

int i1 = Convert.ToInt32( Math.Ceiling(d) );
int i2 = (int) Math.Ceiling(d);

Ils auraient dû faire de 0 un entier même en cas de surcharge de la fonction enum.

Je connaissais la raison d'être de l'équipe de base C # pour mapper le 0 à l'énumération, mais tout de même, ce n'est pas aussi orthogonal qu'il devrait l'être. Exemple de Npgsql .

Exemple de test:

namespace Craft
{
    enum Symbol { Alpha = 1, Beta = 2, Gamma = 3, Delta = 4 };


   class Mate
    {
        static void Main(string[] args)
        {

            JustTest(Symbol.Alpha); // enum
            JustTest(0); // why enum
            JustTest((int)0); // why still enum

            int i = 0;

            JustTest(Convert.ToInt32(0)); // have to use Convert.ToInt32 to convince the compiler to make the call site use the object version

            JustTest(i); // it's ok from down here and below
            JustTest(1);
            JustTest("string");
            JustTest(Guid.NewGuid());
            JustTest(new DataTable());

            Console.ReadLine();
        }

        static void JustTest(Symbol a)
        {
            Console.WriteLine("Enum");
        }

        static void JustTest(object o)
        {
            Console.WriteLine("Object");
        }
    }
}

C'est l'un des plus inhabituels que j'ai vus jusqu'à présent (à part ceux ici bien sûr!):

public class Turtle<T> where T : Turtle<T>
{
}

Il vous permet de le déclarer mais n'a aucune utilité réelle, car il vous demandera toujours d'envelopper la classe que vous remplissez au centre avec une autre tortue.

[blague] Je suppose que ce sont des tortues tout le long ... [/ blague]

En voici un que je n'ai découvert que récemment ...

interface IFoo
{
   string Message {get;}
}
...
IFoo obj = new IFoo("abc");
Console.WriteLine(obj.Message);

Les regards au- dessus fou au premier coup d' œil, mais est en réalité juridique .Aucun, vraiment (même si je l' ai manqué un élément clé, mais ce n'est pas quelque chose comme aki « ajouter une classe appelée IFoo» ou « ajouter un usingalias à un point IFooà un classe").

Voyez si vous pouvez comprendre pourquoi, alors: Qui a dit que vous ne pouvez pas instancier une interface?

Quand un booléen n'est-il ni vrai ni faux?

Bill a découvert que vous pouvez pirater un booléen de sorte que si A est vrai et B est vrai, (A et B) est faux.

Booléens piratés

J'arrive un peu tard pour la fête, mais j'ai trois quatre cinq:

1. Si vous interrogez InvokeRequired sur un contrôle qui n'a pas été chargé / affiché, il dira false - et explosera dans votre visage si vous essayez de le changer à partir d'un autre thread ( la solution est de faire référence à cela. Manipulez le créateur du contrôle).

2. Un autre qui m'a fait trébucher, c'est que, étant donné un montage avec:

   enum MyEnum
   {
       Red,
       Blue,
   }

   si vous calculez MyEnum.Red.ToString () dans un autre assembly, et entre temps, quelqu'un a recompilé votre énumération pour:

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }

   à l'exécution, vous obtiendrez "Black".

3. J'avais un assemblage partagé avec quelques constantes pratiques. Mon prédécesseur avait laissé une charge de propriétés get-look d'apparence laide, je pensais que je me débarrasserais de l'encombrement et utiliserais simplement const public. J'ai été plus qu'un peu surpris lorsque VS les a compilés à leurs valeurs, et non à des références.

4. Si vous implémentez une nouvelle méthode d'une interface à partir d'un autre assembly, mais que vous reconstruisez en référençant l'ancienne version de cet assembly, vous obtenez une TypeLoadException (pas d'implémentation de 'NewMethod'), même si vous l' avez implémentée (voir ici ).

5. Dictionnaire <,>: "L'ordre dans lequel les articles sont retournés n'est pas défini". C'est horrible , car cela peut parfois vous mordre, mais travailler les autres, et si vous venez de supposer aveuglément que Dictionary va jouer bien ("pourquoi ne le ferait-il pas? Je pensais, List fait"), vous devez vraiment ayez le nez dedans avant de commencer enfin à remettre en question votre hypothèse.

VB.NET, nullables et l'opérateur ternaire:

Dim i As Integer? = If(True, Nothing, 5)

Cela m'a pris un certain temps pour déboguer, car je m'attendais ià contenir Nothing.

Que dois-je vraiment contenir? 0.

C'est un comportement surprenant mais en fait "correct": Nothingdans VB.NET n'est pas exactement le même que nulldans CLR: Nothingpeut signifier nullou default(T)pour un type de valeur T, selon le contexte. Dans le cas ci-dessus, Ifdéduit Integercomme le type commun de, Nothinget 5donc, dans ce cas, Nothingsignifie 0.

J'ai trouvé une deuxième valise de coin vraiment étrange qui bat la première de loin.

La méthode String.Equals (String, String, StringComparison) n'est pas sans effet secondaire.

Je travaillais sur un bloc de code qui avait ceci sur une ligne à part en haut d'une fonction:

stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);

La suppression de cette ligne entraîne un débordement de pile ailleurs dans le programme.

Le code s'est avéré installer un gestionnaire pour ce qui était essentiellement un événement BeforeAssemblyLoad et essayer de le faire

if (assemblyfilename.EndsWith("someparticular.dll", StringComparison.InvariantCultureIgnoreCase))
{
    assemblyfilename = "someparticular_modified.dll";
}

Maintenant, je ne devrais pas avoir à vous le dire. L'utilisation d'une culture qui n'a pas été utilisée auparavant dans une comparaison de chaînes provoque une charge d'assembly. InvariantCulture ne fait pas exception à cette règle.

Voici un exemple de la façon dont vous pouvez créer une structure qui provoque le message d'erreur "Vous avez tenté de lire ou d'écrire de la mémoire protégée. Cela indique souvent qu'une autre mémoire est corrompue". La différence entre le succès et l'échec est très subtile.

Le test unitaire suivant illustre le problème.

Voyez si vous pouvez déterminer ce qui n'a pas fonctionné.

    [Test]
    public void Test()
    {
        var bar = new MyClass
        {
            Foo = 500
        };
        bar.Foo += 500;

        Assert.That(bar.Foo.Value.Amount, Is.EqualTo(1000));
    }

    private class MyClass
    {
        public MyStruct? Foo { get; set; }
    }

    private struct MyStruct
    {
        public decimal Amount { get; private set; }

        public MyStruct(decimal amount) : this()
        {
            Amount = amount;
        }

        public static MyStruct operator +(MyStruct x, MyStruct y)
        {
            return new MyStruct(x.Amount + y.Amount);
        }

        public static MyStruct operator +(MyStruct x, decimal y)
        {
            return new MyStruct(x.Amount + y);
        }

        public static implicit operator MyStruct(int value)
        {
            return new MyStruct(value);
        }

        public static implicit operator MyStruct(decimal value)
        {
            return new MyStruct(value);
        }
    }

C # prend en charge les conversions entre les tableaux et les listes tant que les tableaux ne sont pas multidimensionnels et qu'il existe une relation d'héritage entre les types et que les types sont des types de référence

object[] oArray = new string[] { "one", "two", "three" };
string[] sArray = (string[])oArray;

// Also works for IList (and IEnumerable, ICollection)
IList<string> sList = (IList<string>)oArray;
IList<object> oList = new string[] { "one", "two", "three" };

Notez que cela ne fonctionne pas:

object[] oArray2 = new int[] { 1, 2, 3 }; // Error: Cannot implicitly convert type 'int[]' to 'object[]'
int[] iArray = (int[])oArray2;            // Error: Cannot convert type 'object[]' to 'int[]'

C'est le plus étrange que j'ai rencontré par accident:

public class DummyObject
{
    public override string ToString()
    {
        return null;
    }
}

Utilisé comme suit:

DummyObject obj = new DummyObject();
Console.WriteLine("The text: " + obj.GetType() + " is " + obj);

Jettera un NullReferenceException. Il s'avère que les ajouts multiples sont compilés par le compilateur C # pour un appel à String.Concat(object[]). Avant .NET 4, il y a un bogue dans cette surcharge de Concat où l'objet est vérifié pour null, mais pas le résultat de ToString ():

object obj2 = args[i];
string text = (obj2 != null) ? obj2.ToString() : string.Empty;
// if obj2 is non-null, but obj2.ToString() returns null, then text==null
int length = text.Length;

Il s'agit d'un bogue d'ECMA-334 §14.7.4:

L'opérateur binaire + effectue la concaténation de chaînes lorsqu'un ou les deux opérandes sont de type string. Si un opérande de concaténation de chaînes est null, une chaîne vide est substituée. Sinon, tout opérande non chaîne est converti en sa représentation chaîne en appelant la ToStringméthode virtuelle héritée de type object. Si ToStringretourne null, une chaîne vide est substituée.

Intéressant - quand j'ai regardé pour la première fois, j'ai supposé que c'était quelque chose que le compilateur C # vérifiait, mais même si vous émettez l'IL directement pour supprimer toute chance d'interférence, cela se produit toujours, ce qui signifie que c'est vraiment le newobjcode op qui fait le vérification.

var method = new DynamicMethod("Test", null, null);
var il = method.GetILGenerator();

il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));

il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));

il.Emit(OpCodes.Call, typeof(object).GetMethod("ReferenceEquals"));
il.Emit(OpCodes.Box, typeof(bool));
il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new[] { typeof(object) }));

il.Emit(OpCodes.Ret);

method.Invoke(null, null);

Cela équivaut également à truesi vous vérifiez string.Emptyce qui signifie que cet op-code doit avoir un comportement spécial pour interner des chaînes vides.

Public Class Item
   Public ID As Guid
   Public Text As String

   Public Sub New(ByVal id As Guid, ByVal name As String)
      Me.ID = id
      Me.Text = name
   End Sub
End Class

Public Sub Load(sender As Object, e As EventArgs) Handles Me.Load
   Dim box As New ComboBox
   Me.Controls.Add(box)          'Sorry I forgot this line the first time.'
   Dim h As IntPtr = box.Handle  'Im not sure you need this but you might.'
   Try
      box.Items.Add(New Item(Guid.Empty, Nothing))
   Catch ex As Exception
      MsgBox(ex.ToString())
   End Try
End Sub

La sortie est "Tentative de lecture de la mémoire protégée. Ceci indique que l'autre mémoire est corrompue."

PropertyInfo.SetValue () peut affecter des entiers à des énumérations, des entiers à des octets nullables, des énumérations à des énumérations nullables, mais pas des entiers à des énumérations nullables.

enumProperty.SetValue(obj, 1, null); //works
nullableIntProperty.SetValue(obj, 1, null); //works
nullableEnumProperty.SetValue(obj, MyEnum.Foo, null); //works
nullableEnumProperty.SetValue(obj, 1, null); // throws an exception !!!

Description complète ici

Et si vous avez une classe générique qui a des méthodes qui peuvent être rendues ambiguës en fonction des arguments de type? J'ai rencontré cette situation récemment en écrivant un dictionnaire bidirectionnel. Je voulais écrire des Get()méthodes symétriques qui retourneraient l'opposé de tout argument passé. Quelque chose comme ça:

class TwoWayRelationship<T1, T2>
{
    public T2 Get(T1 key) { /* ... */ }
    public T1 Get(T2 key) { /* ... */ }
}

Tout va bien si vous créez une instance où T1et T2sont de types différents:

var r1 = new TwoWayRelationship<int, string>();
r1.Get(1);
r1.Get("a");

Mais si T1et T2sont les mêmes (et probablement si l'un était une sous-classe d'un autre), c'est une erreur de compilation:

var r2 = new TwoWayRelationship<int, int>();
r2.Get(1);  // "The call is ambiguous..."

Fait intéressant, toutes les autres méthodes dans le deuxième cas sont encore utilisables; ce ne sont que des appels à la méthode désormais ambiguë qui provoque une erreur de compilation. Cas intéressant, quoique peu probable et obscur.

C # Accessibilité Puzzler

La classe dérivée suivante accède à un champ privé à partir de sa classe de base et le compilateur regarde silencieusement de l'autre côté:

public class Derived : Base
{
    public int BrokenAccess()
    {
        return base.m_basePrivateField;
    }
}

Le domaine est en effet privé:

private int m_basePrivateField = 0;

Voulez-vous deviner comment nous pouvons compiler un tel code?

.

.

.

.

.

.

.

Répondre

L'astuce consiste à déclarer en Derivedtant que classe interne de Base:

public class Base
{
    private int m_basePrivateField = 0;

    public class Derived : Base
    {
        public int BrokenAccess()
        {
            return base.m_basePrivateField;
        }
    }
}

Les classes internes ont un accès complet aux membres de la classe externe. Dans ce cas, la classe interne dérive également de la classe externe. Cela nous permet de "casser" l'encapsulation des membres privés.

Je viens de trouver une jolie petite chose aujourd'hui:

public class Base
{
   public virtual void Initialize(dynamic stuff) { 
   //...
   }
}
public class Derived:Base
{
   public override void Initialize(dynamic stuff) {
   base.Initialize(stuff);
   //...
   }
}

Cela génère une erreur de compilation.

L'appel à la méthode 'Initialize' doit être distribué dynamiquement, mais ne peut pas l'être car il fait partie d'une expression d'accès de base. Pensez à transtyper les arguments dynamiques ou à supprimer l'accès de base.

Si j'écris base.Initialize (en tant qu'objet); cela fonctionne parfaitement, mais cela semble être un "mot magique" ici, car il fait exactement la même chose, tout est toujours reçu comme dynamique ...

Dans une API que nous utilisons, les méthodes qui renvoient un objet de domaine peuvent renvoyer un "objet nul" spécial. Dans l'implémentation de ceci, l'opérateur de comparaison et la Equals()méthode sont remplacés pour retourner trues'ils sont comparés ànull .

Un utilisateur de cette API peut donc avoir du code comme celui-ci:

return test != null ? test : GetDefault();

ou peut-être un peu plus verbeux, comme ceci:

if (test == null)
    return GetDefault();
return test;

où GetDefault()est une méthode renvoyant une valeur par défaut que nous voulons utiliser à la place null. La surprise m'a frappé lorsque j'utilisais ReSharper et que je vous recommande de réécrire l'une ou l'autre de ces options comme suit:

return test ?? GetDefault();

Si l'objet de test est un objet nul renvoyé par l'API au lieu d'un objet approprié null, le comportement du code a maintenant changé, car l'opérateur de coalescence null vérifie réellement null, sans exécuter operator=ou Equals().

Considérez ce cas étrange:

public interface MyInterface {
  void Method();
}
public class Base {
  public void Method() { }
}
public class Derived : Base, MyInterface { }

Si Baseet Derivedsont déclarés dans le même assembly, le compilateur rendra Base::Methodvirtuel et scellé (dans le CIL), même siBase n'implémente pas l'interface.

Si Baseet Derivedsont dans des assemblys différents, lors de la compilation de l' Derivedassembly, le compilateur ne changera pas l'autre assembly, donc il introduira un membre dans Derivedce sera une implémentation explicite car MyInterface::Methodil déléguera simplement l'appel à Base::Method.

Le compilateur doit le faire pour prendre en charge la répartition polymorphe en ce qui concerne l'interface, c'est-à-dire qu'il doit rendre cette méthode virtuelle.

Ce qui suit pourrait être des connaissances générales qui me manquaient, mais hein. Il y a quelque temps, nous avions un cas de bogue qui comprenait des propriétés virtuelles. Résumant un peu le contexte, considérez le code suivant et appliquez le point d'arrêt à la zone spécifiée:

class Program
{
    static void Main(string[] args)
    {
        Derived d = new Derived();
        d.Property = "AWESOME";
    }
}

class Base
{
    string _baseProp;
    public virtual string Property 
    { 
        get 
        {
            return "BASE_" + _baseProp;
        }
        set
        {
            _baseProp = value;
            //do work with the base property which might 
            //not be exposed to derived types
            //here
            Console.Out.WriteLine("_baseProp is BASE_" + value.ToString());
        }
    }
}

class Derived : Base
{
    string _prop;
    public override string Property 
    {
        get { return _prop; }
        set 
        { 
            _prop = value; 
            base.Property = value;
        } //<- put a breakpoint here then mouse over BaseProperty, 
          //   and then mouse over the base.Property call inside it.
    }

    public string BaseProperty { get { return base.Property; } private set { } }
}

Dans le Derivedcontexte de l' objet, vous pouvez obtenir le même comportement lors de l'ajout en base.Propertytant que montre ou de la saisie base.Propertydans la montre rapide.

Cela m'a pris un peu de temps pour réaliser ce qui se passait. Au final, j'ai été éclairé par la Quickwatch. Lorsque vous accédez à la Quickwatch et explorez l' Derivedobjet d (ou à partir du contexte de l'objet this) et sélectionnez le champ base, le champ d'édition en haut de la Quickwatch affiche la distribution suivante:

((TestProject1.Base)(d))

Ce qui signifie que si la base est remplacée en tant que telle, l'appel serait

public string BaseProperty { get { return ((TestProject1.Base)(d)).Property; } private set { } }

pour les montres, Quickwatch et les info-bulles de débogage de la souris, et il serait alors logique qu'il s'affiche "AWESOME"au lieu de "BASE_AWESOME"considérer le polymorphisme. Je ne sais toujours pas pourquoi cela le transformerait en distribution, une hypothèse est que cela callpourrait ne pas être disponible dans le contexte de ces modules, et seulementcallvirt .

Quoi qu'il en soit, cela ne change évidemment rien en termes de fonctionnalités, cela Derived.BasePropertyreviendra toujours vraiment "BASE_AWESOME", et donc ce n'était pas la racine de notre bogue au travail, simplement un composant déroutant. J'ai toutefois trouvé intéressant de voir comment cela pouvait induire les développeurs en erreur qui ne le Basesauraient pas lors de leurs sessions de débogage, en particulier s'il n'est pas exposé dans votre projet mais plutôt référencé comme une DLL tierce, ce qui fait que les développeurs disent simplement:

"Oi, wait..what? Omg que DLL est comme, .. faisant quelque chose de drôle"

Celui-ci est assez difficile à surpasser. Je suis tombé dessus alors que j'essayais de construire une implémentation RealProxy qui prend vraiment en charge Begin / EndInvoke (merci MS pour avoir rendu cela impossible à faire sans horribles hacks). Cet exemple est essentiellement un bogue dans le CLR, le chemin de code non géré pour BeginInvoke ne valide pas que le message de retour de RealProxy.PrivateInvoke (et mon remplacement Invoke) renvoie une instance d'un IAsyncResult. Une fois qu'il est retourné, le CLR devient incroyablement confus et perd toute idée de ce qui se passe, comme le montrent les tests en bas.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Proxies;
using System.Reflection;
using System.Runtime.Remoting.Messaging;

namespace BrokenProxy
{
    class NotAnIAsyncResult
    {
        public string SomeProperty { get; set; }
    }

    class BrokenProxy : RealProxy
    {
        private void HackFlags()
        {
            var flagsField = typeof(RealProxy).GetField("_flags", BindingFlags.NonPublic | BindingFlags.Instance);
            int val = (int)flagsField.GetValue(this);
            val |= 1; // 1 = RemotingProxy, check out System.Runtime.Remoting.Proxies.RealProxyFlags
            flagsField.SetValue(this, val);
        }

        public BrokenProxy(Type t)
            : base(t)
        {
            HackFlags();
        }

        public override IMessage Invoke(IMessage msg)
        {
            var naiar = new NotAnIAsyncResult();
            naiar.SomeProperty = "o noes";
            return new ReturnMessage(naiar, null, 0, null, (IMethodCallMessage)msg);
        }
    }

    interface IRandomInterface
    {
        int DoSomething();
    }

    class Program
    {
        static void Main(string[] args)
        {
            BrokenProxy bp = new BrokenProxy(typeof(IRandomInterface));
            var instance = (IRandomInterface)bp.GetTransparentProxy();
            Func<int> doSomethingDelegate = instance.DoSomething;
            IAsyncResult notAnIAsyncResult = doSomethingDelegate.BeginInvoke(null, null);

            var interfaces = notAnIAsyncResult.GetType().GetInterfaces();
            Console.WriteLine(!interfaces.Any() ? "No interfaces on notAnIAsyncResult" : "Interfaces");
            Console.WriteLine(notAnIAsyncResult is IAsyncResult); // Should be false, is it?!
            Console.WriteLine(((NotAnIAsyncResult)notAnIAsyncResult).SomeProperty);
            Console.WriteLine(((IAsyncResult)notAnIAsyncResult).IsCompleted); // No way this works.
        }
    }
}

Production:

No interfaces on notAnIAsyncResult
True
o noes

Unhandled Exception: System.EntryPointNotFoundException: Entry point was not found.
   at System.IAsyncResult.get_IsCompleted()
   at BrokenProxy.Program.Main(String[] args) 

Je ne sais pas si vous diriez que c'est une bizarrerie de Windows Vista / 7 ou une bizarrerie .Net mais cela m'a fait me gratter la tête pendant un certain temps.

string filename = @"c:\program files\my folder\test.txt";
System.IO.File.WriteAllText(filename, "Hello world.");
bool exists = System.IO.File.Exists(filename); // returns true;
string text = System.IO.File.ReadAllText(filename); // Returns "Hello world."

Sous Windows Vista / 7, le fichier sera réellement écrit dans C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt

Avez-vous déjà pensé que le compilateur C # pourrait générer un CIL non valide? Exécutez ceci et vous obtiendrez TypeLoadException:

interface I<T> {
  T M(T p);
}
abstract class A<T> : I<T> {
  public abstract T M(T p);
}
abstract class B<T> : A<T>, I<int> {
  public override T M(T p) { return p; }
  public int M(int p) { return p * 2; }
}
class C : B<int> { }

class Program {
  static void Main(string[] args) {
    Console.WriteLine(new C().M(42));
  }
}

Je ne sais pas cependant comment cela se passe dans le compilateur C # 4.0.

EDIT : c'est la sortie de mon système:

C:\Temp>type Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1 {

  interface I<T> {
    T M(T p);
  }
  abstract class A<T> : I<T> {
    public abstract T M(T p);
  }
  abstract class B<T> : A<T>, I<int> {
    public override T M(T p) { return p; }
    public int M(int p) { return p * 2; }
  }
  class C : B<int> { }

  class Program {
    static void Main(string[] args) {
      Console.WriteLine(new C().M(11));
    }
  }

}
C:\Temp>csc Program.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.


C:\Temp>Program

Unhandled Exception: System.TypeLoadException: Could not load type 'ConsoleAppli
cation1.C' from assembly 'Program, Version=0.0.0.0, Culture=neutral, PublicKeyTo
ken=null'.
   at ConsoleApplication1.Program.Main(String[] args)

C:\Temp>peverify Program.exe

Microsoft (R) .NET Framework PE Verifier.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

[token  0x02000005] Type load failed.
[IL]: Error: [C:\Temp\Program.exe : ConsoleApplication1.Program::Main][offset 0x
00000001] Unable to resolve token.
2 Error(s) Verifying Program.exe

C:\Temp>ver

Microsoft Windows XP [Version 5.1.2600]

Il y a quelque chose de vraiment excitant dans C #, la façon dont il gère les fermetures.

Au lieu de copier les valeurs de la variable de pile dans la variable libre de fermeture, il fait que la magie du préprocesseur enveloppe toutes les occurrences de la variable dans un objet et la déplace ainsi hors de la pile - directement dans le tas! :)

Je suppose que cela rend le langage C # encore plus fonctionnel (ou lambda-complet hein)) que ML lui-même (qui utilise la copie de valeur de pile AFAIK). F # a également cette fonctionnalité, comme C #.

Cela m'apporte beaucoup de plaisir, merci les gars MS!

Ce n'est pas un cas étrange ou un coin ... mais quelque chose de vraiment inattendu à partir d'un langage de machine virtuelle basé sur la pile :)

D'une question que j'ai posée il n'y a pas longtemps:

L'opérateur conditionnel ne peut pas transtyper implicitement?

Donné:

Bool aBoolValue;

Où aBoolValueest attribué Vrai ou Faux;

Les éléments suivants ne seront pas compilés:

Byte aByteValue = aBoolValue ? 1 : 0;

Mais cela:

Int anIntValue = aBoolValue ? 1 : 0;

La réponse fournie est également très bonne.

La portée en c # est parfois vraiment bizarre. Permettez-moi de vous donner un exemple:

if (true)
{
   OleDbCommand command = SQLServer.CreateCommand();
}

OleDbCommand command = SQLServer.CreateCommand();

Cela ne parvient pas à compiler, car la commande est redéclarée? Il y a des conjectures intéressées quant à pourquoi cela fonctionne de cette façon dans ce fil sur stackoverflow et dans mon blog .