MSB3030: Could not copy the file "…WindowsAppSdk.AppxDeploymentExtensions.Desktop-EventLog-Instrumentation.dll" because it was not found — the file is there; the path to it is too long for the copy step to read.

The cause is your folder, not your project. Windows' classic path limit is 260 characters (MAX_PATH), and the Windows App SDK build copies files with very long names into deep obj/ and bin/ subfolders. Past the limit the copy fails, and the failure is reported as the source file not being found. Move the project to a short path — the same project that failed at a 270-character path built in 9.9 seconds from C:\short\.

The error

From the first smoke build of the untouched template (abridged — the build log kept the file name; the full line shows the complete source path):

MSB3030: Could not copy the file "…\WindowsAppSdk.AppxDeploymentExtensions.Desktop-EventLog-Instrumentation.dll" because it was not found.

Why it happens

A MAUI project targeting Windows builds into a path like obj\Debug\net10.0-windows10.0.19041.0\win-x64\, and the Windows App SDK adds package folders and file names that are sixty or seventy characters each. Start from a project folder that is already long — a scratch directory under a user profile, a nested workspace — and the sum crosses 260.

Some parts of the toolchain handle long paths and some do not, so the failure lands on whichever step first hands a too-long path to an API that refuses it. Here that step was a copy, which is why the error is MSB3030 and why its message misleads: the copy task asked for a file, the operating system said no, and MSBuild reported "not found". The Android and web targets built the whole time — shorter output paths, ordinary file names. "Works on Android, fails on Windows" can be your folder name.

The fix

Put the checkout somewhere short. That is the whole change:

git clone https://github.com/rahulvyas777/clinic-live C:\src\clinic-live
cd C:\src\clinic-live
dotnet build src/ClinicLive.Pocket -f net10.0-windows10.0.19041.0

Two alternatives, both weaker. Windows 10 and later can lift the limit for applications that opt in (the LongPathsEnabled policy plus a manifest flag per executable), but not every tool in a MAUI build opts in, so it may move the failure rather than remove it. And you can shorten the intermediate path with BaseIntermediateOutputPath, which helps only until the next long package name arrives. A short folder fixes every case at once.

What the AI got wrong: three retries, a self-contained flag and a clean of obj/ — every hypothesis was about the project, and the project was fine. When an error names a file that plainly exists, suspect the path before the file.

Where it bit us

Season three, Part 1: the plan, in the smoke build of the freshly scaffolded template, before the first tag. There is nothing to check out for this one — the fix was a folder, and every tag from pocket-02 on in the repo was built from a short path. The lesson: an environment can fail a build that the code would pass.

Frequently asked

Why does MSB3030 say a file was not found when the file exists?
Because the copy task asked Windows for a path longer than 260 characters and the operating system refused it. MSBuild reports the refusal as the source file being missing. Check the full path length before checking the file.
How do I fix MSB3030 on a Windows App SDK or .NET MAUI build?
Move the project to a short folder such as C:\src\yourapp and build again. The Windows App SDK produces very long file names inside deep obj and bin folders, so a long project path pushes the total past MAX_PATH. Enabling long paths in Windows can help, but not every build tool honors it.
Why does the Android target build when the Windows target fails with MSB3030?
The Android output uses shorter folder names and ordinary file names, so the same project folder stays under the 260-character limit for it. Only the Windows App SDK's long package and file names cross the line.

More decoded errors in the Fixes category; the season this opened starts at Part 1.