This is not the first time I've written about the Windows API Code Pack, and probably will not be the last time. However, this time I am reaching out to all Windows Developers who create Windows applications using the .NET framework--this blog post is for you. We want your feedback about the Windows API Code Pack in preparation for a future release. And to all those who wonder whether the API Code Pack is still alive, fear not--it is alive and kicking!
You may think of the Windows API Code Pack as the closest thing to an “official” managed API for Windows on top of the .NET Framework. The Windows API Code Pack is a free, managed source code library provided by Microsoft as-is. You should consider this library as if you wrote that code. It is a great starting point and provides a really solid solution for managed code developers who create Windows application and looking to light up their applications. It covers a lot of the new Windows 7 features as well as some more fundamental core features from the Windows Vista timeframe.
The Windows API Code Pack's former name was Windows Vista Bridge, or simply “The Bridge”. We began developing the Windows Vista Bridge after Windows Vista and the .NET Framework 3.0 were released. Realizing that .NET Framework 3.0 was missing some Windows Shell and other Win32 APIs, which made it harder for managed code developers to use the full power of Windows. The team set out to create a “bridge” that would help developers to cross this gap and allow managed code developers to access some of the more useful features of Windows, such as Search, Restart and Recovery, Glass, and Power Management. The outcome of this process was the Windows Vista Bridge Sample Library.
In the process of updating Windows Vista Bridge, we realized that the old name doesn't fit the new Library. Because this library is no longer tied to a specific Windows release, we decided to change the name to the rather unwieldy but descriptive Windows API Code Pack for Microsoft .NET Framework. Unlike Vista Bridge that shipped after Vista was released, the Alpha version (version 0.8) of the Windows API Code Pack was released on April 20, 2009, six months before Windows 7 shipped. Releasing an early version allowed us to solicit developers’ feedback, update our feature list, and discover more bugs. It also allowed us to actually tell a managed code stories for Windows 7, since back then the .NET Framework (3.5) didn’t support any Windows 7 features.
Windows API Code Pack Version 1.0.1
A year has passed since the initial 0.8 Alpha release. Since then, we have had 3 more releases. The current version, 1.0.1, released November 18, 2009, includes a great deal of useful features that any managed code developer who is targeting Windows can use, including complete taskbar integration, extensive improvements to Windows Shell and libraries, DirectX 11, Sensor, and many more features.
There have been more than 67,000 direct downloads of the Windows API Code Pack since its release, and about the same number of downloads for other projects, such as the Windows 7 Training Kit for Developers, Flashcards.Show, Images.Show. These projects either use the Windows API Code Pack DLLs or include the Windows API Code Pack code. I guess this is where I need to acknowledge all of those who downloaded the Windows API Code Pack – thank you!
Windows API Code Pack Version 1.X
We didn’t stop working on the Windows API Code Pack! In the next few weeks/months we’ll release another version that will include bug fixing, major code cleanup and standardization, and few new features.
The team working on the Code Pack gave the existing code base a major facelift. Following the Microsoft development process, the original code was reviewed against a number of criteria, including Visual Studio FxCop analysis, updated naming conventions, improved performance, and upgrades, resulting in a much cleaner and more cohesive baseline. This baseline code will serve us internally for future releases, and I know developers will appreciate it as well.
We also added automatic testing for all the major projects (DLLs). Adding automatic testing to the Windows API Code Pack streamlines our internal development process and alerts you if any of your Code Pack customizations breaks anything along the way. The testing framework we use for the Windows API Code Pack is called xUnit. We chose xUnit over Visual Studio (VS) unit testing because unit testing is not part of the free express version of VS, and we didn’t want to limit our target audience.
While these code changes do not result in many new features, they do result in a much more robust and easy to maintain and debug code base upon which we can build going forward. We are working on a small set of new features for our next release, which will ship in few weeks.
But fear not, this is where you come into the picture. If you ever wanted to add a feature to the Code Pack, were looking for some specific Win32 API to be wrapped, or just wanted to pass us some feedback, this is your opportunity. Please send us your feedback or file a bug using the Discussions or Issue Tracker for the Windows API Code Pack.
We are especially interested in improving support for the Windows Shell, specifically in the areas of Shell integration, support for file handlers and properties, libraries, and search and indexing. We are also looking into adding social and web APIs related to Windows, as well as some fundamentals around Windows Services and Task Scheduling and Power Management. Again, if you have any additional ideas or feedback, we are listening.
The Windows API Code Pack Team
It looks like the Code Pack is no longer "alive and kicking"... It appears it now exists only in the code.msdn.microsoft.com archives, with Aug. 2010 the last time it got attention. Why is it that you just drop things and leave them in limbo like this? Why not give it the proper end-of-life it, and we, deserve? At least have the respect to your customers and fellow developers to say "we're done with this, and have moved on."
I'm still bothered by the duplication between the API Code Pack and the .NET 4.0 framework. I see no reason I should have to use both ... all the functionality should have been part of .NET 4.0 - not just a subset.
If you are compiling a list of apps using the API Code Pack, our application OpsCentral uses it. It's a personnel accountability application for fire departments written in WPF 4.0
Is there a list somewhere of all the apps that use the API Code Pack? That would be very handy.
In an ideal world, my answer would be yes, however we canot say anything at this stage about .NET 5, but we very much do want to see as much of the code pack in the .NET stack
Will it be integrated in the .NET Framework vNext (e.g.: v5.0)? I think it'd be great if this Code Pack would no require a separate package outside .NET Fx.
Thanks Robert, and a very cool idea!
We'll add this to our list.
You guys need to add a RegistryWatcher that mimics the FileSystemWatcher. All of the Registry monitoring solutions out there totally suck. There is some code in the Conmigo "Contacts.NET" solution, and that would be a great place to start. (conmigo.codeplex.com/.../Show)
It would need to be able to monitor any Hive, and throw an Event when a key is added, modified, or deleted. The event should have the FULL key, the value, and the operation type.
Seriously, it's desperately needed.
VS2010 WPF support Taskbar Jump Lists, Icon Overlay and Progress bar. It doesn’t support any of the advance Aero Peek, window clipping, or custom window preview.
WPF also support touch, for WPF.
VS2010 also includes support for Location, but not for sensors.
MFC has a ribbon support as well as touch and Taskbar
There are many features in the Windows API Code Pack that are still missing from VS, and some that simply provide more coverage. Our next release include some small but support cool features that extend the API surface coverage of .NET Framework.
How much of this functionality is duplicated in the .NET 4.0 framework?