Introduction

project.lock.json was the dependency lock file generated by the early project.json era of .NET Core tooling. Its job was to record the exact package graph chosen during restore so builds stayed predictable across machines, target frameworks, and runtimes.

What the File Was For

In the old .NET Core workflow, developers described dependencies in project.json. When dotnet restore or a NuGet restore ran, the tool resolved every direct and transitive dependency and wrote the result to project.lock.json.

That generated file captured details such as:

• The exact version selected for each package
• The target framework the package applied to
• Runtime-specific assets when a runtime identifier was involved
• Whether a dependency came from another project or from a package feed

The key point is that project.lock.json was not the place where you declared intent. It was the place where restore recorded the resolved result.

Here is a simplified example of an old project.json file:

1{
2  "dependencies": {
3    "Newtonsoft.Json": "9.0.1"
4  },
5  "frameworks": {
6    "netcoreapp1.0": {}
7  }
8}

After restore, the lock file expanded that short declaration into a full dependency graph. A generated file might include package names, resolved versions, and framework-specific sections that made restore deterministic for the next build.

Why It Mattered

Without a lock file, two restores performed at different times could resolve slightly different transitive dependencies. That can produce hard-to-reproduce bugs, especially when a dependency range allows newer versions. project.lock.json reduced that uncertainty by pinning what restore had already chosen.

The workflow looked like this:

dotnet restore
dotnet build

dotnet build depended on the resolved package graph already written by restore. If the dependency declaration changed, restore regenerated the lock file.

This also helped with multi-targeted projects. If one project targeted more than one framework, the lock file kept separate dependency information for each target. That mattered because a package might expose different assemblies for net451, netcoreapp1.0, or other targets.

Generated File, Not Hand-Written Config

A common mistake was treating project.lock.json like a configuration file. It was not intended for manual editing. Even if you changed a version in the lock file, the next restore would overwrite it based on project.json and feed resolution rules.

If you wanted a different package version, you changed the declaration and then restored again:

1{
2  "dependencies": {
3    "Newtonsoft.Json": "9.0.1",
4    "Serilog": "2.3.0"
5  }
6}

Then:

dotnet restore

The important mental model is simple:

• 'project.json described what your project wanted'
• 'project.lock.json recorded what restore actually resolved'

What Replaced It

Modern SDK-style .NET projects do not use project.lock.json. When Microsoft moved from project.json to *.csproj plus PackageReference, the tooling shifted to files such as obj/project.assets.json. In newer workflows you may also see packages.lock.json, which serves a more explicit lock-file role.

For example, a modern project typically declares packages in the project file:

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net8.0</TargetFramework>
4  </PropertyGroup>
5
6  <ItemGroup>
7    <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
8  </ItemGroup>
9</Project>

So if you are searching a current repository and cannot find project.lock.json, that usually means the project uses the newer SDK-style build system instead of the older project.json stack.

Common Pitfalls

• Editing project.lock.json by hand. Restore regenerates it, so the change does not persist in a reliable way.
• Confusing it with project.assets.json or packages.lock.json. They belong to newer restore models and are not interchangeable.
• Assuming its presence in all .NET projects. It is tied to an older tooling generation, not modern SDK-style projects.
• Chasing package bugs in the wrong file. Dependency intent lives in project.json or *.csproj, not in the generated lock output.

Summary

• 'project.lock.json was the generated dependency lock file for older project.json-based .NET Core projects.'
• It stored the resolved package graph, including transitive dependencies and framework-specific results.
• The file supported reproducible restores and builds across environments.
• Developers generally should not edit it by hand.
• Modern .NET projects usually use project.assets.json and optionally packages.lock.json instead.