.NET Interactive binary incompat + packages not on nuget

.NET Interactive appears to have made breaking changes to APIs without updating the extensibility packages available on Nuget.org. This leaves projects authoring extensions in a pickle, including forcing downstream users to transitively reference non-standard pacakge source locations.

• 1.0.0-beta.21553.5 is the latest extensibility package available on nuget.org (https://www.nuget.org/packages/Microsoft.DotNet.Interactive/1.0.0-beta.21553.5)
• 1.0.255401 is the set of packages being used in VS Code by default
• These are binary incompatible
• 1.0.255401 is presumably available but in a non-standard location. If an extension uses it, all downstream clients must add that non-standard location too.

[ NOTE: I was confused between the different versioning schemes between "microsoft.dotnet-interactive and “microsoft.dotnet.interactive”. For extensibility the individual 1.0.0-beta.* packages are the relevant ones ]

More generally, I’m concerned .NET Interactive is not yet managing binary compatibility of extensibility correctly, potentially leading us into a quagmire. In the long term it’s crucial that the extensibility model of .NET Interactive stay 100% stable and binary compatible - once people make extensions they must continue to work in all future versions of .NET Interactive.

In the problem I hit today, XPlot.Plotly.Interactive extends .NET Interactive by using https://www.nuget.org/packages/Microsoft.DotNet.Interactive/1.0.0-beta.21553.5. However when I load that into .NET Interactive in VS Code I get:

Error: Microsoft.DotNet.Interactive.KernelExtensionLoadException: Failure loading Kernel Extension
 ---> System.MissingMethodException: Method not found: 'Microsoft.DotNet.Interactive.DisplayedValue Microsoft.DotNet.Interactive.KernelInvocationContextExtensions.Display(Microsoft.DotNet.Interactive.KernelInvocationContext, System.Object, System.String)'.

This appears to be a .NET Interactive binary-compatibility mismatch, and indeed running

typeof<Formatter>.Assembly.Location

says:

...\.nuget\packages\microsoft.dotnet-interactive\1.0.255401\tools\net5.0\any\Microsoft.DotNet.Interactive.Formatting.dll

When I go looking for version 1.0.255401 on nuget.org to update XPlot the components aren’t there. This means the extension is now stuck of must start to rely on non-standard, non assembly download locations.

[jonsequitur]

The updated packages will appear on NuGet.org momentarily.

While an occasional break in binary compatibility is inevitable until we finalize the API, extension authors can reduce the exposure to this further by opting for source code compatibility using scripts (.dib files) instead of assemblies.

You can see an example here: https://github.com/dotnet/interactive/tree/main/samples/extensions/RandomNumber

[dsyme]

Thank you!