vscode-solidity: one extension for compiling, linting and generating Nethereum code from Solidity

The problem the extension solves: Solidity work without leaving the editor

Solidity is the language used in Ethereum to create smart contracts, and vscode-solidity is a Visual Studio Code extension that treats it as a first-class language rather than a plain text file. The feature list reads like the everyday annoyances of contract development: syntax highlighting, snippets, compilation, code completion across contracts and libraries in the current file and in referenced imports, goto definition, find all references across the project, hover information, and code actions such as changing the compiler, formatting an address and adding an SPDX licence.

The audience is a Solidity developer who wants the editor to know about the toolchain, not just the syntax. Compilation is available for the current contract through the command palette with Solidity : Compile Current Solidity Contract, bound to F1 plus that command, or F5, and for all contracts through Solidity : Compile all Solidity Contracts, bound to Ctrl with F5 or Cmd with F5 depending on the keyboard.

Two details set the tone of the project. First, it is published as a Visual Studio Marketplace extension under the identifier JuanBlanco.solidity and warns explicitly about extension impersonations, telling users to check the publishing history, and pointing out that the VS Code Marketplace has ten years of history while OpenVSX has five. Second, the same codebase ships as a standalone language server, so the editor is an option rather than a requirement.

Four routes to a solc binary, and which one your machine can reach

Compiler selection is the most configured part of the extension, and it is where most setup friction sits. The documentation states that four ways of choosing a compiler are supported: Remote, Local, NodeModule and Embedded. Available compiler versions live in the solc-bin repository at binaries.soliditylang.org, and the extension also ships a list of versions in solidity-versions.txt in its repository.

Remote download pulls the compiler from the solc-bin repository, and the version is set through a user or workspace setting. The setting key takes a value such as 'latest' or a pinned release string:

"solidity.compileUsingRemoteVersion" : "latest"

A local file keeps the compiler on your machine. You download it from binaries.soliditylang.org and point the setting at the extracted soljson file:

"solidity.compileUsingLocalVersion" : "C:\\Users\\JuanFran\\Downloads\\soljson-v0.8.18%2Bcommit.87f61d96.js"

The node module route uses the solc npm package in your project, and the extension looks for it in the configured node_modules at the project root:

npm install solc

The default module package name is solc, but the settings allow another node module that contains a compiler. There is also a per-file case, where a specific contract is compiled with a compiler other than the default, which the documentation describes through the context menu and per-file settings.

The practical consequence: if you are on a locked-down network with no access to binaries.soliditylang.org and no npm registry, the remote route fails and the local route depends on having fetched the file already.

Project detection by config file, and the src/ plus lib/ convention

Mono repo support works by recognising the project from its configuration files. The extension looks for remappings.txt, foundry.toml, brownie-config.yaml, truffle-config.js, hardhat.config.js and hardhat.config.ts. Those markers are how it knows a workspace holds a Solidity project at all, and how it decides which directory tree belongs to the project rather than to some unrelated folder in the same repository.

The layout convention is stated plainly and will surprise people coming from a Hardhat-first workflow. Solidity files are expected in the src/ directory and libraries in the lib/ directory, and libraries follow the same structure inside. If your sources live at the repository root, as many older projects do, the extension will not pick them up in the way you expect, and moving or symlinking them is usually less painful than fighting it.

Compilation also supports EIP82, which covers the dappfile and dependency packages used by the older Ethereum tooling. There is a matching code action that triggers from an import when the file targets a specific compiler version and you see the issue highlighted, which is a faster route than opening the settings each time.

Beyond the source layout, the extension can download source code and ABI from Etherscan, which saves a trip to a block explorer when you need to look at a deployed contract.

From compilation output to Nethereum files

The most differentiated feature is code generation through Nethereum. The documentation describes a default template for a Nethereum service along with DTOs generation, and the generated files can be produced automatically on compilation rather than only on request.

The manual route uses the command palette. After a compilation you open the contractName.json file from the bin folder, run the command Solidity: Code generate from compilation output, and the files are produced from that compilation artifact. Automatic generation on compilation is the faster loop when the template already matches your project, and it removes the step of remembering to regenerate after every change.

