Back to Questions
1.5k
views9
comments
deploying F# dlls
f#

Hi - I'm trying to use a F#-dll in one of my projects - indeed I referenced the dll in another dll.

Normaly on my development machine everything works fine - but after deploying I get a nasty "System.Badimageformatexception" and I guess that this is due to some problems with FSharp.core and FSharp.Powerpack.

I googled a bit and found the story with "--standalone" (--static-link is gone in the CTP?) so I tried this. After referencing all the missing dlls I got reported during compilation of the F# dll the dll gets build.

But now if I remove the FSharp.Core Reference from my other dll this one won't compile anymore reminding me to reference the missing dll.

Can anyone help me with this issue or do I have to rewrite all my F# code into a C# dll (:ARGH:)

.

Which environment are you deploying to? It works in development?

A BadImageFormatException is pretty severe -- it means the file it tried to load wasn't valid. Last I ran into this was when I generated an invalid assembly. If you're just copying the good files around, this shouldn't happen. I think it can also happen with some 32/64 bit mismatch.

If you use --standalone (--static-link is still there, try fsc /?), then no, you won't be able to have other F# projects reference that assembly and be able to interop. This is because the F# types are no longer the same; they are now your assembly's types.

By on 3/31/2009 11:28 AM ()

Which environment are you deploying to? It works in development?

A BadImageFormatException is pretty severe -- it means the file it tried to load wasn't valid. Last I ran into this was when I generated an invalid assembly. If you're just copying the good files around, this shouldn't happen. I think it can also happen with some 32/64 bit mismatch.

If you use --standalone (--static-link is still there, try fsc /?), then no, you won't be able to have other F# projects reference that assembly and be able to interop. This is because the F# types are no longer the same; they are now your assembly's types.

It's a Windows Server 2003 SP2 - this system is just like my development PC a 32bit OS.

I checked with a simple F#-program and well this runs fine - of course even without the --standalone, as long as the FSharp dlls are around (I checked running this from the directory I deployed my project to - so I guess my problems are not with F# after all).

:sigh: - I guess this leaves me with a lot of nasty debuging/trial and error to do.

BTW: It's a WCF-Service hosted in a Windowsservice - all runs smoth on my machine but after trying to start the service on the target machine all I find is a entry in the event logs giving me nothing more but a hint to the Badimageformatexception thrown by the CLR.

Me current guess is that maybe I am running into some issues with remoting (I use remoting to implement some simple form of IoC - and maybe I run into trouble with Assembly.Load?)

By on 3/31/2009 9:29 PM ()

well - yes this seems to be the problem.

I removed the initialisation that uses remoting and now the service starts it running cycle (of course he soon runs into some missing things and shuts down gracefully) - so I guess no blame to F# or it's libs.

Thanks for the help.

By on 3/31/2009 9:41 PM ()

Just in case anyone wants to know the solution to my problem: It was indeed caused by Assembly.Load - all the other reflection stuff is no problem but this function just don't work.

By on 4/1/2009 9:16 PM ()

Just in case anyone wants to know the solution to my problem: It was indeed caused by Assembly.Load - all the other reflection stuff is no problem but this function just don't work.

Can you share any additional info on the problem? I worked a lot with the reflection and Assembly.Load did not cause any problems, other than some misunderstandings on my part.

Your problems - are they related to F# in any way? My F# stuff is not using dynamic assembly load just yet, but will certainly need it in the future.

By on 4/4/2009 9:06 AM ()

No the problem was not related to F#.

I thouhgt it might be the F# assemblies because I never ran in such a problem before and had those "static link" problems in mind.

Basiclly I was playing with a filter mechanism for messages. This should be extensible without recompiling and so I use some kind of DI and IoC. For example there is a basic-filter for the subject of the message checking it against a regular expression - of course this expression must be serialized.

I have a simple IFilter interface and one more specialized interface inheriting IFilter that just represents filter expressions as "<filter> [>|>=|<|<=|=|<>] <concrete value]" and let's me make some simplifications (see below).

Every filter must be able to serialize itself (as XML) using some provided IoC-container (so the IoC must not only be able to give me a single object for a type but deserialize one)

To make this more fun I implemented a logic-filter in F# providing AND, OR, NOT support, and simplifining the second kind of implementation by writing the complete expression in conjunctive normal form, collecting by filter-class and then using some basic rules in the form "A > 2 AND A > 3" simplifies to "A > 3" and so on.

To make the story short - I didn't want to tell the IoC-container every single type-implementation (I use the constructor-delegate mechanism with a constructor receiving the serialized XML-data) so the idea was to initialise the container by searching in a directory for assemblies with IFilter-implementations using reflection.

And it works just fine - on my local machine - but alas on the server this little code:

1

 var asm = Assembly.LoadFile(file);

just give me the crash I talked about.

So well now I have to provide some "RegisterFilter(blablabla)" code for every filter and it's fine. Maybe I should put those thinks in an external config file but this seems overkill for my "test"-project.

By on 4/5/2009 9:55 PM ()

So well now I have to provide some "RegisterFilter(blablabla)" code for every filter and it's fine. Maybe I should put those thinks in an external config file but this seems overkill for my "test"-project.

Have you thought about using the .NET 3.5 Add-ins and Extensibility framework?

By on 4/6/2009 12:17 AM ()

No - it seems to be overkill for my purpuse + I hate to have all the interesting work be done by someone others code ;)

It's just some kind of "prove of concept"-project just to be sure that F#/C# interop is ready for the jungle (a.k.a. productive code) :)

By on 4/6/2009 6:24 AM ()

I think it can also happen with some 32/64 bit mismatch.

If that is the case, you should be able to force the applcation into 32bit mode by compiling the _executable_ for x86. The way it works is that the OS chooses 32 bit or 64 when it loads an application. So if you compile for Any CPU, it will choose 64bit on a 64 bot OS. However, if one of your referenced dlls is then for 32 bit only, you get the badimage exception. If the executable is 32 bit, the OS will load the whole app in 32bit mode and everything runs ok.That said, F# should work on 64 bit systems - I think it's unlikely this is the problem.

By on 3/31/2009 1:07 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