AntDeploy: deploying .NET apps to IIS, Docker and services from Visual Studio

A deployment extension rather than a deployment server

AntDeploy is a Visual Studio extension, and that single fact explains most of its design. The repository description calls it tools to deploy applications to a remote server across IIS, Windows services, Linux services and Docker, supporting both .NET Framework and .NET Core, with rollback and incremental deploy.

The workflow it implies is a developer clicks a deploy action in Visual Studio and the build lands on a target. There is no separate orchestration server in the picture, no environment abstraction and no approval stage. For a team of a handful of developers deploying to a staging or production web server, that is a short path to a working release, and it is the reason the project is popular in that setting.

The trade is that a deployment pipeline is a shared, audited, repeatable thing, and an extension is a personal tool. One person can deploy from their machine and another cannot, and the history of what was deployed lives on the server rather than in a place the team controls.

The plugin is published to the Visual Studio Marketplace, and the README gives three separate download links, one for Visual Studio 2022, one for Visual Studio 2019 and one for older versions. The homepage is also a marketplace listing, under the name nainaigu.AntDeploy. Several source projects in the repository sit in folders named after those Visual Studio generations, AntDeploy2019/ and AntDeploy2022/, which suggests the same codebase is compiled per Visual Studio version.

The four deployment targets and what each supports

The feature list in the README names four target types, and it is precise about which application models each one handles.

Docker deployment is supported, with the .NET Core case called out. IIS deployment is supported for both .NET Core and .NET Framework. Windows service deployment is supported for both as well. Linux service deployment is supported for .NET Core.

The asymmetry is the useful part of that list. A .NET Framework application is a Windows-only thing, so its absence from the Linux row is not a gap. The .NET Core row is where the interesting constraint sits, because a Linux service target means the deployment has to happen somewhere that can run that service, which is where the agent comes in.

Beyond the target types, the README lists a second group of capabilities in bold as the differentiating ones: incremental publishing, one-click rollback, an ignition step, publishing a selected set of files, and a view of the deployment history. Those five are what separate this from a plain publish-and-copy, and rollback plus history are the two that matter operationally.

Incremental publishing matters for large .NET Framework applications, where replacing the whole folder on every release means a long stop-the-world copy and a window where the site is half updated. Publishing only what changed keeps that window short. The deployment history answers the question that comes up after every incident, which is what went out and when.

The agent and why service targets need one

Publishing to a Windows service or a Linux service requires an agent on the target server, and the README links two issue threads that explain the details: one on installing the agent service on a Windows server, and one on why publishing to a Windows service or a Linux service requires the agent to be installed.

The reasoning is not hard to reconstruct from the target list. A web deployment can be done by pushing files into a directory, because an IIS site serves whatever is on disk. A service is different: there is a process running, it holds the files open, and the new version cannot replace the old one while the host still has them mapped. Stopping the service, replacing the binaries, restarting it and confirming that it came back is a sequence of privileged operations on the target machine, and the agent is what performs them.

That design has a consequence for the deployment model. The agent is a persistent service on the target, so the server needs a place to put it, and that place needs to be reachable from wherever the developer is running Visual Studio. The README also documents a batch agent update demo, which tells you the project expects a fleet of agents to be kept current.

The alternative would have been to do the service control over a remote shell, which the project does not appear to do. Pushing an agent and managing its version is a real operational commitment, and it is the price of the one-click service deployment.

Using AntDeploy outside Visual Studio

The README lists support for using the tool independently of Visual Studio, with cross-platform support for Windows and macOS, and links an issue thread on how to do it. There is also a demo for publishing a front-end project to IIS this way, and a separate section for the mac experience with a note that the mac build is distributed through the project group files rather than through the marketplace.

This matters more than a normal cross-platform claim, because the Visual Studio extension is a click in an IDE and the standalone mode is the part that can be scripted. A pipeline that needs to publish from a build agent rather than from a developer's desktop depends on that mode existing, and the presence of an AntDeployApp/ folder and a CMD/ folder in the repository layout points to a command line entry point alongside the Visual Studio front ends.

The mac caveat is worth noting for anyone planning a cross-platform rollout. The build for macOS is not distributed the same way as the other platforms, it comes from a group file, which is a distribution friction point that a pipeline operator will have to solve once.

The video series linked in the README is recorded and hosted on Bilibili, and there is a mind map with the project structure. Both point at a documentation model that lives outside the repository, in issue threads and in video, which is worth keeping in mind when you are deciding whether to standardise on it.

