Технически говоря, сборки Silverlight похожи на обычные сборки CLR, за исключением того, что они ссылаются на разные версии среды выполнения (и разные версии системных библиотек, такие как mscorlib). Silverlight может запускать только сборки Silverlight, поэтому, если вы компилируете код F #, вам нужно указать компилятору F # ссылаться на Silverlight (здесь шаблоны Visual Studio от Luke Hoban и вот недавний образец Silverlight приложение в F # (Брайан Макнамара).
Теперь, что касается сборок не-F #, боюсь, это может быть проблемой. В принципе вам не нужно их перекомпилировать - есть инструменты для изменения версии (чтобы превратить сборку CLR в сборку Silverlight). См. Например эту статью . На практике Silverlight имеет много ограничений (многие методы отсутствуют, вам не разрешено делать некоторые трюки с Reflection по соображениям безопасности и т. Д.). Итак, я боюсь, что если вы просто конвертируете сборку в Silverlight, она не будет работать, но вы все равно можете попробовать это ... (но будьте осторожны - если ссылочный метод отсутствует, вы не найдете этого до тех пор, пока Silverlight не попытается вызвать его во время выполнения).
Наконец, существует также проблема связи с приложением, запущенным в Silverlight, поскольку приложения Silverlight имеют довольно ограниченные возможности. Однако Silverlight 4 RC должен позволять вам читать / записывать локальные файлы при работе в режиме Out-of-browser (что может быть достаточно).
В итоге Я думаю, что есть много проблем, которые могут сделать невозможным использование Silverlight для этого. Возможно, я бы подумал о том, чтобы провести еще какое-то тестирование на Mono и посылать им отзывы (если вы обнаружите случай, когда производительность явно плохая). По моему опыту, они могут быть весьма эффективными при реагировании на отзывы пользователей, и я чувствую, что F # может быть довольно интересной вещью для команды Mono.