# Metasign: an open-source e-contract system on ASP.NET Core and Angular

> Metasign is an electronic contract solution that covers contract creation, online delivery and return of completed documents, storage and tracking, reporting and batch creation, with an ASP.NET Core backend and an Angular front end. It suits a team that wants the mechanics of e-signature under its own roof, and it is not a turnkey product with a hosted service behind it.

**ncc-erp/metasign** — An e-contract solution to bring superior experience in contract engagement and operational management

- Repository: https://github.com/ncc-erp/metasign
- Website: https://www.metasign.com.vn
- Stars: 581 · Forks: 12
- Language: HTML
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ncc-erp-metasign

## What the product is actually for

Metasign is described as an e-contract solution intended to bring businesses and individuals a better experience when engaging in contracts and to optimise operation and management systems. The homepage is metasign.com.vn, which places it as a product from a Vietnamese vendor, and the support community is hosted on a Mezon invite link rather than on a forum.

The functional scope is listed as five capabilities: creating different types of contracts easily, delivering and getting back completed contracts via online channels, storing, tracking and managing contracts in a more convenient manner, generating reports, and creating contracts in a batch.

That list describes the mechanics of electronic contracting rather than the legal layer around it. There is nothing in the repository about identity verification services, certificate authorities, qualified electronic signatures, or trust service integration. If the requirement is a signature that satisfies eIDAS or an equivalent regime, the repository does not show where that comes from, and the readme's screenshot tutorial is the only user-facing documentation offered.

The audience implied by the repository is therefore a developer or an IT team that wants to build or self-host a contract workflow, rather than a business user signing contracts. The project ships as source code with setup instructions for Visual Studio, Visual Studio Code and PostgresSQL, and the primary language listed for the repository is HTML, which reflects that the visible artefact is a web interface.

The licence is MIT, and the project describes itself as an open-source e-contract solution for both businesses and individuals.

## Two repositories in one directory, and where the parts live

The top-level listing explains the shape of the project better than the prose does.

There is an aspnet-core/ directory holding the backend, and an angular/ directory holding the front end, which is why the setup instructions have separate Backend Setup and Frontend Setup sections and why the front end is a separate repository referenced by name: the instructions tell you to go to the metasign folder, then ncc-erp-metasign, then angular. That means the clone you get from the backend repository does not contain the front end source, and the front end has to be fetched separately.

Inside the backend, the path given for the startup project is aspnet-core/src/EC.Web.Host, and the project you set as startup is named metasign.Web.Host. So the solution contains several web projects and one of them has to be chosen explicitly, which is a hint that the code is organised around a host project with libraries underneath it rather than as a single deployable.

The rest of the root tells you about the build pipeline. There are pipelines-BE.yml and pipelines-FE.yml, so backend and front end are built by separate pipeline definitions, and config-pipelines.yml sits alongside them. There is conf_s.yml at the root, which appears to be configuration for the CI system, and rename.ps1, a PowerShell script for renaming, which suggests the project is branded per customer and the name Metasign is one configuration of it.

There is also a package.json at the root alongside package-lock.json, but it is not the Angular application's manifest. Its entire content is a single dependency, angular2-signaturepad at version 4.0.2 or newer. That is the drawing library behind the signature capture, and the fact that it sits at the repository root rather than inside angular/ is a small oddity that will show up when you try to build the front end and find that the root manifest does not describe it.

The _screenshots/ directory holds the images the readme embeds, including the high level design diagram and three screenshots of the interface.

## Getting the backend running on PostgreSQL

The prerequisites are spelled out in full: Visual Studio 2022, the .NET 6 SDK or ASP.NET Core Runtime, Visual Studio Code, Node.js 14.21.2 with npm, and PostgreSQL.

The clone is a single command, and it fetches the backend repository into a folder you create yourself, which the instructions call metasign:

```bash
git clone https://github.com/ncc-erp/metasign.git
```

The backend is then opened in Visual Studio 2022 through File, then Open, then Project/Solution, and the NuGet packages are restored from Solution Explorer. The startup project is set by going to aspnet-core/src/EC.Web.Host and setting metasign.Web.Host as the startup project.

The database connection lives in appsettings.json under ConnectionStrings, and the Default entry is a standard PostgreSQL connection string pointing at localhost on port 5432 with a database named metasign:

```json
{
"ConnectionStrings":  {
"Default":  "Host=localhost;Port=5432;Database=metasign;User ID=yourUID;Password=yourPW;Pooling=true;"
},
// ... other settings ...
}
```

You replace yourUID and yourPW with your own credentials, and the instructions say to open SQL Server to see the newly created database, which is a leftover from a version of this project that targeted SQL Server rather than PostgreSQL. The actual mechanism is PostgreSQL, and the step that follows creates the schema.

Schema creation is done from the NuGet Package Manager Console, with the default project changed to src/EC.Web.Host, and then a single command is run:

```bash
Update-database
```

That is an Entity Framework Core command, and it means the migrations live in the backend project rather than in a separate SQL script, so the schema follows the entity model. It also means the tool needs to reach the database named in the connection string, which is the reason the credentials have to be right before you press it.

The backend is then started with F5, or with Ctrl+F5 for start without debugging, and the default backend port is http://localhost:44311/.

## The Angular front end and the build commands

The front end is a separate repository that you open from the folder structure with the code command:

