'do' statements in modules do not get evaluated ?

It seems that do statements in modules do not get evaluated when the module is accessed from another assembly.

Creating an empty project

D:\>md Test
D:\>cd Test
D:\Test>dotnet new classlib -lang F#
D:\Test>code Library.fs

then changing the code to

namespace Test

module SayDll =
    let hello name =
        printfn "Hello %s" name
    
    do printfn "loaded-SayDll"

and calling it from fsi

D:\Test>dotnet build
D:\Test>cd bin/debug/net7.0
D:\Test\bin\Debug\net7.0>dotnet fsi

Microsoft (R) F# Interactive version 12.0.2.0 for F# 6.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> #r "Test.dll"
- Test.SayDll.hello "Goswin";;

--> Referenced 'D:\Test\bin\Debug\net7.0\Test.dll' (file may be locked by F# Interactive process)

Binding session to 'D:\Test\bin\Debug\net7.0\Test.dll'...
Hello Goswin
val it: unit = ()

>

The do statement was not evaluated. Whereas putting it all in fsi

D:\>dotnet fsi

Microsoft (R) F# Interactive version 12.0.2.0 for F# 6.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> module SayFsx =
-     open System.Net
-     let hello name =
-         printfn "Hello %s" name
-
-     do printfn "loaded-SayFsx"
-
- SayFsx.hello "Goswin";;
loaded-SayFsx
Hello Goswin
module SayFsx =
  val hello: name: string -> unit
val it: unit = ()

the do statement evaluates as expected.

Is this behavior intentional? Did I miss some documentation on this? There is also a not really answered question related to this on Stackoverflow. What would make a do statement in another assembly’s module evaluate?

[charlesroddie]

This is according to spec.

FSharp language specification 4.1, 12.5.1 execution of static initializers.

The thing causing the difference between FSI and a dll reference is that static initializers are run on the basis of files, and in the first case there is something needing initialization in the same file (because everything is in one file), and in the second it is a “different file”.

[kerams]

If it’s according to spec, I would, at the very least, expect to see a warning when do module initializers are used in class libraries.

The workaround I have come up with is

module X

let _initializer: unit =
    oneTimeSideEffect ()

let funcRequiringOneTimeInitialization x y =
    _initializer // this is required, otherwise _initializer is never evaluated
    doStuff x y

It feels very brittle and unintuitive though. Yes, I can use a class with a static ctor for this, but “class bad, module good” 😃))).