dotnet scripting / fsc compilation of .fsx scripts should package all the runtime dependencies along the compiled .exe

fsc support for compiling .fsx files could be improved by packaging all the runtime dependencies in the output folder, next to the compiled .exe.

Describe the solution you’d like

I’d like this to be the default behaviour, but since it would be a change of behaviour, maybe it would require a flag (--copy-runtime-dependencies-to-output-folder ?)

It should take care of those constructs:

• DependencyManager that are pulled through #r "extension: " mechanism
• vanilla #r "Assembly" directives
• #load “otherscript.fsx”
• more generally, all the HashDirective constructs that F# supports in scripts

Describe alternatives you’ve considered

Alternative is to make a new compiler out of FCS, that would do that, but it seems more cohesive to expand the support for compiling .fsx that is already implemented in fsc

Additional context

Related to https://github.com/dotnet/fsharp/issues/13236#issuecomment-1162153774 Related to https://github.com/dotnet/interactive

cc: @KevinRansom @jonsequitur

[KevinRansom]

@MecuSorin , I believe that what @smoothdeveloper would like to see is a developer experience for sompiling scripts that is as simple as the old desktop compile experience

fsc program.fsx

On the desktop framework this built an .exe that ran. In the cross platform multi-assembly world we now live in, the project file is pretty much essential. However, because #r “nuget: blah” which is valid .fsx syntax and thus can be compiled with F# compiler; the dependencies retrieved using it are not visible to the dotnet build and pack processes. They can of course be easily added to the project file for compile, but it is an extra manual step. What I believe @smoothdeveloper is really asking for is a mechanism that simplifies compiling and deploying F# scripts that have complex dependencies.

This isn’t a scenario we have spent much time on thinking through, but is certainly quite valuable to script developers. Any change we make, would most likely involve teaching dotnet build to understand how to access the results of the #r nuget action.

[kant2002]

Most probably I want to have dotnet publish myscript.fsx, because this is ultimately publishing with all parameters which dotnet publish can provide. I imaging if we can teach dotnet-publish to handle .fsx files as projects. If think this through, IronPython can benefit from this too, as other languages. but this way may require some form of support from dotnet SDK for scripting environments which maybe accepted or not.

As a practical way to do it, I create prototype tool which I share in #13961 . I collect all references and handle other directives, similar to what @jonsequitur seems to be doing and pass additional arguments to dotnet publish. Would be curious to know how they do it.

seems to be whole scope of work is relatively small, but packaging solution and property land it inside existing tooling is complicated.