Best practices for libraries with admin level dependencies

[nick-beer]

I'm looking for a little bit of guidance.

I have a set of .NET Framework driver libraries that have been distributed via an installer for many years now. I'm now looking to modernize those libraries for easier consumption via NuGet packages for .NET 5 and beyond. However, these .NET libraries have dependencies on things like a kernel mode driver and shared global configuration/data that require administrative privilege for initial installation.

Some of these dependencies (like the configuration data) can be localized, but some realistically cannot. I know this type of global data is antithetical to NuGet, so I'll still need a traditional installer (although I'd be happy if there were some alternative here).

So, I think the best I can do is create a NuGet package and require the user to run a traditional installer once. One concern with this approach is ensuring the version of the NuGet package is compatible with the installed driver.

Are there any established best practices for this type of scenario? Any examples of packages that have similar requirements?

I've thought of a couple of things that might work/help:

• Include a .targets file in the build folder of the NuGet package that is responsible for verifying that the driver is installed, and that the driver version is compatible
• Update our installer to publish a .targets file to MSBuildExtensionsPath to define a custom property that can be used for the NuGet package version

Any thoughts or examples would be appreciated.

[donnie-msft]

Hi! Given this is a question about using the product, I've moved this to a Discussion.