Open colombod opened 3 years ago
@marcoparenzan
Why should it depend on FSharp compiler?
The package management implementation is written in F#.
Even if so... it should be a .net assembly, not relying on the compiler, shouldn't it?
Also, why is it marked with Impact-Low
? Sounds crucial
Also, it doesn't reproduce for me on the latest main
:
using var kernel = new CSharpKernel().UseNugetDirective();
var rInstruction = new SubmitCode("#r \"nuget:Newtonsoft.Json,13.0.1\"");
var result = await kernel.SendAsync(rInstruction);
result.KernelEvents.Subscribe(eventSub => eventSub.Should().NotBeOfType<CommandFailed>());
result = await kernel.SendAsync(new SubmitCode("1 + 1"));
result.KernelEvents.Subscribe(eventSub => eventSub.Should().NotBeOfType<CommandFailed>());
If I did everything correctly, of course
Also, why is it marked with Impact-Low? Sounds crucial
Embedding a C# kernel is still a bit of a niche scenario. This doesn't happen in the typical notebook configuration, i.e. the dotnet-interactive
tool. It happens if you reference Microsoft.DotNet.Interactive.CSharp
in your own app and enable loading NuGet packages.
You can see this scenario in use in this sample: https://github.com/dotnet/interactive/tree/main/samples/connect-wpf
Even if so... it should be a .net assembly, not relying on the compiler, shouldn't it?
Fair question. Eventually, this might be the case and would be a little cleaner. I should have clarified that the reason that the package management functionality is written in F# is that it's using F# scripting, which is in FSharp.Compiler.Service.
You can see this scenario in use in this sample:
Thanks, I wrote a sample which uses an embedded kernel for the repo 😄 . But okay, agreed that for now it's not urgent (although there're already apps using it!).
that the package management functionality is written in F# is that it's using F# scripting, which is in FSharp.Compiler.Service.
Okay, but then why is it using F# scripting? I guess I better dig into it myself though, it might be unclear without looking at the code
Thanks, I wrote a sample which uses an embedded kernel for the repo
I know, but the extra context is hopefully useful for others reading this.
Okay, but then why is it using F# scripting? I guess I better dig into it myself though, it might be unclear without looking at the code
It was tactical. We were already using F#, so why write another package manager? But we might well make this cleaner in the future.
I'm seeing this issue with the connect-wpf sample. I was trying to reference a package from nuget, but it basically causes a hang if its talking to the remote WPF kernel even with the latest dotnet interactive package version that the connect-wpf sample is talking to now.
Any idea what might be up? Wanted to mess around with this, but I'm not even sure if there is an exception being thrown.... Tried debugging it and breaking on all exceptions.
I'm seeing this issue with the connect-wpf sample. I was trying to reference a package from nuget, but it basically causes a hang if its talking to the remote WPF kernel even with the latest dotnet interactive package version that the connect-wpf sample is talking to now.
Any idea what might be up? Wanted to mess around with this, but I'm not even sure if there is an exception being thrown.... Tried debugging it and breaking on all exceptions.
Can you share notebook you are using to reproduce the issue? Thank you
@colombod I was just using the notebook in this sample: https://github.com/dotnet/interactive/tree/main/samples/connect-wpf And then tried to reference this nuget package:
#r "nuget: Infragistics.WPF.Charts.Trial, 21.1.37"
in the wpf context, e.g:
#!wpf
#!dispatcher
#r "nuget: Infragistics.WPF.Charts.Trial, 21.1.37"
var item = new Infragistics.Controls.Charts.XamDataChart();
now, its possible I messed something up, because I removed the package sources config from the nuget.config so that I was talking to public nuget, since it seemed all the required packages where there, and I needed to talk to public nuget for that package, but is the nuget.config required for this scenario? I also tried other nuget packages also with the same results.
in case I wasn't clear, I mean I yanked the packages sources:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<!-- <packageSources>
<clear />
<add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" />
<add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
<add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
</packageSources> -->
</configuration>
I am seeing the same issue. need to investigate
Describe the bug
Create a .NET 5 console app add Microsoft.DotNet.Interactive.CSharp 1.0.0-beta.21108.3 add nuget support unsing the
UseNuget
submit a #r instruction and exceptions is raised that reports about missing FSharp.Compiler.Service
Microsoft.DotNet.Interactive.CSharp should have dependency on FSharp.Compiler.Service for this to work for PackageManagement
Please complete the following:
1.0.0-beta.21108.3