Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are there plans to remove the restriction of "Omnisharp needs to be restarted after adding a new package reference" #424

Open
madelson opened this issue Mar 12, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@madelson
Copy link

commented Mar 12, 2019

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 dotnet-script, this is the once piece that seemed like it would be pretty clunky to work with and that it could lead to a lot of developer frustration. Pretty much every LinqPad script we write today leverages a number of NuGet packages, so this would be a heavily-used feature.

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.

@atifaziz

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

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!

@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 dotnet-script but there was some contention around caching strategies and the dotnet-script maintainers decided to settle on their own pick. There are also some corner cases that C# scripting can't handle so in the end, I decided it may be best to go with the approach of transforming a LINQPad script into a .NET Core console project (transparently and on-the-fly) and run that, with subsequent invocations reusing previous compilations whenever possible. If interested, come join the show. 😉

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.

@filipw

This comment has been minimized.

Copy link
Owner

commented Mar 12, 2019

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.

the actual root cause is in the Roslyn compiler - I have a pending PR that will address the root problem dotnet/roslyn#25422
Once that is merged, it will open up some clean ways of handling this.

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 #r that directly reference DLLs - not nugets - those are processed in real time). I have been working on a workaround in OmniSharp that will allow Nuget dependencies to be resolved upon saving the file too, which hopefully would improve the behavior.

@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.
it allows you to select nuget packages from nuget using command palette and adds the selected version to the CSX as #r. Then it silently restarts OmniSharp for you as part of this "installation". It's sort of a neat way to work around the problem, perhaps you'd find this useful.

@filipw filipw added the intellisense label Apr 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.