The binding between source and output is the compilation artifact itself, which is why the bin folder and contractName.json matter: they are the interface between the compiler run and the generated service code. That also explains the limitation. Generation quality is bounded by what the compiler emitted and by the Nethereum template, so a project with unusual contract structures will still need the generated files reviewed by hand.

Linting runs through Solhint or Ethlint, and the documentation links both projects. Two linters rather than one keeps the choice open for teams that already have a preferred configuration, and it means rule sets from either can be applied inside the editor.

Snippets for ERC drafts and a small set of project interfaces

Writing an interface from scratch for a standard you only half remember is a common waste of time, so the extension ships approved ERCs and most drafts marked as work in progress. You type erc in the editor and pick the example or interface from the completion list.

The same mechanism covers project interfaces. The current release includes the interfaces for Uniswap V2, and typing uni lists them. The stated reason is that as smart contracts become more interoperable, being able to examine the interfaces you plan to integrate with saves real time.

The extension takes a conservative line on coverage. If an ERC or a project interface is missing, the documentation asks for a pull request, and it says only established projects will be included. That is a reasonable gate, but it means the snippet library is not complete, and a team working with a less common standard will still be writing the interface by hand.

Compiler optimisation is the other snippet-adjacent piece of advice in the documentation, and it is framed by intent rather than by a fixed number: optimise for how many times you intend to run the code, with lower values optimising more for initial deployment cost and higher values optimising for execution.

Running the language server outside Visual Studio Code

The editor extension is packaged from the same source as a standalone language server, and the repository includes a separate document for that build path. Installing it globally gives you a binary that speaks the standard protocol over standard input and output:

npm install -g vscode-solidity-server

vscode-solidity-server --stdio

The package.json exposes that binary through a bin entry pointing at the built server script, and the build pipeline for it is a separate script chain that compiles the CLI, adds a shebang and adds a command wrapper, so the global install exposes a usable command rather than a bare file.

This matters for teams that do not live in Visual Studio Code. The repository also carries a README-NeoVim.md, so an editor outside the Visual Studio family is an anticipated case. The practical benefit is that completion, navigation and diagnostics come from the same Solidity analysis code, which keeps behaviour consistent across editors instead of diverging into per-editor reimplementations.

Release cadence, engine requirements and licence

The extension is published under the MIT licence, with the licence text in a License.txt file at the root of the repository. That is the permissive end of the spectrum and carries no particular obligation for teams embedding it or redistributing the packaged extension, subject to keeping the licence notice.

The package manifest names the extension solidity with publisher JuanBlanco, and requires Visual Studio Code at version ^1.77.0 or newer through the engines field. The published versions use a three-part scheme: 0.0.187 on 2025-11-04 and 0.0.185 on 2025-08-26. The last push to the repository was on 2026-05-28, so commits have continued after the most recent tagged build, and the extension available from the marketplace is therefore an older artifact than the working tree.

The build is TypeScript with tsc for compilation and tsup for the CLI bundle, tests run under mocha with nyc coverage, and the package ships only the compiled CLI directory in its files list. Contributors also have a README-DEVELOP.md, so the development setup is documented separately from the user documentation.

For an organisation deciding on adoption, the version scheme is worth a moment of thought: a 0.0.x version line for a tool that most teams will keep installed for years means the marketplace release is the unit of upgrade, and the gap between that release and the current tree can grow.

Editorial conclusion

Adopt vscode-solidity if you write Solidity in Visual Studio Code and want compilation, Nethereum generation and linting in one place, and if you can live with the src/ and lib/ layout convention and pin a compiler per workspace. Skip it if you need a different editor or if your build is driven entirely by Foundry, Hardhat or Brownie on the command line, since the extension detects those projects but does not replace their toolchains. Before switching, check that the pinned solc version you need is listed in solidity-versions.txt, and confirm which of the four compiler sources, remote, local, node module or embedded, your environment can reach.

Frequently asked questions

Official sources

1. Issues
2. juanfranblanco/vscode-solidity on GitHub
3. License: MIT
4. README
5. Releases