Improve Plugin Release Model

Right now, there's no clear way to "release" a SDK/WPA plugin so that it can easily, and directly, be consumed by WPA. The best solution right now is for us to release a helper script that installs/opens WPA, downloads our plugin (from somewhere?), with all its dependencies, and then opens WPA with args that point it to our plugin. There are lots of opportunities here for improvement.

Dependencies

Currently, to load our plugin (QuicTraceLib.dll) requires a number of other files to be in the same folder.

As I understand it, pretty much all these files would be shared by every plugin. Is that not correct? Is there anyway we can improve the situation here so "publishing" our plugin doesn't mean we have to package all these binaries up with it?

Publishing

Since the current process requires our script to do "everything", we can publish the plugin (with all dependencies) anywhere and in any format (i.e. just a simple zip or something more fancy) we like. I would like to propose we standardize this a bit so that WPA can grab the published plugin directly; for instance, using NuGet.

If we could simply publish our plugin via a public NuGet feed, and then point WPA to that, that'd be ideal. We could get out of the business figuring out how to publish, how to download and where to put it after we download. Also, this helps standardize versioning and automatically getting the latest plugin.

Launching

Finally, requiring us to have a script to launch WPA with custom args is painful and doesn't scale beyond one plugin. We are already envisioning a model where we have two different layers' logs in the same file, each with their own independent plugin. Neither repo should have a script that depends on the others' plugin.

Somehow, WPA should "just know" what plugin to use and go and get it. This way, a vanilla WPA install can simply be used to open up a file and use the appropriate plugin. I can think of two possible ways to go about this, but I'm sure there are more:

Centralized

There is a centralized location (this repo?) that has a mapping of Provider to NuGet package name (assuming NuGet publishing model) that WPA can use to figure out which plugins to get for the file.

Dynamic Load

There is a special ETW event that must be written by the provider (not sure how this would work) that says "I can be loaded by plugin X" (where X is the NuGet package name).

The issue names WPA and QuicTraceLib.dll but no repository files, tests, or concrete entry point; start by tracing how WPA currently discovers, launches, and packages plugin dependencies. Compare the proposed NuGet, centralized mapping, and dynamic-load approaches, with completion defined as a design that supports standardized publishing, dependency handling, and multiple independent plugins without per-repository launch scripts.