ubisoft/Sharpmake: the project generator built for thousands of Visual Studio configurations

Scale is the whole argument

Sharpmake is a generator for Visual Studio projects and solutions, and the README opens by placing it against two names you already know, saying it is similar to CMake and Premake, but that it is designed for speed and scale.

The scale claim is concrete. Sharpmake has been used at Ubisoft to generate several thousands of `.vcxproj`, `.csproj` and `.sln` files in a matter of seconds, and each of these projects can support a large number of Visual Studio configurations as well.

That last clause is the one that matters. A single project with four platforms, three optimisation levels, two rendering APIs and a level editor variant is a hundred and twenty configurations, and a hundred and twenty project files that somebody has to keep consistent. The README describes the target plainly, the development of multi-platform games, where the number of platforms, the different levels of optimization, the multiple rendering APIs on PC and the level editor can quickly multiply the number of configurations a given code base must support. Sharpmake generates all of those at once, quickly, which makes it trivial to regenerate the entire project.

The origin story explains the design. Sharpmake was developed internally at Ubisoft for Assassin's Creed 3 in 2011, and after experimenting with the other existing tools it became clear that none of them were performant enough to generate the number of configurations needed, at least not in a trivial way, and a custom generator was needed.

Why the scripts are C#

Sharpmake uses the C# language for its scripts, hence the name, and the README explains the benefit as the obvious one. You can edit your scripts in Visual Studio, or in Visual Studio Code, and benefit from the default C# tooling of auto-completion, refactoring and the debugger.

That is a stronger argument than it first appears. A generator whose scripts are a bespoke language means a new language to learn, a language with no editor support, and a script you cannot step through when it produces the wrong project file. A generator whose scripts are C# means the generation logic is ordinary compiled code, in a language the team already writes, with the tooling already installed.

And it is not only for Visual Studio. Sharpmake can also generate makefiles and Xcode projects, and it can be run natively on any modern operating system that supports a recent version of the dotnet runtime. So the C# choice is about the authoring experience, not about the target platform, which is why the same scripts produce a Visual Studio solution on a developer's machine and a makefile for a build server.

Building it and running a sample

The build and run section is short because the tool is a .NET solution.

git clone https://github.com/ubisoft/Sharpmake.git

You clone the Git repository and open the `Sharpmake.sln` solution in the root folder. Then there are two debugging paths, and they are the way to learn the tool.

To debug Sharpmake using a sample, you set the `Samples` project as the startup project and choose from the dropdown list which sample you want to run. To debug using a functional test, you set the `Sharpmake.FunctionalTests` project as the startup project and choose the functional test you want to run.

Having both in the same solution is a deliberate design. A sample shows you what the generated output looks like for a given kind of project, and a functional test shows you what the generator produces for a given input and whether that output is correct. The repository has both `Sharpmake.UnitTests/` and `Sharpmake.PublicApiTests/`, the second of which suggests that the public surface of the library is treated as something with a contract that has to be kept, and there is a `UpdateVerifiedPublicApi.bat` script in the root, which is the mechanism for accepting an intended change to that surface.

The solution also carries a `Sharpmake.sln.DotSettings`, which is the Rider style settings file, and the `SamplesDef.json` at the root, which appears to be the definition of what the samples cover.

The extension system, and the consoles that could not ship

The More Platforms section tells a story that is more interesting than a feature list.

Sharpmake originally had support for game consoles, but Ubisoft pulled it out because those could not be open sourced. Sharpmake now has an extension system that allows support for these consoles to be added back at runtime.

So the tool is designed on the assumption that some platforms are commercially sensitive, and the extension system is how a studio that has such a platform uses Sharpmake without the open source project containing it. That is a clever separation, and it is the reason the extension layout is prescribed in such detail.

The recommended folder layout has a `SharpmakeExtended` directory containing `Sharpmake` for the core, `Sharpmake.Platforms` and `Sharpmake.Extensions` for your additions, a `Directory.build.props` and a `SharpmakeExtended.sln`. The core folder contains all the files of the Git repository, and it is commonly called Sharpmake core. If you plan to version your extended project under git, a git submodule is the way to pull the core in.

