OneScript runs 1C scripts on .NET without the 1C platform

The language without the platform

The project describes itself as an independent cross-platform implementation of a virtual machine that executes scripts in the 1C:Enterprise language, and the second half of that sentence is the important one: the 1C:Enterprise libraries are not used, and installing the 1C:Enterprise system on the target machine is not required.

Put plainly, the README calls it a tool for writing and executing programs in the 1C language without using the 1C:Enterprise platform. That is a meaningful constraint in both directions. A specialist can write automation in a language they already know, and a machine that has never had 1C installed, and may not be allowed to have it installed, can still run the result.

The productivity argument is made in the same terms. OneScript lets you create and execute text scenarios in a language familiar to anyone who works with 1C:Enterprise, and using a familiar language for script automation raises the productivity of a specialist because automating manual operations becomes simpler.

The name and the pronunciation are documented too. The project is called OneScript, it can be shortened to 1Script when writing, and it is pronounced as one script. The primary language of the repository is C#, the licence is MPL-2.0, the default branch is `develop`, and the project site is oscript.io, which is where the main information, the releases and the technical documentation live.

A bundled script library and its package manager

The distribution ships with a set of the most commonly used packages already included, and the rest of the ecosystem lives in a separate repository, oscript-library, which is open to everyone. There is a package manager for it, opm.

That design has a practical consequence for the runtime. A OneScript installation is not just an interpreter, it is an interpreter plus a set of libraries, and opm exists to manage that library set. A deployment therefore has two things to keep in step, the runtime version and the library set, which is what the package manager is for.

The repository also contains an English version of the documentation, `README-EN.md`, next to the main `README.md`, which is in Russian.

Linux packaging comes in two shapes

The current branch, v2.x, is based on .NET 8.0, and the Linux distribution is offered as two ZIP archives with different trade-offs.

The self-contained variant includes the .NET runtime in the archive and has no external dependencies, and the framework-dependent variant is a more compact archive that requires the .NET Runtime 8.0 to be installed. The choice is between a larger download that runs anywhere and a smaller one that needs a runtime on the host.

The installation steps are download, extract into a convenient directory, and set the execute permission:

  chmod +x oscript

The older v1.x LTS line is distributed as a `.deb` package and works on Mono. The package installs the minimally required Mono components, but the debugger needs `mono-complete`, and the README calls that out specifically for Ubuntu and Debian, with the instruction to install `mono-complete` from the official Mono Project repository rather than from the distribution repositories, and a link to the Mono Project download page for the per system instructions. The reason given for the emphasis is that breakpoints do not fire without it.

So there are two supported generations in the README, and they are not interchangeable: a Mono based LTS branch and a .NET 8 based current branch.

macOS needs quarantine and signing cleared

The macOS route is also a ZIP archive, x64 or arm64, from the releases page or the project site, extracted into a convenient directory, and then a small amount of extra work that is specific to the platform.

The commands are:

  chmod +x ./oscript
  xattr -d com.apple.quarantine *.dylib oscript
  codesign -s - ./oscript

Each line has a reason. The first makes the launcher executable, the second clears the quarantine attribute that macOS applies to downloaded archives and which otherwise blocks the binary from running, and the third ad-hoc signs the executable so the loader accepts the unsigned dylibs next to it.

The Windows path is the simplest of the three, since it is an interactive download of an installer from the official site or the Releases section, followed by running it and clicking through. It is the only platform where the README asks for nothing at the shell.

Building from source needs .NET 8 and, optionally, a C++ compiler

The manual build section is the longest part of the README, and it starts with two prerequisites. The .NET SDK 8.0 is required, since the target framework of the project is `net8.0`, and a C++ compiler is needed only for building the native bridge `ScriptEngine.NativeApi`, which supports external components of the 1C NativeApi standard. On Windows the simplest route is MS Build Tools or Visual Studio with the C++ desktop development component, and if you have no C++ compiler there is a parameter for that, described below.

The build itself runs through MSBuild with the `Build.csproj` script in the repository root, and the commands can be run either through `msbuild` in a Developer Command Prompt or through `dotnet msbuild` for a cross-platform invocation.

