(I replied to this topic last week, but it got lost and didn't show up! Not sure what's going on... I'll see if I can remember what I said)

Hi Don,

Thanks for the #load tip. I just moved the common code into a single F# file and #loaded it into FSI. Seems to work ok.

Initially I'd thought that perhaps this kind of problem (the common assembly being locked by the current FSI session's AppDomain) could be eliminated by providing a #R directive that copies the assembly locally before loading it into FSI's AppDomain (identical to how the -R command line switch works). But, this would only solve half of the problem -- I would be allowed to edit the common assembly code and compile it since the output file wouldn't be locked, but I couldn't copy it (with the proposed #R directive) to the local directory because the current version of the assembly would be locked. And here's the real problem -- once the assembly is loaded into FSI's AppDomain, a newer version of the assembly can't be loaded. It would be really nice if this kind of use-case were supported -- perhaps by loading each assembly referenced with #R into its own AppDomain, and then when the next #R is encountered, FSI checks the timestamps on each file to determine which one is newer. If a newer version is encountered, then the whole AppDomain containing the old assembly is unloaded and the new assembly is loaded into a new AppDomain.

This brings up more interesting problems, like what to do with objects that have been instantiated using classes in the old assembly. Perhaps a MATLAB-esque "clear" command could be added to FSI that would clear out all objects in the workspace and unload all custom assemblies.

I don't know about other people that use MATLAB a lot, but there are mainly 2 use cases that I commonly encounter, that it would be nice if F# in Visual Studio supported: 1) I write an M-File as a script that begins with (my personal preference): "clear all; close all; format compact; clc;" That just clears out everything that's been previously calculated and starts from scratch, eliminating any hard-to-debug side effects from a previous run, and 2) I write an M-File in sections, and execute each section in the interactive editor as I need to, but only for testing pieces of a script. Once I get it working, I move it to a script M-File. I think that the ability for an F# program to accomplish the same task from FSI within Visual Studio would be immensely powerful because of the full interoperability with the .NET Framework. Being able to simultaneously work on support DLLs that get automatically loaded into FSI after they are modified would be a huge step toward this direction. This kind of thing would really foster code development for re-use.

While I think that the #load of an entire F# project file would be useful in some cases, I think that it's still shortsighted. For example, it doesn't help me when I want to write a shared assembly in C# and use/test it from F#. Or if I want to write a library in F# and use it from C# or even VB.NET or any other .NET compatible language. The whole idea is to allow interoperability between CLR-compliant assemblies.

That's just my $0.02 :)

Thanks again,

Matt