Carpeta de ensamblados de referencia y diferentes ensamblajes con la misma versión

Tengo un proyecto que usa el ensamblado System.Runtime.Serialization . Estoy usando el tipo DataContractSerializer de ese ensamblado, pero tengo un problema. Hay dos asambleas:

C: \ Archivos de progtwig (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.0 \ System.Runtime.Serialization.dll

C: \ Windows \ Microsoft.net \ Framework \ v4.0.30319 \ System.Runtime.Serialization.dll

Ambos tienen la misma versión – v4.0.30319. El primero tiene 429kb de tamaño y el segundo, 1037kb. Utilicé el reflector para ver la lista de clases, y el primero no tiene la clase que necesito ( DataContractSerializerSettings ). Sin embargo, el segundo sí lo tiene.

¿Por qué hay una gran diferencia en el tamaño y las clases para ese ensamblaje? ¿Va a estar bien, si uso el segundo, en lugar del primero?

    .NET versión 4.0 realizó un gran cambio en la forma en que se realizan los ensamblados de referencia de marcos. Anteriormente, el ensamblaje de referencia era una copia simple del ensamblaje en tiempo de ejecución, el ensamblado en el GAC. Sin embargo, eso causó algunos problemas dolorosos. Notable es la WaitHandle.WaitOne(int) , fue agregada en la actualización de .NET 2.0 Service Pack 2 (también conocida como .NET 3.5). Los progtwigdores lo usaron sin darse cuenta de que era un método agregado , el número de versión del ensamblado de mscorlib aún era 2.0.0.0. Pero luego descubrieron que su progtwig falló cuando se ejecutaba en una versión no parcheada de .NET 2.0. Muy desagradable kaboom, MissingMethodException sin una pista de por qué podría faltar un método tan común.

    Para evitar este tipo de rotura, los ensamblados de referencia de .NET 4.0 se mantienen separados, en el directorio “% programfiles% \ Reference Assemblies” como descubrió. Y son ensamblajes especiales, solo contienen los metadatos con todo el IL eliminado. Por eso el assembly es mucho más pequeño.

    Microsoft ahora puede mejorar el código .NET 4 y agregar clases y métodos públicos sin causar este tipo de roturas. Y lo han hecho profusamente, las actualizaciones 4.01, 4.02 y 4.03 se han enviado desde la versión original 4.0.

    La razón por la que está teniendo problemas con la clase DataContractSerializerSetting se explica fácilmente, simplemente no aparece en el conjunto de referencia. Se agregó, probablemente en una de esas actualizaciones incrementales. Y no debes intentar, tu progtwig se romperá en una máquina que no tiene la actualización. Debería esperar hasta .NET 4.5, la versión que lo agregó al ensamblaje de referencia. Puede invocar DLL Hell si realmente lo desea.