This didn't used to be the case. You simply compile against the silverlight CLR and your F# program would "just work" unless you touched on something in the F# library that used a method or type not available in the silverlight CLR (and that seemed pretty easy to avoid). However I have not tried this since the silverlight CLR was in alpha, so something might have changed:

[link:www.strangelights.com]

Cheers,

Rob

By on 9/10/2008 5:55 AM ()

Is it possible to not reference FSharp.Core in a dll built by the F# compiler? Your statement makes it sound like it is optional, but I didn't think it was.

Cameron

By on 9/18/2008 7:50 PM ()

The asmex assembly examiner in tables > typeref says these are referenced by my simple dll:

Microsoft.FSharp.Core.CompilationMappingAttribute
Microsoft.FSharp.Core.FSharpInterfaceDataVersionAttribute
Microsoft.FSharp.Core.Ref`1
Microsoft.FSharp.Core.SourceConstructFlags

Are those needed? If not, how about a fsc --nocore option?

Cameron

By on 9/18/2008 8:07 PM ()

Perhaps I might try this if I find the time. But the concern of my question is more directed towards the future. While programming F# without using the F# core library might be possible, it lacks quite some convenience and as the runtime-problem will persist, I think the wish for F# core dlls for Silverlight is valid. If this does not run into problems caused by limitations of the Silverlight platform, it could be just another part of the distribution, or, if the matter of size is a problem, a separate download. Even the Visual Studio plugin could be adjusted to include a F# Silverlight project template that automatically uses the Silverlight-compiled core dlls.

By on 9/12/2008 3:57 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper