.net - teoria - Carpeta de conjuntos de referencia y diferentes conjuntos con la misma versión.
teoria de conjuntos operaciones (1)
Tengo un proyecto que utiliza el ensamblado System.Runtime.Serialization
. Estoy utilizando el tipo DataContractSerializer
de ese ensamblaje, pero tengo un problema. Hay dos asambleas:
C: / Archivos de programa (x86) / Ensamblajes de referencia / 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 un tamaño de 429kb, y el segundo tiene 1037kb. Usé 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 tamaño y clases para ese montaje? ¿Estará bien, si uso el segundo, en lugar del primero?
.NET versión 4.0 hizo un gran cambio en la forma en que se realizan los ensamblados de referencia de framework. Anteriormente, el ensamblaje de referencia era una copia simple del ensamblaje de tiempo de ejecución, el almacenado en el GAC. Eso sin embargo causó algunos problemas dolorosos. Notable es la WaitHandle.WaitOne(int)
, que se agregó en la actualización de .NET 2.0 Service Pack 2 (también conocida como .NET 3.5). Los programadores lo usaron sin darse cuenta de que era un método agregado , el número de versión del ensamblado mscorlib aún era 2.0.0.0. Pero luego descubrieron que su programa fallaba al ejecutarse en una versión sin parches de .NET 2.0. Kaboom muy desagradable, MissingMethodException sin una pista por la que podría faltar un método tan común.
Para evitar este tipo de rotura, los ensamblajes de referencia de .NET 4.0 se mantienen separados, en el directorio "% programfiles% / Reference Assemblies", como lo descubrió. Y son conjuntos especiales, solo contienen los metadatos con todos los IL eliminados. Es por eso que el montaje 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 ruptura. Y lo han hecho de manera profusa, las actualizaciones 4.01, 4.02 y 4.03 se han enviado desde la versión original de 4.0.
La razón por la que tiene problemas con la clase DataContractSerializerSetting
se explica fácilmente, simplemente no aparece en el ensamblaje de referencia. Se agregó, probablemente en una de esas actualizaciones incrementales. Y no debes intentarlo, tu programa se interrumpirá en una máquina que no tenga la actualización. Debe esperar hasta .NET 4.5, la versión que lo agregó al ensamblaje de referencia. Puedes invocar DLL Hell si realmente quieres.