We are excited to introduce the WDK NuGet, a new offering that enables developers to build drivers for Windows.
The WDK is the essential tool for developing, testing and deploying drivers on the Windows platform. It provides the headers, libraries, tools and metadata that you need to create drivers for Windows devices.
Previously, the WDK was available as an MSI installer or an ISO file. In addition to these offerings, we now have the WDK NuGet package which contains DLLs, libraries, headers, tools and metadata for driver development. You can easily consume the WDK NuGet package by adding it to your project and then calling a package functionality in your project code.
The WDK NuGet offer the following advantages over the traditional WDK offerings:
It is smaller in size, which reduces the download and setup time.
It is portable across different machines and environments.
It can be integrated with large CI/CD pipelines and source control systems.
It better support an agile WDK release model, it can be easily updated with latest WDK features and fixes.
The WDK NuGet is now publicly available on nuget.org, where you can find all release and pre-release versions.
To get started with the WDK NuGet, you need to have Visual Studio 2022 or later installed on your machine. You can then follow the steps in this Microsoft documentation to install the WDK NuGet package and create your first driver project.
We are also working on improving the developer experience while developing their driver projects from Visual Studio.
We hope you enjoy the WDK NuGet and find it useful for your driver development needs. We welcome your feedback and suggestions on how to make it better.
So, I tried to update my VS 2022 WDK install (I had an older WDK revision installed) using NuGet a couple of weeks ago. It resulted in a completely non-working WDK to the point where I had to remove the WDK and SDK and reinstall them (well, I installed the newest version this time).
Is there some sort of limitation on how/when you do the NuGet install? Or was I just unlucky.
Peter,
To use the NuGet package, you only need the latest WDK VSIX component from the VS marketplace. You do not need to have WDK installed. However, if you had an existing WDK installation, the NuGet package shouldn't interfere with it. If you are able to reproduce this failure, please share.
Following up on my earlier post, I would like to clarify a few points:
The scenario you described is not possible and probably based on some misunderstanding. The WDK NuGet package is NOT an update patch that can be installed to update an existing WDK install. It is a separate package that can coexists with your existing WDK package without interfering with it. That is simply not how it works. If anyone has a similar experience, please let us know, we actively encourage feedback and suggestions on how we can make the experience better.
I'm happy to provide guidance if you have specific questions regarding how the WDK NuGet works. Do you have any specific challenges following the instructions documented here.
The specific use case that is not documented on that page is an existing msi based WDK installed with VS2022.
I think you said that the nuget install can coexist with an existing msi WDK install, and I am wondering how that works. How does VS2022 determine which WDK to use?
When NuGet package is installed, it copies the SDK and WDK packages to the driver project folder and that serves as wdkcontentroot for that project. If NuGet is not installed it uses the default WDK install path as the wdkcontentroot.
Does this answer your question?
I'm wondering if you hardcoded your WDK props file?
As I shared before, nuget packages will not interfere with your installed WDK msi.
Slight misunderstanding here: I hadn’t tried the nuget WDK yet, I was curious how the WDK specific property files were being located by visual studio when they weren’t in the standard ‘kits’ path.
So I tested it out on a vm and it works, and it works with my set of command line powershell build tools, which was my actual concern.
I’m still curious as to what was changed to convince vs to look in the project packages directory.
I guess the motivation for nuget WDK is primarily for build systems or managed ‘developer vms’ where installing msi’s is forbidden for security reasons?
@Paul_Eze Thanks for sharing, it looks like a great idea. I encountered the following issues when trying it:
wdf.h header was not found unless hardcoding the path in Additional Include Directories
Driver-specific platform toolsets (WindowsApplicationForDrivers, WindowsUserModeDriver) seem to not be available, like they used to be with the regular WDK - right?
I went through the process again on another machine and can confirm it works, so probably there must be something wrong with my main machine.
On a side note, could this also work when using the standalone Build Tools instead of the full Visual Studio installation? In this scenario I wasn't able to get past the "platform toolset not found" errors.
Thanks Mark, though I was rather referring to the normal Visual C++ build tools and not the EWDK.
Reason for asking is we have existing agents set up for building C++ applications and was hoping they could also work with driver projects, just by referencing the WDK Nuget package.
WDK Nuget requires the new 'WDK extension' for visual studio 2022. It will not work with Build Tools for Visual Studio, as far as I know.
The EWDK is the closest approximation to Build Tools for Visual Studio, however it has the reverse problem in that it has limited support for building applications.
I have a solution that can be built for x64 and ARM64. I can install WDK using NuGet for x64 or ARM64, there are no issues with building. But if install WDK for x64 and ARM64 for the same projects, the build will fail for one of the architecture. Is this a bug or is it just not supported yet?
I verified that both x64 and ARM64 WDK nuget builds work for me. I specified both platforms in my packages.config file and did a nuget restore to download all the required nuget packages.
So you are misconfigured somehow.
FYI: I used the github windows driver sample repo as a reference on how to get nuget builds working correctly. The entire repo (more or less, some directories are explicitly excluded) builds on github using a github 'action' script, and it uses nuget wdk builds.
<Project>
<Import Project="packages\Microsoft.Windows.WDK.x64.10.0.26100.3323\build\native\Microsoft.Windows.WDK.x64.props"
Condition="Exists('packages\Microsoft.Windows.WDK.x64.10.0.26100.3323\build\native\Microsoft.Windows.WDK.x64.props') and '$(Platform)' == 'x64'"/>
<Import Project="packages\Microsoft.Windows.WDK.arm64.10.0.26100.3323\build\native\Microsoft.Windows.WDK.arm64.props"
Condition="Exists('packages\Microsoft.Windows.WDK.arm64.10.0.26100.3323\build\native\Microsoft.Windows.WDK.arm64.props') and '$(Platform)' == 'ARM64'"/>
<Import Project="packages\Microsoft.Windows.SDK.CPP.x64.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.x64.props"
Condition="Exists('packages\Microsoft.Windows.SDK.CPP.x64.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.x64.props') and '$(Platform)' == 'x64'"/>
<Import Project="packages\Microsoft.Windows.SDK.CPP.arm64.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.arm64.props"
Condition="Exists('packages\Microsoft.Windows.SDK.CPP.arm64.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.arm64.props') and '$(Platform)' == 'ARM64'"/>
<Import Project="packages\Microsoft.Windows.SDK.CPP.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.props"
Condition="Exists('packages\Microsoft.Windows.SDK.CPP.10.0.26100.3323\build\native\Microsoft.Windows.SDK.cpp.props')"/>
</Project>
The directory.build.props file will add the associated nuget packages to all projects without having to individually modify each project.
To populate the packages directory, use nuget.exe. (You will have to install nuget.exe by downloading it from nuget.org, or by using winget, chocolatey, scoop etc. For unknown reasons Microsoft refuses to include it as a standard build tool.)
You should only have to do a restore once, unless you change the versions you are using. (For an automated build system the restore should be done as part of the setup for the build.)