```bash
code .
```

The Angular CLI is then installed globally, and the front end dependencies are installed:

```bash
npm install -g @angular/cli
```

```bash
npm install 
```

Note the trailing space in the second command as written in the readme, and note that this npm install runs in the angular directory, which is where the actual application manifest with the Angular dependencies lives, unlike the root package.json.

The front end is served with npm start, and a production build is npm run build. The readme frames both under Building and Running, and the sequence for running the full stack is: start the backend from Visual Studio Code or the command line, then start the front end with npm start.

That ordering matters because the two are separate processes on separate ports. The backend listens on 44311 by default, the Angular development server serves the interface and proxies or points at the API, and the front end is the only part with a visible user interface.

The presence of angular2-signaturepad at the root of the repository tells you where the signature capture sits. The readme's screenshot tutorial walks through three screens: the main application, an admin page and a basic user page. The admin and basic user distinction suggests role-based access, with contract templates, users and reports managed on one side and signing on the other.

Node.js 14.21.2 is the version the prerequisites name, which is a Long Term Support line that is several major versions behind current releases. Angular itself has moved on considerably since that point, so the front end is built against an older toolchain than a new project would use.

## Where Metasign is the wrong choice

The first limitation is the legal layer, and it is the one the repository is silent about. Electronic contracting in most regulated jurisdictions depends on identity verification, a qualified trust service and a signature that a third party can verify after the fact. The readme describes none of that. What it describes is a workflow for creating a document, sending it, getting it back signed, and storing it. A team that has to answer a customer's question about the legal validity of a signature it collected will not find the answer in this repository.

The second is the release history. The published releases are v1.0.1 from 2023-09-29, v1.0.2 from 2023-10-04 and v1.0.3 from 2023-11-03, while the last push to the repository was on 2026-06-16. So the code has moved since the last tagged release, and the tag most people would install is nearly three years old. If you are evaluating this, you should be evaluating the main branch, not v1.0.3.

The third is the build and runtime age. .NET 6 and Node.js 14.21.2 are the stated prerequisites, and both are out of support. An organisation with a current platform baseline will be pinning old runtimes to run this, or doing the upgrade work themselves, and the Visual Studio 2022 workflow described in the readme assumes a Windows workstation rather than a container or a Linux CI runner, even though the front end and the database are otherwise cross-platform.

The fourth is that this is source code, not a service. There is no hosted option, no per-signature pricing, no notification delivery, no SMS or email provider wired in, and no monitoring. Everything an operator would normally have is something you build. The pipelines-BE.yml and pipelines-FE.yml files show that a CI setup exists, but the readme says nothing about deployment targets.

The fifth is documentation. The user-facing guidance is a sequence of screenshots and a short getting started, and the repository does not include a data model, an API reference or a description of what a contract template contains. The screenshot tutorial is linked from the readme as the way to learn how to use the product, which is an admission that the workflow has to be inferred from pictures.

## Conclusion

Metasign fits a team that wants contract templates, online delivery, tracking and reporting implemented on infrastructure it controls, with an ASP.NET Core backend on PostgreSQL and an Angular front end that a JavaScript team can work on. It is the wrong choice if you need a legally recognised qualified signature or identity verification with a certification authority behind it, since the repository documents no such integration, and it is the wrong choice if you want a hosted product rather than software to deploy. Before adopting it, read the connection string section of appsettings.json and confirm the PostgreSQL instance you point it at, note that the default backend port is 44311, and consider that the last push was on 2026-06-16 with the newest published release being v1.0.3 from 2023-11-03.

## FAQ

### What is Metasign?

Metasign is an e-contract solution for creating contracts, delivering and receiving completed contracts online, storing and tracking them, generating reports and creating contracts in a batch. It is MIT licensed and consists of an ASP.NET Core backend with an Angular front end.

### How do I set up the Metasign backend?

Clone the repository, open the solution in Visual Studio 2022, restore the NuGet packages, set metasign.Web.Host in aspnet-core/src/EC.Web.Host as the startup project, set the Default connection string in appsettings.json to your PostgreSQL instance, then run Update-database in the Package Manager Console with src/EC.Web.Host as the default project, and start with F5.

### How do I run the Metasign front end?

Open the separate ncc-erp-metasign angular repository, install the Angular CLI globally with npm install -g @angular/cli, run npm install to fetch dependencies, then start it with npm start. A production bundle is produced with npm run build, and the backend serves on http://localhost:44311/ by default.

### What database does Metasign use?

PostgreSQL. The Default connection string in appsettings.json uses Host=localhost;Port=5432;Database=metasign, and the schema is created with the Entity Framework Update-database command. The readme's mention of opening SQL Server to check the new database is a leftover from an earlier version of the project.

### What licence is Metasign released under?

MIT, with the licence file at the root of the repository. The last push was on 2026-06-16 and the newest published release is v1.0.3 from 2023-11-03, so the tagged release is older than the current main branch.

## Sources

- [License: MIT](https://github.com/ncc-erp/metasign/blob/main/LICENSE)
- [ncc-erp/metasign on GitHub](https://github.com/ncc-erp/metasign)
- [Project website](https://www.metasign.com.vn)
- [README](https://github.com/ncc-erp/metasign/blob/main/README.md)
- [Releases](https://github.com/ncc-erp/metasign/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ncc-erp-metasign