The two extension folders are explained in a single sentence that is worth repeating. There is no difference between platforms and extensions, these two folders are only used to tidy or split things a little. What matters is the mechanism: `Sharpmake.Application.csproj` from the core automatically adds the `.csproj` files from those folders to its dependency list, which means they are built and copied to its output folder automatically, and hitting Start Debugging just works.

The samples directory is the specification

The `samples/` directory in the repository is the most useful thing in the project for learning it, because the sample names describe the problem space.

There is a C# hello world, a C++ command line application, a C++ project that forces a package reference, C# projects for imports, a Visual Studio extension and a WCF service, a C++ project with a custom analyser and one with a custom build step, a project about configure order, a compile command database example, and FastBuild samples, one of them deliberately duplicating a file.

Then there is the platform coverage, with samples for Android, iOS, Linux, Rust, Xcode and Clang, an assembly sample, an assembly one written in NASM, an events sample, a plain HelloWorld, and a JumboBuild sample that is presumably about the very large number of configurations that motivated the project in the first place.

Two more files sit alongside them, a `Directory.Build.props` at the samples root and a `samples/CSharpHelloWorld` style layout, so the samples also demonstrate the expected directory conventions rather than only the API.

For a tool whose output is a pile of project files, samples are the documentation that actually teaches, and this set covers both ends of the problem, one trivial project and one enormous configuration matrix.

The scripts around the code

The root of the repository is a set of PowerShell and Python scripts, and they describe how the project is built and checked.

`Compile.ps1` builds the tool, and there are four run scripts: `RunSharpmake.ps1` to invoke the generator itself, `RunSample.ps1` and `RunProcess.ps1` to run a sample or a process, and `UpdateSamplesOutput.bat` to refresh the expected output of the samples. `extract-vcpkg.ps1` pulls out the vcpkg dependency, which tells you that the Windows toolchain is fetched rather than vendored.

The test entry points are `functional_test.py` and `regression_test.py`, both Python, so the functional tests that the developer workflow runs from Visual Studio are the same ones the scripts drive. `UpdateVerifiedPublicApi.bat` is the counterpart for the public API, and `SamplesDef.json` holds the definition the samples and the update scripts share.

The rest of the tree is organised by concern, with `Sharpmake.Application/`, `Sharpmake.Generators/` for the output generators, `Sharpmake.PublicApiTests/`, `Sharpmake.UnitTests/`, `Sharpmake.FunctionalTests/`, `Sharpmake.Platforms/`, plus `tools/`, `docs/`, a `NuGet.config`, a `Directory.Build.props` and an `AGENTS.md`.

Where this is the wrong choice

The first wrong case is a small project. If you have one project with one configuration, a hand written `.vcxproj` is a file you can read, and a generator plus a solution plus a scripting model is a lot of machinery for it.

The second is a team that wants a build system. Sharpmake generates project files, it does not compile, and the project description is explicit that it produces project definition files such as Visual Studio projects and solutions, GNU makefiles and Xcode projects. If your problem is that the build is slow, this does not address it.

The third is a C++ only shop with an existing CMake setup that works. The case for Sharpmake is the configuration matrix, and a project that already generates its project files from CMake is solving the problem in a different way, and Sharpmake would be a second source of truth rather than a replacement.

The fourth is an open source project that wants to support a console platform. The extension mechanism exists, but it assumes you have a platform definition that is not in the core, and the platform list is in the documentation under `docs/Platforms.md`, so the work is in understanding what the core already provides and what your studio has to supply.

On the state of the project, the releases are 1.8.0 on 2026-09-01, 1.9.0 on 2026-10-09 and 1.9.1 on 2026-10-13, the last push was on 2026-10-14, and the repository is not archived. The licence is Apache-2.0, and the code is C#.

Editorial conclusion

Adopt Sharpmake if you generate Visual Studio projects and your configuration matrix has outgrown hand written project files, since the case for it is thousands of .vcxproj and .sln files across many platforms and optimisation levels, and the C# scripting means your existing editor tooling applies. Do not adopt it for a small project, since a single hand written project file beats a generator with a solution to build, and do not expect it to replace your build system, since it generates project files rather than running the compile. Verify first that the configuration count is actually your bottleneck, that the console platform support you need can be supplied through the extension mechanism, and that you can live with the current release line, since 1.9.0 and 1.9.1 landed in October 2026 and the project moves quickly.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ubisoft/Sharpmake on GitHub