¿Cuál es el caso de esquina más extraño que has visto en C # o .NET? [cerrado]

Colecciono algunos casos de esquina y rompecabezas y siempre me gustaría escuchar más. La página solo cubre bits y bobs del lenguaje C #, pero también me parecen interesantes las cosas principales de .NET. Por ejemplo, aquí hay uno que no está en la página, pero que me parece increíble:

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

Esperaría que eso imprima False: después de todo, "nuevo" (con un tipo de referencia) siempre crea un nuevo objeto, ¿no? Las especificaciones para C # y la CLI indican que debería. Bueno, no en este caso particular. Imprime True, y lo ha hecho en todas las versiones del marco con el que lo he probado. (No lo he probado en Mono, lo admito ...)

Para ser claros, este es solo un ejemplo del tipo de cosas que estoy buscando: no estaba buscando una discusión / explicación de esta rareza. (No es lo mismo que el internamiento de cadena normal; en particular, el internamiento de cadena normalmente no ocurre cuando se llama a un constructor). Realmente estaba pidiendo un comportamiento extraño similar.

¿Alguna otra gema al acecho?

Creo que te mostré esto antes, pero me gusta la diversión aquí, ¡esto requirió un poco de depuración para localizarlo! (el código original era obviamente más complejo y sutil ...)

    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());
    }

Entonces, ¿qué era T ...

Respuesta: cualquiera Nullable<T>, como int?. Todos los métodos se anulan, excepto GetType () que no puede ser; por lo que se convierte (en caja) al objeto (y, por lo tanto, a nulo) para llamar a object.GetType () ... que llama a nulo ;-p

Actualización: la trama se complica ... Ayende Rahien lanzó un desafío similar en su blog , pero con un 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?");
}

¡Pero puede ser derrotado! Usando la misma indirección utilizada por cosas como la comunicación remota; advertencia: lo siguiente es puro mal :

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

Con esto en su lugar, la new()llamada se redirige al proxy ( MyFunnyProxyAttribute), que regresa null. ¡Ahora ve y lávate los ojos!

Redondeo de los banqueros.

Este no es tanto un error o mal funcionamiento del compilador, sino ciertamente un extraño caso de esquina ...

.Net Framework emplea un esquema o redondeo conocido como redondeo bancario.

En el redondeo de los banqueros, los números 0.5 se redondean al número par más cercano, entonces

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

Esto puede conducir a algunos errores inesperados en los cálculos financieros basados ​​en el redondeo Round-Half-Up más conocido.

Esto también es cierto de Visual Basic.

¿Qué hará esta función si se llama como Rec(0)(no bajo el depurador)?

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

Responder:

• En JIT de 32 bits, debería producir una StackOverflowException
• En JIT de 64 bits, debe imprimir todos los números en int.MaxValue

Esto se debe a que el compilador JIT de 64 bits aplica la optimización de llamada de cola , mientras que el JIT de 32 bits no.

Desafortunadamente, no tengo una máquina de 64 bits a mano para verificar esto, pero el método cumple con todas las condiciones para la optimización de llamadas de cola. Si alguien tiene uno, me interesaría ver si es verdad.

¡Asigna esto!

Esta es una que me gusta preguntar en las fiestas (que probablemente sea la razón por la que ya no me invitan):

¿Puedes hacer la siguiente compilación de código?

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

Un truco fácil podría ser:

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

Pero la verdadera solución es esta:

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

Por lo tanto, es un hecho poco conocido que los tipos de valor (estructuras) pueden reasignar sus thisvariables.

Hace unos años, cuando trabajábamos en un programa de lealtad, tuvimos un problema con la cantidad de puntos otorgados a los clientes. El problema estaba relacionado con la conversión / conversión de double a int.

En el código a continuación:

double d = 13.6;

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

¿i1 == i2 ?

Resulta que i1! = I2. Debido a las diferentes políticas de redondeo en el operador Convertir y emitir, los valores reales son:

i1 == 14
i2 == 13

Siempre es mejor llamar a Math.Ceiling () o Math.Floor () (o Math.Round con MidpointRounding que cumple con nuestros requisitos)

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

Deberían haber hecho 0 un número entero incluso cuando hay una sobrecarga de la función enum.

Conocía la razón fundamental del equipo de C # para asignar 0 a enum, pero aún así, no es tan ortogonal como debería ser. Ejemplo de Npgsql .

Ejemplo de prueba:

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");
        }
    }
}

Este es uno de los más inusuales que he visto hasta ahora (¡aparte de los que están aquí, por supuesto!):

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

Te permite declararlo, pero no tiene ningún uso real, ya que siempre te pedirá que envuelvas cualquier clase en el centro con otra tortuga.

[broma] Supongo que son tortugas hasta el fondo ... [/ broma]

Aquí hay uno que descubrí recientemente ...

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

Lo anterior parece una locura a primera vista, pero en realidad es legal. No, de verdad (aunque me he perdido una parte clave, pero no es nada obsceno como "agregar una clase llamada IFoo" o "agregar un usingalias para señalarIFoo un clase").

Vea si puede descubrir por qué, entonces: ¿Quién dice que no puede crear una instancia de una interfaz?

¿Cuándo un booleano no es verdadero ni falso?

Bill descubrió que puedes hackear un booleano para que si A es Verdadero y B sea Verdadero, (A y B) sea Falso.

Booleanos pirateados

Llego un poco tarde a la fiesta, pero tengo tres cuatro cinco:

1. Si sondea InvokeRequired en un control que no se ha cargado / mostrado, dirá falso y explotará en tu cara si intentas cambiarlo desde otro hilo ( la solución es hacer referencia a esto. Manejar en el creador del controlar).

2. Otro que me hizo tropezar es que, dada una asamblea con:

   enum MyEnum
   {
       Red,
       Blue,
   }

   si calcula MyEnum.Red.ToString () en otro ensamblado, y en algún momento alguien ha vuelto a compilar su enumeración para:

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }

   en tiempo de ejecución, obtendrás "Black".

3. Tenía un ensamblaje compartido con algunas constantes útiles. Mi predecesor había dejado una carga de propiedades de solo obtener feo, pensé en deshacerme del desorden y simplemente usar const público. Estaba más que un poco sorprendido cuando VS los compiló con sus valores, y no con referencias.

4. Si implementa un nuevo método de una interfaz desde otro ensamblaje, pero reconstruye haciendo referencia a la versión anterior de ese ensamblaje, obtiene una excepción TypeLoadException (sin implementación de 'NewMethod'), aunque la haya implementado (consulte aquí ).

5. Diccionario <,>: "El orden en que se devuelven los elementos no está definido". Esto es horrible , porque a veces puede morderte, pero trabajar en otros, y si has asumido ciegamente que Dictionary va a jugar bien ("¿por qué no debería? Pensé, List lo hace"), realmente tienes que hacerlo tenga la nariz puesta antes de que finalmente comience a cuestionar su suposición.

VB.NET, nulables y el operador ternario:

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

Esto me llevó algún tiempo depurar, ya que esperaba icontenerNothing .

¿Qué contengo realmente? 0.

Esto es sorprendente, pero en realidad es un comportamiento "correcto": Nothingen VB.NET no es exactamente lo mismo que nullen CLR: Nothingpuede significar nullo default(T)para un tipo de valor T, dependiendo del contexto. En el caso anterior, se Ifinfiere Integercomo el tipo común de Nothingy 5, por lo tanto, en este caso, Nothingsignifica 0.

Encontré un segundo caso de esquina realmente extraño que supera por mucho al primero.

El método String.Equals (String, String, StringComparison) no está libre de efectos secundarios.

Estaba trabajando en un bloque de código que tenía esto en una línea sola en la parte superior de alguna función:

stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);

Eliminar esa línea conduce a un desbordamiento de la pila en otro lugar del programa.

El código resultó estar instalando un controlador para lo que en esencia era un evento BeforeAssemblyLoad y tratando de hacer

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

Por ahora no debería tener que decírtelo. El uso de una cultura que no se haya usado antes en una comparación de cadenas provoca una carga de ensamblaje. InvariantCulture no es una excepción a esto.

Aquí hay un ejemplo de cómo puede crear una estructura que provoque el mensaje de error "Intentó leer o escribir memoria protegida. Esto es a menudo una indicación de que otra memoria está dañada". La diferencia entre el éxito y el fracaso es muy sutil.

La siguiente prueba de unidad demuestra el problema.

Vea si puede resolver lo que salió mal.

    [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 # admite conversiones entre matrices y listas, siempre que las matrices no sean multidimensionales y haya una relación de herencia entre los tipos y los tipos son tipos de referencia

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" };

Tenga en cuenta que esto no funciona:

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[]'

Esto es lo más extraño que he encontrado por accidente:

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

Usado de la siguiente manera:

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

Lanzará un NullReferenceException. Resulta que las múltiples adiciones son compiladas por el compilador de C # a una llamada a String.Concat(object[]). Antes de .NET 4, hay un error solo en esa sobrecarga de Concat donde el objeto se verifica para nulo, pero no el resultado 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;

Este es un error de ECMA-334 §14.7.4:

El operador binario + realiza la concatenación de cadenas cuando uno o ambos operandos son de tipo string. Si un operando de concatenación de cadenas es null, se sustituye una cadena vacía. De lo contrario, cualquier operando que no sea de cadena se convierte en su representación de cadena invocando el ToStringmétodo virtual heredado de type object. Si se ToStringdevuelve null, se sustituye una cadena vacía.

Interesante: cuando lo vi por primera vez, asumí que era algo que el compilador de C # estaba buscando, pero incluso si emites el IL directamente para eliminar cualquier posibilidad de interferencia, todavía sucede, lo que significa que realmente es el newobjcódigo operativo que está haciendo el comprobación.

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);

También equivale a truesi comprueba lo string.Emptyque significa que este código de operación debe tener un comportamiento especial para internar cadenas vacías.

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

El resultado es "Se intentó leer la memoria protegida. Esto es una indicación de que otra memoria está dañada".

PropertyInfo.SetValue () puede asignar entradas a enumeraciones, entradas a entradas anulables, enumeraciones a enumeraciones anulables, pero no entradas a enumeraciones anulables.

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 !!!

Descripción completa aquí

¿Qué sucede si tiene una clase genérica que tiene métodos que podrían hacerse ambiguos dependiendo de los argumentos de tipo? Me encontré con esta situación recientemente escribiendo un diccionario bidireccional. Quería escribir Get()métodos simétricos que devolvieran lo contrario de cualquier argumento que se pasara. Algo como esto:

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

Todo está bien si haces una instancia donde T1y T2son diferentes tipos:

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

Pero si T1y T2son lo mismo (y probablemente si uno era una subclase de otro), es un error del compilador:

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

Curiosamente, todos los demás métodos en el segundo caso todavía son utilizables; solo las llamadas al método ahora ambiguo causan un error del compilador. Caso interesante, aunque un poco improbable y oscuro.

Rompecabezas de accesibilidad C #

La siguiente clase derivada está accediendo a un campo privado desde su clase base, y el compilador mira silenciosamente hacia el otro lado:

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

El campo es de hecho privado:

private int m_basePrivateField = 0;

¿Te importaría adivinar cómo podemos compilar ese código?

.

.

.

.

.

.

.

Responder

El truco es declarar Derivedcomo una clase interna de Base:

public class Base
{
    private int m_basePrivateField = 0;

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

Las clases internas tienen acceso completo a los miembros de la clase externa. En este caso, la clase interna también deriva de la clase externa. Esto nos permite "romper" la encapsulación de miembros privados.

Acabo de encontrar una cosita linda hoy:

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

Esto arroja un error de compilación.

La llamada al método 'Inicializar' debe despacharse dinámicamente, pero no puede ser porque es parte de una expresión de acceso base. Considere lanzar los argumentos dinámicos o eliminar el acceso base.

Si escribo base.Initialize (cosas como objeto); funciona perfectamente, sin embargo, esta parece ser una "palabra mágica" aquí, ya que hace exactamente lo mismo, todo aún se recibe como dinámico ...

En una API que estamos usando, los métodos que devuelven un objeto de dominio pueden devolver un "objeto nulo" especial. En la implementación de esto, el operador de comparación y el Equals()método se anulan para devolver truesi se compara connull .

Entonces, un usuario de esta API podría tener un código como este:

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

o quizás un poco más detallado, como este:

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

donde GetDefault()es un método que devuelve algún valor predeterminado que queremos usar en lugar de null. La sorpresa me golpeó cuando estaba usando ReSharper y siguiendo su recomendación de reescribir cualquiera de estos a lo siguiente:

return test ?? GetDefault();

Si el objeto de prueba es un objeto nulo devuelto por la API en lugar de un apropiado null, el comportamiento del código ahora ha cambiado, ya que el operador de fusión nula realmente busca null, no se ejecuta operator=o no Equals().

Considere este caso extraño:

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

Si Basey Derivedse declaran en el mismo ensamblado, el compilador lo hará Base::Methodvirtual y sellado (en el CIL), aunque Baseno implemente la interfaz.

Si Basey Derivedestán en ensamblajes diferentes, al compilar el Derivedensamblaje, el compilador no cambiará el otro ensamblaje, por lo que introducirá un miembro Derivedque será una implementación explícita para MyInterface::Methodeso solo delegará la llamada aBase::Method .

El compilador debe hacer esto para admitir el envío polimórfico con respecto a la interfaz, es decir, debe hacer que ese método sea virtual.

Lo siguiente podría ser conocimiento general que simplemente me faltaba, pero eh. Hace algún tiempo, tuvimos un caso de error que incluía propiedades virtuales. Resumiendo un poco el contexto, considere el siguiente código y aplique el punto de interrupción al área especificada:

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 { } }
}

Mientras está en el Derivedcontexto del objeto, puede obtener el mismo comportamiento al agregar base.Propertycomo reloj o al escribir base.Propertyen el reloj rápido.

Me tomó un tiempo darme cuenta de lo que estaba pasando. Al final fui iluminado por el Quickwatch. Al ingresar al Quickwatch y explorar el Derivedobjeto d (o desde el contexto del objeto this) y seleccionar el campo base, el campo de edición en la parte superior del Quickwatch muestra el siguiente reparto:

((TestProject1.Base)(d))

Lo que significa que si la base se reemplaza como tal, la llamada sería

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

para los Watches, Quickwatch y la información sobre herramientas de depuración del mouse, y entonces tendría sentido que se muestre en "AWESOME"lugar de "BASE_AWESOME"cuando se considera el polimorfismo. Todavía no estoy seguro de por qué lo transformaría en un elenco, una hipótesis es que callpodría no estar disponible desde el contexto de esos módulos, y solo callvirt.

De todos modos, eso obviamente no altera nada en términos de funcionalidad, Derived.BasePropertytodavía volverá realmente "BASE_AWESOME", y por lo tanto, esta no fue la raíz de nuestro error en el trabajo, simplemente un componente confuso. Sin embargo, me pareció interesante cómo podría engañar a los desarrolladores que desconocen ese hecho durante sus sesiones de depuración, especialmente si Baseno se expone en su proyecto, sino que se hace referencia a él como un archivo DLL de terceros, lo que hace que los desarrolladores simplemente digan:

"Oi, espera ... ¿qué? Dios mío es como DLL, haciendo algo gracioso"

Este es bastante difícil de superar. Me encontré con él mientras intentaba construir una implementación RealProxy que realmente sea compatible con Begin / EndInvoke (gracias MS por hacer que esto sea imposible sin trucos horribles). Este ejemplo es básicamente un error en el CLR, la ruta de código no administrada para BeginInvoke no valida que el mensaje de retorno de RealProxy.PrivateInvoke (y mi anulación Invoke) está devolviendo una instancia de IAsyncResult. Una vez que se devuelve, el CLR se confunde increíblemente y pierde la idea de lo que está sucediendo, como lo demuestran las pruebas en la parte inferior.

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.
        }
    }
}

Salida:

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) 

No estoy seguro de si diría que esto es una rareza de Windows Vista / 7 o una rareza de .Net, pero me hizo rascarme la cabeza por un tiempo.

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."

En Windows Vista / 7, el archivo se escribirá realmente en C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt

¿Alguna vez pensó que el compilador de C # podría generar CIL no válido? Ejecute esto y obtendrá un 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));
  }
}

Sin embargo, no sé cómo le va en el compilador de C # 4.0.

EDITAR : esta es la salida de mi sistema:

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]

Hay algo realmente emocionante en C #, la forma en que maneja los cierres.

En lugar de copiar los valores de la variable de pila en la variable libre de cierre, hace que la magia del preprocesador envuelva todas las ocurrencias de la variable en un objeto y, por lo tanto, la saque de la pila, ¡directamente al montón! :)

Supongo que eso hace que C # sea aún más funcionalmente completo (o lambda-complete huh)) que el propio ML (que usa el valor de pila copiando AFAIK). F # también tiene esa característica, como lo hace C #.

Eso me alegra mucho, ¡gracias, muchachos de MS!

Sin embargo, no es un caso extraño o de esquina ... sino algo realmente inesperado de un lenguaje VM basado en pila :)

De una pregunta que hice hace poco:

¿El operador condicional no puede emitir implícitamente?

Dado:

Bool aBoolValue;

Dónde aBoolValue se le asigna Verdadero o Falso;

Lo siguiente no se compilará:

Byte aByteValue = aBoolValue ? 1 : 0;

Pero esto haría:

Int anIntValue = aBoolValue ? 1 : 0;

La respuesta proporcionada también es bastante buena.

El alcance en C # es realmente extraño a veces. Déjame darte un ejemplo:

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

OleDbCommand command = SQLServer.CreateCommand();

Esto no se compila, porque el comando se vuelve a declarar? Hay algunas conjeturas interesantes sobre por qué funciona de esa manera en este hilo en stackoverflow y en mi blog .