AssemblyInfo.cs Could Not Be Found | Build Error Fixes

What This AssemblyInfo Error Means

The message about the missing AssemblyInfo file comes from the C# compiler when a project lists an AssemblyInfo file as an input, but the file is not present at the expected path. The file usually lives under the Properties folder in older .NET 4.x projects, and the compiler reads it to apply version, product name, and other assembly attributes.

In newer SDK style projects, the build often generates those attributes automatically instead of using a physical AssemblyInfo.cs file. When project settings, build scripts, or source control setup fall out of sync, the tool chain can still reference the old file while the file itself no longer exists. That mismatch leads to a compiler error about the missing AssemblyInfo file and stops the build.

This article walks through the main reasons the message appears and gives clear steps for Visual Studio, command line, and CI pipelines so you can restore a clean build without editing random files by guesswork.

Behind the scenes the project file lists every source file that the compiler should see. MSBuild reads those entries, resolves wildcards like *.cs, and then passes a full list of paths to the C# compiler. When AssemblyInfo.cs is present in that list but missing from disk, the compiler has no way to recover and it reports the error instead of skipping the file. Understanding that link between the project file and the physical folder layout helps you track down the missing file instead of changing random settings.

Common Reasons This AssemblyInfo Error Appears

Before you change project files, it helps to match the error to the type of project and build setup you use. Several patterns pop up again and again when this message shows in the build output.

• Upgraded Project Without Cleaning Old References — A legacy .NET 4.x project converted to SDK style still has compile items pointing at Properties\AssemblyInfo.cs, even if attributes are now auto generated.
• File Removed From Source Control — The AssemblyInfo.cs file once existed, was deleted or renamed locally, and the project file or build script still expects it.
• Misplaced Properties Folder — The folder structure changed, perhaps during a move to a different root directory, and the relative path Properties\AssemblyInfo.cs is no longer valid.
• Custom Build Targets — A build step, such as a code analysis tool or custom MSBuild target, hard codes a path to AssemblyInfo.cs and fails when that file is missing.
• GenerateAssemblyInfo Settings Changed — For SDK style projects, the GenerateAssemblyInfo property was turned off while no manual AssemblyInfo.cs file was added to replace the generated attributes.

The table below pairs the most common scenarios with direct actions so you can decide where to start. Reading the full error line, including the folder path, often shows whether the compiler looked under Properties or an unexpected working directory on a build agent.

AssemblyInfo.cs Could Not Be Found Fix Steps

Start with simple checks inside Visual Studio or your editor before touching MSBuild properties. Small path issues or missing files are often the fastest fixes.

• Check Project File References — In Solution Explorer, right click the project, choose Unload Project, then right click again and choose Edit. Search for AssemblyInfo.cs entries under . If the file path no longer matches your folder layout, update or remove it.
• Confirm Physical File Location — Use the file explorer in your IDE or operating system to see whether a Properties\AssemblyInfo.cs file exists. If the project needs a manual AssemblyInfo file, create the folder and file, then include it in the project.
• Run A Clean Build — In Visual Studio choose Clean Solution, then Rebuild Solution. From the command line, run dotnet clean followed by dotnet build. This clears stale intermediate files that may still reference the old path.
• Check Linked File Paths — Some projects link to a shared AssemblyInfo.cs from another directory. If you see a Link element for the file, verify that the source path is reachable on your machine and build agents.

If these checks do not clear the error, the next steps depend on whether your project uses the older non SDK project system or the newer SDK style format that ships with recent .NET releases.

Fixing Legacy Projects That Rely On AssemblyInfo.cs

Many classic .NET applications, especially those created in older Visual Studio versions, store assembly attributes in a Properties\AssemblyInfo.cs file. The compiler expects that file when the project file lists it as a compile item. When it goes missing, you can either restore the file or redirect the project to a new location.

• Restore From Source Control — If the project previously built on another machine, check your version control history and restore the deleted AssemblyInfo.cs file. Include it again in the project if needed.
• Create A Fresh AssemblyInfo.cs — In Visual Studio, right click the Properties folder, choose Add then New Item, and add a C# class file named AssemblyInfo.cs. Replace the default contents with standard attributes such as [assembly: AssemblyTitle] and [assembly: AssemblyVersion].
• Update Project Paths After Moves — When a project folder gets moved or renamed, open the .csproj file and check the path used in the Compile element. Align it with the new folder layout so the compiler can reach Properties\AssemblyInfo.cs again.

