This can be internal.

If we make this internal, how will it be accessible from the tests ?

If we think about display feedback, I wonder if something a little richer than a string would be useful. What other use cases might there be for this event? What can subscribers do with a string?

Is this is C#-specific? If so, it should go into the CSharpKernel. This is worth discussing with @TIHan.

This is something we need to have a discussion with @KevinRansom about as he has been working on #r nuget for F#. It was mentioned that we could and probably should share so that there isn't a difference in behavior between two implementations of resolving nuget packages for the interactive experience.

I imagine that F# by itself could have its own way of resolving nuget packages, but through an API allow a custom handler.

I don't think we need a different way to resolve a NuGet package but might need custom handling once it's resolved, if only for different extension paths within the package.

Will there always be an invocation context? What about extensions that we want to load on startup?

We need to "Publish" an event saying that the extension has been loaded and we need the context for that. If we would like to load extensions at startup, how would we "Publish" that event if we dont have the KernelInvocationContext ?

I think once we have that scenario, it would not be a hard change to make this method maybe return a list of extensions that it loaded(so that it can be called at startup) and then the caller can do whatever necessary. Thoughts ?

Can we test this using InMemoryDirectoryAccessor?

This is an end to end test which tests that given a nuget package dll, is it able to load the extension from that, and since "LoadAssembly" is being called, it needs the artifacts to actually exist on disk.