Windows API Code Pack: Where is it? [closed]

A

6

121

Why has itself and the evidence it ever existed been removed?

Only a half year ago it was promoted on channel9 as Something that should be in everyones pack -- today the Microsoft Archive is "retired" and totally keeps quiet that the API code pack ever existed.

Auburta answered 6/6, 2014 at 12:17 Comment(2)

Maybe this is of interest as well. – Thurber 7/7, 2014 at 5:59

I know that this is an old question but it turned up early in my search results so I thought I'd add my $0.02. I haven't researched extensively but I think that the Windows API Code Pack may have been officially superseded by the Windows 10 WinRT API Pack. – Presswork 8/2, 2021 at 2:2

A

70

I can't answer the question of why, nor do I wish to speculate (maybe someone else closer to the issue can tell us what happened), but thankfully it's not completely gone. It looks like the binaries have been reuploaded to NuGet by other developers, although note that none of the packages are official ones from Microsoft.

The following packages were uploaded by NuGet user aybe:

As usual, to install them:

Install-Package WindowsAPICodePack-Core
Install-Package WindowsAPICodePack-ExtendedLinguisticServices
Install-Package WindowsAPICodePack-Sensors
Install-Package WindowsAPICodePack-Shell
Install-Package WindowsAPICodePack-ShellExtensions

Animato answered 26/6, 2014 at 1:10 Comment(7)

There are a number of similar packages on NuGet created by different persons. Obviously none of these packages is an “official” one, and none of them is listed in the “Microsoft and .NET” feed. – Animation 26/6, 2014 at 8:3

Can anyone say with any certainty that these packages are the same as what used to be available straight from Microsoft? – Unvalued 23/9, 2015 at 18:51

There is now a 'Microsoft.WindowsAPICodePack-Core' from Microsoft. – Propene 21/4, 2016 at 14:1

@DefenestrationDay: Assuming you are talking about this one, that was the one I originally linked to, and it's not from Microsoft, it's from someone who happened to have copies of just two of the packages and not everything. – Animato 21/4, 2016 at 14:10

Although not from Microsoft, it is reassuring that aybe's Nuget package is an upload of source code, not a binary. For example, for common file dialogs, you can build it yourself, and trace the calls to see that the actual work is done via built-in .NET dlls ("shell32.dll", etc.) See ShellNativeMethods.cs for the DllImport definitions. – Gefen 1/4, 2018 at 20:16

.. also see Core\Interop\CoreNativeMethods.cs. Defines some entry points in "user32.dll", "kernel32.dll" and "gdi32.dll". Searching solution, there are about a dozen files with DllImport lines. But it looks like Shell & Core NativeMethods are the main ones. – Gefen 1/4, 2018 at 20:29

aybe's github : github.com/aybe/Windows-API-Code-Pack-1.1 – Haft 16/9, 2018 at 1:35

B

16

Someone has uploaded it to GitHub.

Boehike answered 27/7, 2014 at 10:3 Comment(0)

I

15

A zip file containing the same files as the original executable self-extractor (i.e. the source, binaries and docs) is located here: https://github.com/jamie-pate/KeepSync/blob/master/contrib/Windows%20API%20Code%20Pack%201.1.zip.

Imprest answered 30/7, 2014 at 23:35 Comment(1)

This should be the proper answer. Unpacked and added the binary references. Working like a charm – Arnold 24/11, 2015 at 17:0

U

1

Here's link (or this link) to original Windows API CodePack 1.1.

Unalterable answered 30/12, 2014 at 17:17 Comment(2)

Oh, I remembered that there's a bug in "Windows API Code Pack 1.1\source\WindowsAPICodePack\Core\Interop\TaskDialogs\TaskDialogNativeMethods.cs" file. You should swap the following lines: "mainIcon = i;" and "spacer = IntPtr.Zero;". So, the order is: "spacer = IntPtr.Zero;" and then "mainIcon = i;". – Unalterable 30/12, 2014 at 18:49

Maybe because these are links to privately hosted EXE files. 1) Some people do not trust exe files from unofficial sources (even though that they are signed). 2) This answer has a lifetime of the subscription to these hosts. Maybe other reasons... – Rectus 2/5, 2019 at 8:58

S

1

The original links are dead, but an Microsoft employee has uploaded the v1.1 original codepack to nuget. Search for winapicp at nuget, or use this link: Windows API Code Pack for Microsoft .NET Framework

Shebeen answered 28/7, 2016 at 7:58 Comment(4)

What makes you believe it was a Microsoft employee? – Auburta 28/7, 2016 at 12:39

Because within the MS hosted forum this was marked as the answer by the moderator, who itself IS a MS employee social.msdn.microsoft.com/Forums/windowsdesktop/en-US/… – Shebeen 2/8, 2016 at 11:54

@user3082079 just because its marked as an answer by a MS employee does not mean the package is officially published by a MS employee. Even if he/she is there is no term guarantee that its officially released by MS. Note that a MS employee does not represent MS for all the work he/she publishes. MS Moon light project allows employees to publish their own work that's not under MS's name. – Massachusetts 12/9, 2016 at 19:48

Quick note that this package does not contain PDBs. – Imprest 9/2, 2018 at 10:32

I

0

Seems like someone also posted it on CodePlex.

Indophenol answered 12/9, 2014 at 22:20 Comment(5)

That's not the whole pack, just some contrib extensions. – Amenra 22/9, 2014 at 3:0

Looks to me to have all the core libraries sans the samples and tests – Indophenol 22/9, 2014 at 15:49

You're right it actually does contain the pack itself contrary to what the description would make you believe. It is only version 1.0 though so it's missing some things. – Amenra 26/9, 2014 at 0:58

Please don't use that project as it's really outdated (it's basically vanilla 1.0, as correctly pointed out by kjbartel). – Arathorn 7/12, 2014 at 18:53

Small correction: it's 1.0 plus the contributions as stated in the description. – Arathorn 9/12, 2014 at 18:33

Recommended topics

Hot tags