Как Silverlight определяет, что сборка является Silverlight?

Я пытаюсь скомпилировать код из F # для использования в Silverlight. Я компилирую:

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

Это создает автономную сборку, которая ссылается на структуру SL. Но когда я пытаюсь добавить ссылку на сгенерированную сборку, я получаю такую ​​ошибку:

Вы можете добавлять ссылки на проекты только в другие проекты Silverlight в решении.

Что делает плагин VS, чтобы определить, что это не сборка Silverlight? Вот манифест:

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

Я не понимаю, что ему не нравится; это чистый проверяемый IL. Я сравнил со сборкой SL "библиотека классов", и она выглядит так же. Единственная разница заключалась в некоторых атрибутах, но я удалил их, и VS по-прежнему позволял мне ссылаться на DLL. Я даже добавил непроверяемый IL в DLL "SL library", и она все еще загружалась.

Какие-либо предложения?

Обновление. Я кое-что покопался, и мне кажется, что манифест не имеет значения. Не нравится что-то в IL из библиотек FSharp. Их можно проверить, но что-то внутри вызывает отказ.


reference f# silverlight
person MichaelGG    schedule 25.10.2008    source источник
comment
Если у вас есть ответ, не забудьте поделиться им с нами. Я тоже хотел бы это знать. Спасибо!   -  person chakrit    schedule 26.10.2008
comment
Обязательно выложу, если разберусь: P   -  person MichaelGG    schedule 28.10.2008

Ответы (2)


arrow_upward
7
arrow_downward

Ответ!

По-видимому, проблема в том, что когда вы добавляете ссылку на bin \ Release или bin \ Debug, Visual Studio (или система проектов Silverlight) решает попытаться сослаться на проект. Это не удается по какой-то причине.

Если вы скопируете выходную DLL F # в другое место, ссылка пройдет нормально. (Конечно, это будет ссылка на файл, а не на проект.)

Затем настройте зависимости, чтобы сначала была построена библиотека F #, а затем вы можете использовать ссылку на файл для получения двоичного файла, сгенерированного F #.

Обновление. Еще одна очевидная проблема. Если я включу оптимизацию кода, то получаю такую ​​ошибку:

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'

Если я отключу оптимизированный код, это исчезнет, ​​и все будет работать нормально.

person MichaelGG    schedule 28.10.2008
comment
Не могу дождаться, чтобы попробовать! - person Brian Leahy; 29.10.2008

arrow_upward
0
arrow_downward

Visual Studio использует функцию IsSilverlightAssembly () в типе Microsoft.VisualStudio.Silverlight.SLUtil для проверки возможности установки ссылки.

У Дэвида Бетца есть хорошая запись в блоге, в которой подробно описаны здесь.

person Maurice    schedule 22.01.2009
comment
По-видимому, он делает немного больше, чем внутри VS, поскольку перемещение файла из целевого местоположения заставляет VS видеть его как сборку SL - те же биты, которые он раньше видел как не-SL. Хотя, возможно, это другая логика, которая говорит ссылку на файл на путь вывода - ›ссылка на проект. - person MichaelGG; 23.01.2009