feature request: static configuration

[jshield]

For the sake of performance and ease of debugging it would be nice if workspacer could look for a DLL named workspacer.Config.dll under %USERPROFILE%/.workspacer and if present load the assembly and use that for configuration, then falling back to compiling and executing a CSX script.

could look for a class named WorkspacerConfiguration that exports a method that returns the expect builder.

[josteink]

I don't have a strong opinion on this.

Myself I'm not sure debugging would be made easier by such a change... And if you pre-compile your configuration to a DLL (against versioned workspacer DLLs), what do you expect to happen when a new version of workspacer is made available?

Handling all that smoothly might actually do the opposite... Reduce performance and make debugging harder?

That said, if somebody wants to implement it and presents a PR, I will be willing to review it though.

[jshield]

hey mate thanks for the reply, by performance I mean the time it takes for the cscript to compile is non trivial particularly when I have a number of custom widgets and for whatever reason need to restart workspacer. perhaps if the resulting compiled cscript assembly could be cached somewhere it might not be an issue.

as for what happens, I'd imagine it would be the same as what happens now with the cscript if there is an API break it'll break, however it is a lot easier for me to automate testing my configuration still compiles using standard .net tools and github actions than relying on a custom cscript evaluator and having to launch workspacer on an agent in an interactive session and then script commands to terminate it.

a potential mitigation might be to release the configuration surface as a set of abstractions to nuget similar to how dotnet extensions like IConfiguration, DependencyInjection are released. those shouldn't change often, and can be versioned according to semver, although that would be additional maintenance burden and probably would only need to be done as a last resort.

I ended up rolling something that works for me so far, I've attached a PR for reference. it probably needs further work if it were to be merged into unstable.

[josteink]

as for what happens, I'd imagine it would be the same as what happens now with the cscript if there is an API break it'll break

The problem is the csharp-script gets compiled against whatever running assembly is running (so it's guaranteed to be the right one). while once compiled to a static DLL, the .NET runtime will link the compiled DLL to a specific versions of referenced DLLs.

This could create issues with loading the static configuration DLL after new versions are published and installed.

It's not impossible to handle. For instance, one can override the AssemblyLoadContext when loading the configuratio, but like I said it's going to involve at least a little bit of work.

a potential mitigation might be to release the configuration surface as a set of abstractions to nuget similar to how dotnet extensions like IConfiguration, DependencyInjection are released. those shouldn't change often, and can be versioned according to semver, although that would be additional maintenance burden and probably would only need to be done as a last resort.

Yeah. That sounds like a bigger kind of job, for IMO a very niche need. I'd rather not go down that road :)