The targets are worth reading, because they describe the whole delivery: `CleanAll` clears the results of previous builds, `BuildAll` produces the binaries for the distribution, the FDD, SCD and debugger, plus the native components when a C++ compiler is present, and there are separate targets for each part, `MakeCPP`, `MakeFDD`, `MakeSCD` and `BuildDebugger`. `GatherLibrary` downloads and assembles the base set of libraries, which are opm, asserts, logos, fs, tempfiles and cli. `PrepareDistributionFiles` assembles the full distribution contents including libraries and documentation, `PackDistributions` packs them into ZIP archives for all supported platforms, `BuildDocumentation` generates the platform reference in markdown and json, `CreateNuget` and `PublishNuget` handle the NuGet packages, and `Test` runs the unit and acceptance, or BSL, tests.

The build parameters are `VersionPrefix`, whose default is 2.0.0, an optional SemVer `VersionSuffix` such as beta-786, `NoCppCompiler`, which when true skips the native components, and `Configuration`, which defaults to Release with `LinuxDebug` for a debug build on Linux. All build artefacts land in the `built` directory at the root of the repository.

Two concrete invocations are given, one to build the distribution contents:

dotnet msbuild Build.csproj /t:CleanAll;PrepareDistributionFiles

and one to set the version explicitly:

dotnet msbuild Build.csproj /t:CleanAll;PrepareDistributionFiles /p:VersionPrefix=2.0.0

A second, older build path in the Makefile

The repository root also carries a Makefile, and it describes an older and simpler shape of the project.

It points at `src/1Script_Mono.sln`, so it builds the Mono solution rather than the .NET 8 one, with `Any CPU` and `Release` as the platform and configuration. The `dist` target restores NuGet packages, runs msbuild, and copies the DLLs, EXEs and CFG files into `dist/bin` and `dist/lib`, and it builds the opm package into `dist/lib/opm/opm.os`.

The `install` target copies the binaries into `${PREFIX}/share/oscript/bin` and installs two launchers, `oscript` and `oscript-cgi`, into `${PREFIX}/bin`, with `PREFIX` defaulting to `/usr`. There is a matching `uninstall` target that reverses it.

So the Makefile is the path for a Mono era build and a system-wide install, while `Build.csproj` is the path for the current .NET 8 distribution. For a reader, the more useful observation is the presence of `oscript-cgi`, which tells you the runtime is designed to be driven by a web server as well as from a terminal.

The rest of the repository is the usual project furniture, with `src/`, `tests/`, `install/`, `docs/`, a `Jenkinsfile`, `appveyor.yml`, `.travis.yml`, a `CODESTYLE.md`, `verify_stylecode.ps1`, `coverals.io.bat` and `gitlog.sh`.

Where OneScript fits, and what it is not

The decision to adopt this comes down to one question, which is whether the machine that has to run your automation can have 1C:Enterprise on it. If it can, and you are licensed for it, then scripting inside the platform gives you the platform's own libraries, and OneScript is the more complicated option. If it cannot, or the licence is the problem, then OneScript is a way to keep the language and drop the platform.

The boundary the project draws is the libraries. The README is explicit that the 1C:Enterprise libraries are not used, so any script that depends on them will not run here. That is a real constraint for anyone porting an existing configuration, and it is the first thing to check in a migration.

Two other things are worth weighing. The first is that the ecosystem is split across two runtime generations, a Mono based 1.x LTS and a.NET 8 based 2.x, and libraries and scripts have to work with whichever one you pick. The second is the documentation situation: the main README is in Russian, the project site carries the technical documentation, and an English README sits alongside the Russian one in the repository.

The practical next step is therefore to read the Russian README and the site documentation for the specific area you need, and to test the scripts you intend to port against the version line you intend to run. The project is clearly alive, with releases v2.2.0 from 2026-09-05, v2.1.0 from 2026-07-01 and v2.0.1 from 2026-04-20, and a last push on 2026-10-19.

Editorial conclusion

Adopt OneScript when you automate work in the 1C:Enterprise language and you need the scripts to run on machines where the platform is not installed or not licensed. Do not adopt it for programs that depend on the 1C platform libraries themselves, since the project states those are not used. Verify first which packaging you want, since the self-contained archive is larger and the framework-dependent one needs .NET Runtime 8.0, that the v1.x Mono based line is the LTS branch while v2.x on .NET 8 is the current one, and that the version you take is v2.2.0 from 2026-09-05, given that the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. EvilBeaver/OneScript on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases