Back to Questions
1.0k
views4
comments
Dynamically loading, invoking, unloading, and deleting an F# assembly
f#

Suppose I define the following interface in an isolated assembly:

1
2
3
4
5

type ITest =
    abstract Foo : int
    abstract Bar : int -> int
    abstract Baz : (int -> int)
    abstract Bov : int -> int * (int -> int)

Then, I implement this interface (again in an isolated assembly called MyTest.dll, referencing the first):

namespace MyTest

1
2
3
4
5
6
7
8

type Test() =
 inherit System.MarshalByRefObject()

 interface ITest with
  member this.Foo = 12
  member this.Bar(x) = x + 12
  member this.Baz = (fun x -> x + 12)
  member this.Bov(x) = x + 12, (fun y -> y*y)

Now, I want to: dynamically invoke methods on this Test class, and then be able to delete MyTest.dll. Following the various tutorials on this, I know I need to do this in a new AppDomain, i.e.:

1
2
3
4
5
6
7

let appdom = AppDomain.CreateDomain("TestDomain")
            let test = appdom.CreateInstanceAndUnwrap("MyTest", "MyTest.Test") :?> ITest
            let a = test.Foo
            let b = test.Bar(1)

            AppDomain.Unload(appdom)
            File.Delete("MyTest.dll")

And this works fine. However, if I invoke either Baz or Bov on ITest, things stop working. That is, MyTest.dll gets loaded into the current AppDomain, and it becomes impossible to delete it.

The issue appears to happen because these methods return closures. Is this a bug, or an unavoidable restriction for some technical reason, or what?

Rgds,

Mat

.

Hm. I was hoping to find more about this; all I found web-searching now was a side comment on this old blog

[link:blogs.msdn.com]

that says

This has the effect of marshaling the delegate into that AppDomain and then dispatching to it there. The assemblies containing the delegate and the target of the delegate will be created in the specified AppDomain.

which suggests this is the by-design behavior?

By on 4/4/2009 11:44 AM ()

Perhaps?

One thing, from here:

Data can only be marshaled across AppDomain boundaries if it is either remotable or serializable. Remotable data is an instance of a class that descends from System.MarshalByRefObject.

Are F# closures either remotable or serializable?

By on 4/4/2009 12:01 PM ()

F# closures are marked serializable, and I've actually persisted them to a database and reloaded them later. So in this case it's probably returning the serialized closure, and to deserialize it needs the concrete type?

I'm not too up on cross-AppDomain stuff, but the way I think I've solved this in the past is to make sure I'm executing everything in the target AppDomain. This consists of loading my executable code (the runner) into the new AppDomain, and having it do its work there. That way I don't get things leaking back into the original AppDomain.

By on 4/4/2009 12:14 PM ()

Ah, got it finally:

1
2
3
4
5
6
7
8
9
10
11
12
13

let appdom = AppDomain.CreateDomain("TestDomain")

let baz : (int -> int) ref = ref id

appdom.DoCallBack(fun () ->
let asm = Assembly.Load("MyTest") 
let test = asm.CreateInstance("MyTest.Test") :?> ITest
baz := test.Baz
) 

AppDomain.Unload(appdom)

File.Delete("MyTest.dll")

it appears that only a copy of baz gets modified within the scope of the DoCallBack lambda, the original baz is unmodified...

By on 4/4/2009 12:40 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