Why do custom App_Plugins files (views, CSS, JS) go missing or 404 after installing a new NuGet package on Umbraco Cloud?

A customer installs a new NuGet package (e.g. an image-processing or caching package with no static assets of its own), deploys to an Umbraco Cloud environment, and suddenly an unrelated custom backoffice package — like a custom dashboard — stops working. Files under App_Plugins/{YourPackage} are missing (checked via Kudu), return 404, or load with the wrong MIME type (e.g. "Refused to apply style ... because its MIME type ('') is not a supported stylesheet MIME type").

This is a known pattern and is not caused by the newly installed package directly — installing any package that triggers a rebuild/republish can expose an existing gap in how your own custom App_Plugins files are set up to survive a build.

Root Cause

Per Umbraco's official package documentation:

The default way files get delivered into App_Plugins is via a .targets file bundled inside a NuGet package. On build, those files are copied from the NuGet cache into App_Plugins.
If a custom package's App_Plugins files were added manually (not shipped via a proper NuGet .targets/RCL mechanism) and are not explicitly marked to be copied to the output/publish directory in the .csproj, a build or dotnet clean can drop them from the compiled output.
On Umbraco Cloud, every deployment effectively rebuilds/republishes the site. Installing a new NuGet package is enough to trigger this, which is why the symptom appears to coincide with an unrelated package install — the new package isn't the cause, it's just the trigger for a rebuild that exposes the missing configuration.

How to Confirm

Check Kudu (site/wwwroot/App_Plugins/{PackageName}) on the affected environment to confirm the files are actually absent (not just a caching/browser issue).
Check if the affected files belong to a custom package the customer maintains or an official Umbraco or marketplace package with its own release/support channel.
Check how the files were added to App_Plugins originally — manually copied into source control, or generated via dotnet new umbraco-extension/RCL.

How to Fix

Option 1 — Explicitly include the files in the build/publish output. In the project's .csproj:

xml

<ItemGroup>   
  <Content Include="App_Plugins\**">
          <CopyToPublishDirectory>Always</CopyToPublishDirectory>   
  </Content> 
</ItemGroup>

Option 2 (recommended for packages with more than a couple of files, e.g. dashboards) — Move the static assets into a Razor Class Library (RCL) and map it back to the App_Plugins web path using StaticWebAssetBasePath:

xml

<Project Sdk="Microsoft.NET.Sdk.Razor">
   <PropertyGroup>
  <StaticWebAssetBasePath>App_Plugins/MyExtension</StaticWebAssetBasePath>
   </PropertyGroup>
</Project>

This lets the standard ASP.NET Core static web assets pipeline manage publishing reliably, instead of relying on manual copy rules.

Common config mistake: don't mix a wildcard Content Include="App_Plugins\**" with separate explicit <Content> entries for individual files in the same folder — this has caused conflicts/duplication in past cases. Use one approach or the other, not both.

Config files count too: this isn't limited to views/CSS/JS. Third-party plugin folders can also contain JSON config files (e.g. App_Plugins/umbracocommerce/config/order.editor.config.json) that need their own explicit Content Include if they're not covered by the vendor's own RCL/.targets delivery.

After applying a fix, let the deploy finish before re-checking. In several past cases the customer checked immediately after triggering a rebuild, saw the files still missing, and assumed the fix hadn't worked — when in fact the build/deploy pipeline just hadn't finished propagating yet.

Known Package-Specific Gotchas

Umbraco Forms: the Cloud starter kit's .gitignore ships with commented-out lines that, if left in place, silently exclude App_Plugins/UmbracoForms/ and Views/Partials/Forms/Themes/default/ from git entirely — custom Forms field-type files placed in those default paths never even reach Cloud, regardless of CopyToOutputDirectory settings. If there are missing files inside those two paths, check .gitignore first. The workaround used in one case: create a new Forms theme instead of adding files into the default theme folder.
Umbraco Deploy: App_Plugins/Deploy ships via NuGet and should not be referenced in the .csproj — but in one case those files were still missing from git on a specific environment and had to be committed manually per-environment. Separately, if a custom plugin's package.manifest points to a JS asset with a trailing query string (e.g. ?lastMod=...), it can break Smidge's minification/bundling and blank out the backoffice dashboard when debug mode is off. Removing the query string fixed it.
Disk space: in one extended case, the Kudu /home disk was full of leftover temp files, which blocked deployment entirely — unrelated to csproj/RCL config. Worth a quick Kudu disk-space check if the standard fixes don't resolve things. Note also that UDA (Umbraco Deploy Artifact) files and App_Plugins files are separate mechanisms with separate failure modes — don't assume fixing one fixes the other.

Notes for Support / Umboto

Don't conclude "deploy is working correctly" just because the deployment pipeline reports success — a successful deploy can still omit files that aren't configured to be copied to the publish output. Check Kudu for the physical files before ruling this out.
Any package install can trigger the rebuild that exposes it.
If the missing files are specifically under App_Plugins/UmbracoForms or the Forms default theme folder, check .gitignore before assuming it's a csproj copy-rule problem.
If root cause can't be confirmed from Kudu + a look at the .csproj/.gitignore, escalate to a human rather than repeating generic guidance.

References

Good Practice and Defaults (Umbraco Docs) — App_Plugins delivery via .targets, files lost on dotnet clean.
Creating a Package (Umbraco Docs) — NuGet packaging and App_Plugins structure.