Back to Questions
3.4k
views10
comments
Static linking bug and runtime availability in .NET 4.0
f#.net

Hi,

I'm getting an error when I try to compile an F# library that accesses WPF using the --standalone flag:

FSC(0,0): error FS0084: Assembly reference 'PresentationCFFRasterizer.dll' was not found or is invalid

Done building project "uiutil.fsproj" -- FAILED.

Will the F# runtime be shipping with .NET 4.0?

Thanks,

Rei

.

The F# runtime (FSharp.Core.dll) is not part of .Net 4.0.

On my internal bits today, I succeed with using --standalone for a 'hello world' WPF app. I get the same error as you when trying to compile that same app with --standalone on the May CTP. So I think we have fixed some bugs here recently.

By on 10/1/2009 4:17 PM ()

That's unfortunate that the F# runtime is not a standard part of .Net 4.

I was predicating some plans on it being there as part of the standard distribution.

I had no idea that there was now the concept of a second class language.

How do we petition that this hostile decision be reconsidered.

By on 10/1/2009 8:47 PM ()

Well, you can still statically link to it, except with WPF in the current build apparently -- but I think that's not too much of an issue so long as there's another CTP or something soon enough.

They don't call it the Common Language Runtime for nothing; the only real difference to me between a "first class" language and a "third class" language is whether Microsoft is actively supporting it and improving it to polish, especially in the area of tooling. So I do think F# is still a first class language.

On the other hand, I really don't want to static link the runtime too much. It's about 1.5MB overhead per assembly, and compiling takes forever. That's 4.5MB of redundant code with 3 assemblies.

Instead I would much rather have permission to throw it into the folder alongside my assemblies.

By on 10/1/2009 11:09 PM ()

It didn't occur to me that F# would not just be in the GAC when 4 was released.

By on 10/2/2009 5:46 AM ()

I want to make sure I'm not missing something...

If you have a dependency on 4.0, then the user will first have to install that, which is large. (Win7 has 3.5 sp1, right?)

So we just need to install the f# dlls along with all the other DLLs (3rd party GUI libs, etc.) that we install w/our apps, guaranteeing that we now have the latest f# bit.

Seems not so bad...

By on 10/2/2009 7:35 AM ()

My take, my expectation ... hope is that now/soon after the VS2010 F# v 1.0 release (Nov. '09?) that Don and gang will get the "designer" WPF/SL F# connection(s) polished up for a quick v 1.1 update. The EYES have it. Has anyone seen F# roadmap?

FYI From an interview with Don:

Q. Will this release include designer tools?

o Our focus on delivering high-quality F# core tools is designed to augment Visual Studio’s amazing strengths as a presentation-rich object-oriented programming environment. As a result, we have made an explicit decision to leverage the strengths of C# and Visual Basic as presentational and designer-rich programming languages in this release. This means that F# users should use the Visual Studio designer tools to generate C# or Visual Basic code and incorporate those components into their F# applications. In Visual Studio 2010, we expect F# applications which include components built with designers (e.g. WinForms, ASP.NET, Silverlight and WPF applications with a designer front-end) will normally be authored as mixed language applications. We'll be providing templates that guide F# developers through this process.

By on 10/2/2009 9:45 AM ()

Thanks for that quote.

It slipped under my radar, that F# won't be automatically in the GAC.

Leaving the UI/eye-candy to other languages is, I think, the right decision. (I know of another language that would have been well advised to follow a similar route!)

No auto deployment is bad news. It will dent uptake. There are a lot who won't be prepared to install the underpinnings just to support their app.

(It's like a return to some of the bad things of the COM days.)

As for the "I'm all right Jack" comment.

Sure for some deployment situations it's not hard.

For others it is a factor.

i.e. Among other things I'm looking at two situations.

One I can fix with inconvenience to myself.

The other I will simply drop. It was a good idea, I held off spending resources to be ready for it (now I'm glad I stopped), so I haven't wasted a few hundred hours.

By on 10/2/2009 7:46 PM ()

Here's a link to that information

[link:j.mp]

(This reply editor is just text, hope that works.)

By on 10/2/2009 7:49 PM ()

Ah, yes, see below for the quote.

Note that I believe the license lets you redistribute FSharp.Core.dll, so in addition to the option below (e.g. deploy the redist), you can choose to just deploy the runtime DLL alongside your app (which is similar to --standalone from a deployment perspective, though with slight differences in servicing).

[link:blogs.msdn.com]

Q. Is F# in .NET 4.0?

o The current plan of record is that the F# core libraries and compiler will ship as an additional component, not in the .NET Framework itself. We expect this to be available as an F# redistributable package. Referencing this package from a Visual Studio setup project will be sufficient to deploy the core library DLL(s) it to a client machine.

By on 10/2/2009 8:21 PM ()

so in addition to the option below (e.g. deploy the redist), you can choose to just deploy the runtime DLL alongside your app

:D

By on 10/3/2009 2:41 PM ()

    Topic tags

    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