aliyun-openapi-net-sdk: the V1 Alibaba Cloud SDK for .NET

A V1 SDK the project itself tells you to leave

The most important line in this README is the first one. The Alibaba Cloud V1.0.NET SDK has entered the basic security maintenance phase and is no longer recommended for use. New users should use the V2.0.NET SDK directly, and users who have already integrated V1.0 are advised to migrate. The V2.0 SDK lives in a different repository, alibabacloud-csharp-sdk, with its own help centre documentation and OpenAPI developer portal.

That framing changes what kind of article this is. This is not a library recommendation. It is a description of a codebase you may already own, or one you are considering and should not start with.

The release record supports the same reading. The repository has a single published release, v1.5.2 from 2019-08-20, and the last push was on 2026-10-21. Commits continue to land, but no new package version has been published through that path, so what a consumer installs today is the 2019 build unless they work around the release process.

The topics on the repository are dotnet, net, sdk and v1, and the version marker in the topic list is the giveaway. The V1 and V2 SDKs differ in their service and credential models, so a migration is a code change, not a version bump, and that is the practical cost the README is pointing at.

The audience for the rest of this piece is a developer looking at this code in 2026 and deciding what to do with it.

One NuGet package per product on a shared core

The repository is a collection of assemblies rather than a single library, and the top-level listing shows the shape immediately. There is a directory per Alibaba Cloud product, from aliyun-net-sdk-ecs and aliyun-net-sdk-cdn and dozens more product directories alongside them, all sitting next to aliyun-net-sdk-core, which is the shared runtime.

The consequence for a consumer is that you do not take a dependency on the cloud. You take a dependency on the product you actually call. The README states this directly, telling you to install the ECS NuGet package when you are using ECS, and to add the --version flag if you want a specific version rather than the latest one.

The core package is the one that carries the client machinery, and the badges point at aliyun-net-sdk-core on NuGet as the central artifact. The repository also has its own test project, aliyun-net-sdk-core.Tests, and a solution file for the.NET Standard 2.0 build, aliyun-net-sdk-core.netstandard20.sln.

Requirements are stated plainly:.NET Framework 4.5 and above,.NET Standard 2.0 and above, and C# 4.0 and above. That is a wide target range, which is the point of a V1 SDK, since it predates the modern.NET line and had to run everywhere.

The product directories also tell you how large the API surface is. Each product package carries its own model namespace with a dated version in it, such as Aliyun.Acs.Ecs.Model.V20140526, which is the API revision the generated classes were built against.

Install the product package, not the whole cloud

Two installation routes are given, and the README marks the .NET CLI one as recommended:

    dotnet add package aliyun-net-sdk-ecs

    Install-Package aliyun-net-sdk-ecs

The first is the .NET CLI command and the second is the Package Manager command for older Visual Studio setups. Both are shown for the ECS package, and the same pattern applies to every other product package.

What the installation does not do is configure anything for you. There is no appsettings section, no credential file and no environment variable convention described here. The credentials are passed in code, which is the design of this generation of SDK, and it is worth being clear about the consequence: an access key id and secret end up in source code, in configuration, or in whatever your application already uses for secrets.

The README has one security note on this point, and it is worth repeating rather than paraphrasing. It recommends using the AccessKey of a RAM user to access Alibaba Cloud services, to increase the security of your account. That advice is about limiting blast radius, and it applies whether you use this SDK or the V2 one.

There is also a troubleshooting service, reachable through the api.alibabacloud.com troubleshoot page, which provides OpenAPI diagnosis to help developers locate problems through a RequestID or an error message. The RequestID is the piece to know about, since it is the handle support asks for when a call fails.

DefaultAcsClient and the three-step call

The usage model is described as three steps, and the client object is the centre of it. You create and initialize a DefaultAcsClient instance, you create a request and set parameters, and you initiate the request and handle the response.

The example shows the shape with an ECS call, and it is worth reading closely because the credential handling is visible in it:

using Aliyun.Acs.Core;
using Aliyun.Acs.Core.Profile;
using Aliyun.Acs.Core.Exceptions;
using Aliyun.Acs.Ecs.Model.V20140526;

class Program
{
    static void Main(string[] args)
    {
        // Create a client used for initiating a request
        IClientProfile profile = DefaultProfile.GetProfile(
            "<your-region-id>",
            "<your-access-key-id>",
            "<your-access-key-secret>");
        DefaultAcsClient client = new DefaultAcsClient(profile);

The region id and the two key values are passed to DefaultProfile.GetProfile, which returns an IClientProfile, and the profile is what the client is constructed from. Everything downstream, including which endpoint the client talks to, follows from that profile, which is why the region string is the first placeholder and not an afterthought.

The request and response types are strongly typed and product-specific. DescribeInstancesRequest has a PageSize property, the response is a DescribeInstancesResponse, and the total count is read off it. The request classes carry an API date in their namespace, so the generated surface is pinned to a specific revision of the product API rather than to a moving target.

Errors are split into two exception types, ServerException for a rejected request and ClientException for a failure on the calling side, and the example catches both separately. That split is useful in practice, because a server error means your request reached the API and a client error usually means it did not.

BearerToken credentials for the CCC product

Not every Alibaba Cloud product authenticates with an access key pair. The README carries a second example for CCC, the Cloud Contact Center product, and it uses a bearer token instead:

using Aliyun.Acs.Core;
using Aliyun.Acs.Core.Profile;
using Aliyun.Acs.Core.Exceptions;
using Aliyun.Acs.CCC.Model.V20170705;

class Program
{
    static void Main(string[] args)
    {
        // Create a client used for initiating a request
        var profile = DefaultProfile.GetProfile("<your-region-id>");
        var bearerTokenCredentialProvider = new BearerTokenCredentialProvider("<your-bearertoken>");

        var client = new DefaultAcsClient(profile, bearerTokenCredentialProvider);

The profile is created with only a region id here, and the credential is supplied separately through a BearerTokenCredentialProvider, which is then passed as a second argument to the DefaultAcsClient constructor. The client API supports both forms, so a product that issues short-lived tokens does not force you to fake an access key pair.

The model namespace follows the same dated pattern, Aliyun.Acs.CCC.Model.V20170705, and the request type in the example is a ListPhoneNumbersRequest. The README also notes that you need to install the CCC product NuGet package to run that demo locally, which is the same per-product rule as for ECS.

The practical takeaway for anyone reading this code is that credential handling is per-product and per-call-shape in this SDK. A codebase that talks to several Alibaba Cloud products will have more than one credential path to maintain, and that is one of the things the V2 SDK is meant to simplify.

Configuration topics documented one file at a time

Beyond the calls themselves, the repository points at a set of short documents under docs/ that cover the configuration questions an integrator hits. They are listed by name in the README: Requirements, SSL Verify, Debug, Proxy, Timeout, Product Nuget Package, Log, Client and Credentials, and Endpoint.

That list is a good map of the trouble spots. SSL verification is separate, which means it can be disabled and is a decision someone has to make deliberately. Proxy support is a separate document, which matters for any deployment behind a corporate egress. Timeout is configurable, which matters for long-running operations. Endpoint selection is documented, which is where the region profile and any per-product overrides come from. Debug and Log are separate, which tells you there is more than one place to look when a call behaves unexpectedly.

The Client and Credentials document is the one to read first if you are inheriting this code, because the client and the credential are the two things that differ from a plain HTTP client and the two things most likely to be misconfigured.

For API details, the README points at the product list on alibabacloud.com, and for generated example code the OpenAPI developer portal at api.alibabacloud.com, which can call the cloud product APIs online and generate SDK example code dynamically. That portal is arguably more useful than the repository for day-to-day API work, since the API surface changes independently of the SDK release cycle.

The repository also keeps release notes in aliyun-net-sdk-core/ChangeLog.md, which is where the detail for each published version lives, and the top level carries both a CHANGELOG file and a CHANGELOG.md.

Apache 2.0 with a licence classification caveat

The README's licence section points at the Apache License 2.0, and the badge row in the header also displays Apache 2.0. The LICENSE file is at the repository root, and the project runs a FOSSA licence analysis with a status badge, which is the usual way a company tracks that a large tree of dependencies still passes its own compliance check.

One caveat comes from the repository metadata rather than the README. The licence field there is recorded as a custom licence that GitHub cannot classify, with a pointer to the LICENSE file. In practice that means the Apache 2.0 reference in the README and the actual text in the LICENSE file are the things to read, and where a repository like this spans hundreds of product packages, it is worth confirming that the licence of the core package and the licence of a product package are the same thing rather than assuming it from the badge.

There is no other legal wrinkle to raise, and it is better to say plainly that this is a permissive licence with no copyleft obligation on consumers. Vendors can use it inside a proprietary product without disclosing anything, subject to keeping the notice and the licence text.

For a project in security maintenance the licence question is rarely the deciding factor anyway. The deciding factor is the absence of published security fixes in a component that holds cloud credentials.

Editorial conclusion

Adopt aliyun-openapi-net-sdk only if you are already integrated against it and want to hold the dependency steady while you schedule a migration. Do not start new work on it, because the project states it has entered basic security maintenance, publishes no release after v1.5.2 from 2019, and points new users to the V2.0 .NET SDK in the alibabacloud-csharp-sdk repository. Verify first that the product package you depend on exists for the product you call, that the region id, access key id and access key secret placeholders are filled with credentials you are willing to have in the process, and that the endpoint your client resolves matches the region you pass to DefaultProfile.GetProfile.

Frequently asked questions

Official sources

1. aliyun/aliyun-openapi-net-sdk on GitHub
2. Issues
3. Project website
4. README
5. Releases