Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Are there plans to remove the restriction of "Omnisharp needs to be restarted after adding a new package reference" #424
For context, I'm interested in using dotnet-script as a potential replacement for LinqPad based scripting that my company uses today. LinqPad offers a great scripting dev environment, but the CLI environment (based on lprun) is slow to start, Windows-specific, and doesn't provide a great way to split scripts out across files. In contrast, dotnet-script looks like the perfect C# scripting solution!
After reading through the docs for
Obviously I have no idea what it would take to resolve this issue and whether the "fault" lies with OmniSharp vs. dotnet-script, but consider this a vote for fixing it.
@madelson I was in the same situation as you. I had lots of LINQPad scripts where LINQPad was mostly used as a low-ceremony (though still a highly capable & productive development environment) alternative to Visual Studio for simple programs. However, I didn't have any run-time dependency on LINQPad and so LPRun, besides being slow, had me unnecessarily locked to Windows and .NET Framework. I wrote LINQPadless as my answer. At the time I published version 1, .NET Core was very new and still going through growing pains. For version 2 of LINQPadless, I wanted to take advantage of .NET Core when it had matured with 2.x so that I could use LINQPad to develop on Windows but eventually have the option to run the code on other platforms when authored in a portable way. This version is in another branch, and while it's still in development (pending some polish and documentation), I am using it for production workloads. I considered using
BTW, dotnet-script is an awesome project so this is not an attempt to steal any thunder; I use it regularly and follow it with great interest. I am just sharing my journey given that I was once at the same cross-roads that you seem to be now, especially with regards to LINQPad.
the actual root cause is in the Roslyn compiler - I have a pending PR that will address the root problem dotnet/roslyn#25422
Basically what happens now, is that assembly dependencies from nuget are scanned upon OmniSharp startup and loaded then. And if you change the nuget directives, they are not picked up anymore, since the compilation model is set (except for
@seesharper also had a nice prototype of a VS Code plugin that was used to install Nuget dependencies into a script file (sort of Nuget package manager for scripts) - you can find it here https://github.com/seesharper/dotnet-script-vscode/releases.