A reproducible driver build environment is REAL easy, use the EWDK! It can be installed with an unzip, and/or checked into your version control system. The exact msbuild projects you create in VS2015 run perfectly in the EWDK. It’s the same underlying compiler and build engine, just no gui. You can run code analysis/SDV too, from a script if so desired. The EWDK is also free to download, so there are no licensing issues.
I also suggest developers still use VS2015/WDK manually installed on their workstation for unofficial builds and utility tasks like creating a new project with the wizard. This requires a valid license per user.
I had a non-trivial driver project (30K sloc) that I spent 18 months writing with VS0215/WDK. It took very little time to write a powershell script that consistently ran the build using the EWDK on the exact same project file. I could do my private developers builds by punching the build button in VS, and could run the script to make a real build for QA/Release. Real package builds need to do things like stamp version numbers, put things in zip files, and save symbols to symbol servers.
The non-obvious thing you have to do to use powershell for build scripts is you have to import the EWDK environment settings. There is a little tools that runs a .bat/.cmd script and saves all the environment variables into the powershell environment. Once you do that, you can just do everything in powershell. It takes a little Googling to find how to run SDV builds from a command line too. These are all non-problems after you have done them once.
Jan
On 6/5/17, 10:32 AM, “xxxxx@lists.osr.com on behalf of xxxxx@hotmail.com” wrote:
Is there an upvote button? Getting a development and build environment setup is certifiably ridiculous. For those folks that need to maintain reproducible builds (with their build tools) it’d be real handy to have a driver dev environment that could be easily archived.
It’s somewhat tricky with licensed software, but it’s not UNfeasible to consider something like a driver dev Windows container that would have the WDK and necessary tools to build/test baked-in. The full-blown IDE for Visual Studio would be run natively on your host machine and would be licensed as normal. I’m sure there are a million ways to skin that cat.
The issue remains GROSSLY OVERLOOKED at this point in time though. Getting the appropriate tools to author, build, and release drivers in a reasonable fashion is an afterthought. Microsoft has gone to great lengths to try to provide tools to help minimize “the industry” from releasing poorly tested code (WHQL signing, EV certs, PREfast, SDV, etc.) in an attempt to reduce BSOD failures that give MS a bad rap. They’ve seen a need to help get driver development integrated into the normal development toolset that has been established by user-space developers and the usage of Visual Studio to build/release drivers has been generally well-received. However, there’s a big gap when it comes to making reproducible build environments setup easily. When I unboard a new team member, or need to stand-up another machine to facilitate our nightly builds, it’s a damn nightmare. Get this version of this, and that version of the other, but NOT that version because they don’t work together. Oh and you can’t get the version you need from their website, so install it from over here, but make sure you install this FIRST or it will NOT work. C’mon man. That’s non-sense! What’s worse is when I have to evaluate a potential defect in a legacy driver. Rebuilding a particular release to make incremental changes to find root cause is a whole nother level of silliness with saved VMs, Vagrant scripts,and saved ISOs.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>