Comment Silverlight détermine-t-il qu'un assemblage est «Silverlight»?

Question

J'essaie de compiler le code de F # à utiliser dans Silverlight. Je compile avec:

- noframework --cliroot " C: \ programme Files \ Microsoft Silverlight \ 2.0.31005.0 " --standalone

Ceci génère un assemblage autonome qui référence le framework SL. Mais lorsque j'essaie d'ajouter une référence à l'assembly généré, le message d'erreur suivant s'affiche:

  

Vous pouvez uniquement ajouter des références de projet à   autres projets Silverlight dans le   solution.

Que fait le plug-in VS pour déterminer qu'il ne s'agit pas d'un assemblage Silverlight? Voici le manifeste:

// 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

Je ne comprends pas ce que ça veut dire qu'il n'aime pas; c'est pur vérifiable IL. J'ai comparé à une "bibliothèque de classes" SL. Assemblée, et il semble le même. La seule différence était quelques attributs, mais j'ai supprimé ceux-ci et VS m'a toujours laissé référence à la DLL. J'ai même ajouté IL non vérifiable à la "bibliothèque SL". DLL et toujours chargé.

Des suggestions?

Mise à jour: J'ai fouillé un peu et cela ne semble pas être le manifeste qui compte. Il n’aime pas quelque chose dans l’IL des bibliothèques FSharp. Ils sont peverifiables, mais quelque chose déclenche le rejet.

Answer 1

Réponse!

Apparemment, le problème est que lorsque vous ajoutez une référence à bin \ Release ou bin \ Debug, Visual Studio (ou le système de projet Silverlight) décide de tenter de référencer le projet. Cela échoue pour une raison quelconque.

Si vous copiez la DLL de sortie F # vers un autre emplacement, la référence est parfaitement opérationnelle. (Ce sera une référence de fichier, pas une référence de projet, bien sûr.)

Ensuite, configurez les dépendances de sorte que la bibliothèque F # soit créée en premier, puis vous pouvez utiliser une référence de fichier pour obtenir le binaire généré par F #.

Mise à jour: Un autre problème apparent. Si j'active le code d'optimisation, j'obtiens l'erreur suivante:

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 je garde le code optimisé désactivé, cela disparaît et tout fonctionne correctement.

Answer 2

Visual Studio utilise la fonction IsSilverlightAssembly () dans le type Microsoft.VisualStudio.Silverlight.SLUtil pour vérifier si une référence peut être définie.

David Betz a publié un beau billet de blog décrivant les détails ici .