2008-10-25 7 views
11

Estoy tratando de compilar el código de F # para usar en Silverlight. Compilo con:¿Cómo determina Silverlight que un conjunto es "Silverlight"?

--noframework --cliroot "C: \ Archivos de programa \ Microsoft Silverlight \ 2.0.31005.0" --standalone

Esto genera un montaje independiente que hace referencia al marco de los MVS. Pero cuando intento agregar una referencia al ensamblado generado, me sale este error:

You can only add project references to other Silverlight projects in the solution.

Qué está haciendo el plugin de VS para determinar que esto no es un montaje de Silverlight? Aquí está el manifiesto:

// Metadata version: v2.0.50727 
.assembly extern mscorlib 
{ 
    .publickeytoken = (7C EC 85 D7 BE A7 79 8E)       // |.....y. 
    .ver 2:0:5:0 
} 
.assembly FSSLLibrary1 
{ 

    // --- The following custom attribute is added automatically, do not uncomment ------- 
    // .custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [mscorlib]System.Diagnostics.DebuggableAttribute/DebuggingModes) = (01 00 01 01 00 00 00 00) 

    .hash algorithm 0x00008004 
    .ver 0:0:0:0 
} 
.module 'F#-Module-FSSLLibrary1' 
// MVID: {49038883-5D18-7281-A745-038383880349} 
.imagebase 0x00400000 
.file alignment 0x00000200 
.stackreserve 0x00100000 
.subsystem 0x0003  // WINDOWS_CUI 
.corflags 0x00000001 // ILONLY 
// Image base: 0x04120000 

No entiendo lo que está encontrando que no le gusta; es IL verificable puro Lo comparé con un ensamblado de SL "biblioteca de clases", y tiene el mismo aspecto. La única diferencia eran algunos atributos, pero los eliminé y VS aún me permitió hacer referencia a la DLL. Incluso agregué IL no verificable a la DLL "biblioteca SL" y todavía se cargó.

¿Alguna sugerencia?

Actualización: He estado hurgando, y no parece ser el manifiesto lo que importa. No le gusta algo en el IL de las bibliotecas de FSharp. Son peverificables, pero algo allí está desencadenando el rechazo.

+0

Si tiene una respuesta, no se olvide de compartirla con nosotros. Me gustaría saber esto también. ¡Gracias! – chakrit

+0

mismo aquí, me encanta F # –

+0

Definitivamente lo publicaré si lo resuelvo: P – MichaelGG

Respuesta

7

¡Respuesta!

Aparentemente, el problema es que cuando agrega una referencia al bin \ Release o bin \ Debug, Visual Studio (o el sistema de proyectos de Silverlight) decide intentar hacer referencia al proyecto. Esto falla por la razón que sea.

Si copia la DLL de salida F # a otra ubicación, la referencia se procesará correctamente. (Esta será una referencia de archivo, no una referencia de proyecto, por supuesto.)

Luego configure las dependencias para que la biblioteca F # construya primero, luego puede usar una referencia de archivo para obtener el binario generado por F #.

Actualización: Otro problema aparente. Si giro optimizar el código, entonces me sale este error:

C:\test\SilverlightApplication1\FSC(0,0): error FS0193: internal error: the module/namespace 'System' from compilation unit 'mscorlib' did not contain the namespace, module or type 'MarshalByRefObject' 

Si sigo código optimizado fuera, esto desaparece y todo funciona bien.

+0

¡No puedo esperar para intentarlo! –

0

Visual Studio usa la función IsSilverlightAssembly() en el tipo Microsoft.VisualStudio.Silverlight.SLUtil para verificar si se puede establecer una referencia.

David Betz tiene una buena publicación de blog que describe los detalles here.

+0

Aparentemente, hace un poco más que eso dentro de VS, ya que mover el archivo fuera de la ubicación de destino hace que VS lo vea como un ensamblaje de SL, los mismos bits que vio antes que SL. Aunque, tal vez esta es otra lógica que dice "referencia de archivo a la ruta de salida -> referencia de proyecto". – MichaelGG

Cuestiones relacionadas