Nice idea while it lasted…

To summarize -- if your Scala.Net project only uses .Net 1 features, then you can tweak the IL to use the .Net 2 libraries if you wish; but you can't build something that invokes full .Net 2 functionality as yet.

That means trying to build a Scala project against Silverlight assemblies is a non-starter (or at least not a trivial one) with the current build process. Using the out-of-the-box assemblies:

scalac-net.bat astroclock.scala -Xassem-path 
System.Core.dll;system.dll;System.Windows.Browser.dll;System.Windows.dll
12@(06 15 12 80 ad 02 12 80 b1 12 88 c8)
error: error while loading Control, type 'System.Windows.Controls.Control' is broken
(15@2 in (06 15 12 80 ad 02 12 80 b1 12 88 c8))
9@(06 15 12 80 b9 01 12 86 80)
error: error while loading FrameworkElement, type 'System.Windows.FrameworkElement' is broken
(15@2 in (06 15 12 80 b9 01 12 86 80))
11@(20 01 15 12 25 01 12 78 11 85 b4)
error: error while loading UIElement, type 'System.Windows.UIElement' is broken
(15@3 in (20 01 15 12 25 01 12 78 11 85 b4))
11@(06 15 12 80 ad 02 12 86 38 11 5c)
error: error while loading DependencyObject, type 'System.Windows.DependencyObject' is broken
(15@2 in (06 15 12 80 ad 02 12 86 38 11 5c))
9@(06 15 12 80 b9 01 12 86 10)
error: error while loading Application, type 'System.Windows.Application' is bro
ken
(15@2 in (06 15 12 80 b9 01 12 86 10))
astroclock.scala:90: error: System.Windows.Application does not have a constructor
class MyApp extends Application  {
                    ^
…

while rebuilding the assemblies against either .Net 2.0 or silverlight mscorlib and trying again gave the even more fundamental, but well known

scalac-net.bat astroclock.scala -Xassem-path 
System.Core.dll;system.dll;System.Windows.Browser.dll;System.Windows.dll
error: error while loading String, type 'System.String' is broken
(PEModule.getTypeDefOrRef(): TypeSpec)
one error found

So, to do this would mean upgrading the scala-net compiler to understand .Net 2.0 constructs.

---

Later:--

In constructs like (15@2 in (06 15 12 80 ad 02 12 80 b1 12 88 c8)), the 0x15 (at position 2) is the code ELEMENT_TYPE_GENERICINST, which is then followed by <an mdTypeDef metadata token> <argument Count> <arg1> ... <argN>. The type metadata turns out to be a type-spec; but the rest of it I've not yet unpicked. And then there'd be reverse-engineering the Scala MSIL decompiler...

The first culprit is DependencyObject (#22 in the typedef table), for a private field; but there are dependency properties on UIElement which suffer the same.