Where AntDeploy is the wrong tool

The first limitation is the release cadence. The recent releases are v7.54 from 2023-04-23, v7.53 from 2023-04-11 and v7.52 from 2023-03-24, three releases in under a month and then nothing tagged for more than three years. The last push was on 2026-08-12 and the repository is not archived, so code is still landing, but the packaged extension a developer installs is old.

The second is that an extension is per-developer. The Visual Studio marketplace install gives each person the tool on their machine, and the behaviour of a deployment depends on the machine it runs from. There is no server-side record of intent, no separation of duties and no scheduled deploy.

The third is the requirement for an agent on the target for service deployments, which was covered above and which turns a single-file publish into a two-machine operation with its own version management.

The fourth is documentation. The README is written in Chinese, the tutorials live as issue threads in the AntDeployAgent repository, and the demos are video. A team that does not read Chinese will be working from translations of a fairly scattered body of material, and the English description in the repository metadata is a summary rather than a manual.

The fifth is the surface area. The repository contains AntDeploy, AntDeploy2019, AntDeploy2022, AntDeployAgent, AntDeployAgentLinuxService, AntDeployAgentService, AntDeployAgentWindows, AntDeployAgentWindowsService, AntDeployApp, AntDeployWinform, plus DLL/, CMD/ and MigrationBackup/ directories. That is a large footprint for a deployment tool, and it means the extension, the agent and the standalone app are separate pieces that have to be kept in step.

How AntDeploy compares with Octopus Deploy and with MSDeploy

Octopus Deploy is the standard alternative and the difference in approach is architectural rather than a matter of features. Octopus is a server with a web interface and a deployment process that runs on the server, so every release is executed by the same system, triggered by a pipeline or a scheduled deployment, and recorded centrally. AntDeploy runs the deployment from the developer's machine, so there is nothing central to record it in.

The consequence shows up in audit and coordination. A team with several environments, a change window and more than one person deploying needs a server tier, and Octopus provides one where AntDeploy deliberately does not. For a single developer or a two-person team shipping to one staging box, the extra machinery of a deployment server is overhead AntDeploy avoids.

MSDeploy, which the topic tags include, is the underlying Windows deployment technology that web publishing in Visual Studio uses. AntDeploy builds on that kind of mechanism and adds the target handling for services and containers, the incremental behaviour, the rollback and the history. Compared with calling MSDeploy directly from a script, AntDeploy gives you the Visual Studio integration and the service handling, at the cost of the plugin dependency.

The other comparison is with plain CI publishing. A GitHub Actions or Azure Pipelines job that packages the application and copies it to a target needs no plugin and no agent, and it gives you a deployment history in the pipeline log. What it does not give you is the service restart handling, which is the piece the agent exists to solve.

Licence, maintenance and what to check before adopting it

The licence field on the repository records Apache-2.0, and the LICENSE file sits at the root next to the AntDeploy.sln solution. That is a permissive licence with an explicit patent grant, and the README states that all of the source code is open, with the source tree in the repository.

The repository is not archived and the last push was on 2026-08-12, so maintenance has not stopped, but the version story is thin: no tagged release in more than three years, and the marketplace listing at the homepage is what a user actually installs. A team pinning a build of this extension should record which marketplace version it validated rather than assume a moving target.

Four things are worth checking before making this the deployment path. Whether the marketplace build matches the Visual Studio generation your team uses, since there are separate listings for 2022, 2019 and older. Whether the agent can be installed and kept current on the target servers, and how that is done at scale, since the batch update demo implies a fleet. Whether the rollback path is tested on a real deployment, since a rollback that has only been exercised in a demo is not a rollback. And whether the standalone mode is usable from a build agent, since that is what determines whether releases can be automated at all.

The last point decides the shape of any adoption. Used as a developer convenience, the tool is a reasonable choice. Used as the deployment mechanism for a product, it needs the standalone mode to work reliably, and that is the part to verify first.

Editorial conclusion

AntDeploy suits a .NET team that deploys from Visual Studio to a mix of IIS sites, Windows services, Linux services and containers, and that wants a rollback path without building a release pipeline first. It is the wrong tool for a team standardised on a deployment server such as Octopus Deploy, since the extension is the whole product and there is no server tier to coordinate several environments. Before adopting it, check the release cadence against the Visual Studio version you use, because the extension ships a separate build per Visual Studio generation, and confirm the agent requirement for service targets, since the README explains that publishing to a Windows or Linux service needs an agent installed on that server.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. yuzd/AntDeploy on GitHub