Some solutions share a single AssemblyInfo.cs file across multiple projects. In that layout, the file may live in a common folder while each project links to it. If the shared file moves or is removed, every linked project can show assemblyinfo.cs could not be found during the next build.

For shared layouts, open each affected .csproj file and look for a Compile Include that points outside the project folder. Update that path to match the new shared location, or create a new shared AssemblyInfo.cs under a stable directory that all projects can reach.

Handling SDK Style Projects With Auto Generated Assembly Info

Modern .NET SDK style projects do not generate AssemblyInfo.cs as a physical file by default. Instead, MSBuild uses properties in the project file, such as AssemblyName, Version, and Company, to create temporary attributes during the build. The GenerateAssemblyInfo property controls this behavior.

When GenerateAssemblyInfo is set to false, the SDK stops creating those temporary files and expects you to provide your own AssemblyInfo.cs. If you flip that switch in your .csproj and forget to add a manual file, the build can try to compile a non existent path and raise this message.

• Re Enable Auto Generation — Open the .csproj file and remove any false entry, or set its value to true. Save the file and run a clean build so the SDK can recreate assembly attribute files in the intermediate folder.
• Add A Manual AssemblyInfo.cs Instead — If you turned off GenerateAssemblyInfo on purpose, add a new AssemblyInfo.cs file under a Properties folder and include the attributes you need. Make sure the project has a matching Compile entry so the compiler picks it up.
• Avoid Duplicate Attributes — When you combine a manual AssemblyInfo.cs with generated attributes, you can end up with duplicate AssemblyVersion or AssemblyFileVersion values. Keep GenerateAssemblyInfo consistent across projects and only define each attribute once.

Build logs from dotnet build or Visual Studio show whether the SDK generates intermediate AssemblyInfo files under the obj directory. If you never see those paths, inspect the project file for GenerateAssemblyInfo overrides or custom targets that disable that step.

Dealing With CI, Build Agents, And Custom Tools

In some teams, the AssemblyInfo.cs problem appears only on a build server or in a pipeline while local builds succeed. That pattern points to differences between your workstation and the remote machine, especially around source control and working directory layout.

• Verify The Repository Contents — Check that AssemblyInfo.cs is tracked in the repository if the project needs it. A file that exists only in a local workspace will not reach cloud build agents.
• Review Custom Build Scripts — Pipeline scripts that call msbuild or dotnet build with extra arguments may pass a project file path that differs from your local setup. Confirm that any hard coded paths to Properties\AssemblyInfo.cs are still valid inside the agent workspace.
• Inspect Code Analysis Or Packaging Tasks — Tools such as coverage analyzers or packaging steps sometimes read assembly attributes directly. When they reference AssemblyInfo.cs by path, update those tasks to read attributes from compiled assemblies or from MSBuild properties instead.
• Test With A Minimal Command — Trigger a pipeline run that uses a bare dotnet build or plain msbuild call on the project. If that run passes, the error likely comes from a custom step and not from the core project file.

Once the CI setup matches your local project layout and source control contents, this build error should vanish in both places.

Preventing Repeat AssemblyInfo.cs Build Errors

After you fix the immediate build failure, a few small habits can reduce the chance of this error returning during later migrations or refactors.

• Favor SDK Style Projects — When you upgrade older code, move to the SDK project format and rely on generated assembly attributes unless you have a clear reason to keep a manual AssemblyInfo.cs file.
• Keep Project And Folder Layout In Sync — When you move or rename folders, review the related .csproj files and adjust any Compile Include entries that point to specific paths.
• Audit GenerateAssemblyInfo Settings — In mixed solutions, run a quick search across project files for GenerateAssemblyInfo so you know which projects use manual files and which depend on generated attributes.
• Add A Small Readme For Shared Files — If several projects share a single AssemblyInfo.cs, document that pattern in a short markdown file in the same folder so later maintainers do not delete it by accident.
• Commit New Files Early — When you add or relocate AssemblyInfo.cs in any project, include that change in a small, focused commit so CI systems stay aligned with local builds.

Once you understand what the AssemblyInfo file represents and how SDK style builds treat assembly attributes, this error turns from a confusing blocker into a quick signal that a path or property needs attention. That clarity saves time during upgrades and keeps your builds reliably repeatable on every machine.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback