optimizar - obtener sistema operativo c#

¿C#4 optimiza los espacios de nombres de una manera que las versiones anteriores de C#no lo hicieron?

Question

Esta pregunta es por interés. Estoy trabajando con una biblioteca de terceros y encontré la siguiente documentación en una clase CMS.Security.Dummy :

NO BORRAR ESTA CLASE: esta clase evita que el compilador suelte el espacio de nombres completo en .NET 4.0.

¿Alguien sabe o puede alguien especular por qué .NET 4 eliminaría el espacio de nombres si se eliminara la clase ficticia?

Debido a que .NET 4 tiene un nombre explícito en el comentario del código fuente, asumo que las versiones anteriores de C # muestran un comportamiento que no requiere esta clase ficticia. Aunque eso es puramente especulativo.

Captura de pantalla

Código fuente descompilado

#region Assembly CMS.SettingsProvider.dll, v4.0.30319
// .../solution/wwwroot/Bin/CMS.SettingsProvider.dll
#endregion
using System;
namespace CMS.Security
{
// Summary:
// DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
// entire namespace under .NET 4.0.
public class Dummy
{
// Summary:
// DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
// entire namespace under .NET 4.0.
public Dummy();
}
}

Answer 1

Dado que el espacio de nombres no contiene ningún miembro (sin esa clase), no estoy seguro de que exista siquiera el concepto de espacio de nombres en ese momento ... ni esperaría que fuera útil de todos modos.

Acabo de intentar reproducir esto con el compilador C # 2, y no puedo ver ningún rastro de un espacio de nombres vacío dentro del IL.

Answer 2

El único problema semi-relacionado que se me ocurre es que al compilar un proyecto en msbuild, las referencias indirectas no siempre se copian en el directorio bin de la aplicación actual. Si la biblioteca B hace referencia indirecta a la biblioteca A y la biblioteca C solo a B, la salida de la biblioteca A no se copiará necesariamente a la carpeta bin al compilar la biblioteca C. En el pasado, he usado una referencia de campo nula en una clase para asegurar que La dependencia es explícita y la salida se implementa correctamente. Tal vez los desarrolladores originales experimentaron algo similar y esta fue su solución?

Answer 3

Un hecho poco apreciado es que no existe tal cosa como un "espacio de nombres" desde el punto de vista del sistema de tipo CLR subyacente. Más bien, es solo una convención que decimos que un tipo que contiene puntos en su nombre es "un miembro de un espacio de nombres". Lógicamente no hay ninguna diferencia entre el código legal:

namespace N
{
class C {}
}

y el codigo psuedo:

class N.C {}

C # te obliga a fingir que esta agradable ficción es una realidad, pero es solo una ficción, desde la perspectiva del sistema de tipo CLR, por supuesto. Desde la perspectiva del compilador de C #, por supuesto, los espacios de nombres son "reales". Simplemente no corresponden a nada en los metadatos que no sea una parte del nombre de un tipo.

En resumen: si crea un ensamblaje con un espacio de nombres "vacío", el "espacio de nombres" no existe en absoluto en el binario compilado. Un "espacio de nombres" solo existe cuando hay un tipo en la biblioteca que tiene puntos en su nombre.

Ahora, por qué le importaría asegurarse de que un espacio de nombres "vacío" tenga alguna presencia en la forma binaria, no tengo idea.

Asumo que las versiones anteriores de C # muestran un comportamiento que no requiere esta clase ficticia

No Todas las versiones de C # desde 1.0 tiran espacios de nombres vacíos.