2012-07-10 19 views
12

Se han introducido referencias de ensamblajes reutilizables para .NET Compact Framework y ahora se usan para admitir bibliotecas de clases portátiles.¿Cómo decide el compilador de C# emitir referencias de ensamblado redestilables?

Básicamente, el compilador emite la siguiente MSIL:

.assembly extern retargetable mscorlib 
{ 
    .publickeytoken = (7C EC 85 D7 BE A7 79 8E)       
    .ver 2:0:5:0 
} 

¿Cómo funciona el compilador de C# entender que tiene que emitir una referencia retargetable, y la manera de forzar al compilador de C# para emitir dicha referencia incluso fuera de un portátil biblioteca de clase?

+0

¿No hay indicaciones de los archivos de destino de MSBuild? Me pregunto qué necesitas pasar al compilador desde la línea de comando. – leppie

Respuesta

2

Para el ensamblaje en sí, es un indicador de ensamblaje, es decir [assembly: AssemblyFlags (AssemblyNameFlags.Retargetable)].

Tenga en cuenta que esta bandera no tiene sentido fuera de los ensamblajes de la plataforma; los ensamblajes personalizados no se pueden redirigir.

Para las referencias, se copia como parte del nombre del ensamblaje al que se hace referencia.

+0

Gracias. Esto es lo que estaba buscando. Esperaba deshacerme del mensaje 'No se pudo cargar el archivo o ensamblado' PostSharp, Versión = 3.0.0.0, Cultura = neutral, PublicKeyToken = 53d2effcf2ee70dc, Retargetable = Yes 'o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje.(Excepción de HRESULT: 0x80131040) 'cuando proporciono (a través de IHostAssemblyStore) otro ensamblaje que el que solicitó CLR, pero sigo recibiendo el error incluso con una referencia reorientable. ¿Hay alguna solución a esto? –

+0

Retargable no le permitirá saltar una combinación de usuario, como supongo que está intentando. Es completamente para fines internos de CLR. No soy un experto en las API de alojamiento, pero creo que LoadFile podría permitirte hacerlo. –

+0

Gracias. Intentaré con otra solución: el mismo nombre corto, la misma clave de nombre fuerte, pero un número de versión diferente. Las políticas de enlace normales deberían hacer el truco. –

2

No estoy seguro si esto ayudará, pero el siguiente archivo se generó automáticamente y se incluyó en la compilación.

using System; 
using System.Reflection; 
[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(
    ".NETPortable,Version=v4.0,Profile=Profile4", 
    FrameworkDisplayName = ".NET Portable Subset")] 

Esto podría indicarle al compilador que haga algo de magia.

Editar:

Creo anterior hace un portátil biblioteca. Desde la línea de comandos puedo ver que se usa /nostdlib+, y se hace referencia a un mscorlib.dll portátil (que supongo que tiene el mismo atributo que el mencionado anteriormente).

"... \ Archivos de programa \ conjuntos de referencia \ Microsoft \ Framework.NETPortable \ v4.0 \ Perfil \ Profile4 \ mscorlib.dll"

+1

El 'TargetFrameworkAttribute' también está presente para compilaciones de Client y Full Framework para v4, no está disponible para v3.5. Esta podría ser la razón por la que agregaron el atributo. A partir de v4, también ofrece una manera muy fácil de determinar si un ensamblado fue construido para el marco completo o el perfil del cliente. –

+0

@ AdamHouldsworth: Gracias, ¿y supongo que ahora está obsoleto dado que el perfil del cliente se ha ido en 4.5? ; p – leppie

+0

Incluso en .NET 4 la diferencia entre el perfil del cliente y la descarga completa era un par de MB jajaja, no lo vale, probablemente por qué lo conservaron a favor de PCL. –

0

me he dado cuenta mediante la experimentación que el compilador de C# haría una el compilador de referencia como retargetable si el ensamblado al que se hace referencia está marcado como redestinable (un modificador en la sección .assembly en MSIL). No encontré cómo el compilador decide hacer la ensamblabilidad retrógrada, aún.

Cuestiones relacionadas