Registry names describe distribution channels. A project's packages can expose different interfaces, carry different native files and require different installation steps.
Here is a concrete example from the Windows SDK projects maintained by TitanCSA. Their sources, examples and package guides have been grouped in a central SDK catalogue.
Start with the package identity
For Interceptor, these are two distinct NuGet packages:
| Package | Purpose | Example version |
|---|---|---|
Interceptor.SDK |
Managed SDK interface | 1.0.0 |
Interceptor.Native |
Native SDK source integration | 1.4.22 |
For a .NET application, the managed package can be added with:
dotnet add package Interceptor.SDK --version 1.0.0
The native package is installed from Visual Studio's NuGet Package Manager Console, in a compatible native project:
Install-Package Interceptor.Native -Version 1.4.22
Those version numbers belong to their respective packages. Matching the project name or choosing the largest version number is insufficient to choose the right interface.
The Node.js package has another exact identity:
npm install interceptor-sdk@1.0.0
Always copy the identifier from the project's installation guide. A shorter, similar-looking name in a public registry may belong to a different publisher.
Check the native boundary
A package installation is one part of a Windows device integration. Check the product README for:
- The supported Windows version and architecture.
- Whether the interface loads a native DLL and how that DLL is deployed.
- Whether live operations require a matching product driver and administrator access.
- Which device families and operations have actually been qualified.
Browser Control SDK, for example, uses the WebView2 Runtime and does not require an input driver. Interceptor's live device operations have their own driver requirements. Requirements should be checked per product.
The package interfaces can expose different subsets of an underlying SDK. A list of language bindings is useful for finding a starting point; the API guide and examples establish the supported operations.
Use the project guide as the index
The catalogue now groups each project's sources, installation commands, licences and examples together. Product applications and drivers retain their own repositories and Releases.
The guide lists the registry, exact package name and installation command. Commands marked as planned still need publication or verification. vcpkg, Conan and Conda also have TitanCSA source indexes/channels; their guides explain the required configuration. These custom channels are separate from acceptance into Microsoft’s curated vcpkg catalogue, ConanCenter or conda-forge.
An existing pinned configuration may still refer to an older source location. For that case, the repository includes an archive URL replacement map, and the current vcpkg guide supplies the updated baseline.
Keep licensing and test scope alongside the command
SDK/application source, kernel drivers and bundled dependencies can have separate terms. Some evaluation drivers have time limits; unrestricted use and OEM/redistribution terms are agreed separately. Installing a wrapper package does not complete those steps.
The checks behind these guides include Windows x64 source builds, synthetic contract checks and inert native lifecycle tests. Real hardware and live-driver qualification remain product-specific. Consult the project's validation notes before choosing it for a device integration.
If you try one of the SDKs, useful feedback includes the exact package/version, Windows build, device/connection mode, a small reproducible example and the expected result. The appropriate project repository is the place for that technical discussion.
Links: SDK catalogue · Interceptor project and requirements · Browser Control SDK.
Disclosure: Generated by an AI assistant on behalf of the project maintainer, using the linked project documentation and checked package records.
Top comments (0)