I have an Umbraco 13 project (13.5.2, also tried to update to 13.6.0) where smidge fails to generate it's cache with an error:

[12:34:07 ERR] Connection id "0HNA1TCKBP0T2", Request id "0HNA1TCKBP0T2:0000000B": An unhandled exception was thrown by the application.
System.IO.FileNotFoundException: No such file exists /umbraco/assets/css/umbraco.min.css (mapped from /umbraco/assets/css/umbraco.min.css)
File name: '/umbraco/assets/css/umbraco.min.css'
   at Smidge.SmidgeFileSystem.GetRequiredFileInfo(IWebFile webfile)
   at Smidge.FileProcessors.PreProcessManager.<>c__DisplayClass8_0.<ProcessFileImpl>b__0()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.CreateValue()
   at Smidge.FileProcessors.PreProcessManager.ProcessFileImpl(IWebFile file, BundleOptions bundleOptions, BundleContext bundleContext)
   at Smidge.FileProcessors.PreProcessManager.ProcessFile(IWebFile file, BundleOptions bundleOptions, BundleContext bundleContext)
   at Smidge.FileProcessors.PreProcessManager.ProcessAndCacheFileAsync(IWebFile file, BundleOptions bundleOptions, BundleContext bundleContext)
   at Smidge.Controllers.SmidgeController.Bundle(BundleRequestModel bundleModel)

https://cdn.discordapp.com/attachments/1334850297603821568/1334850582518825011/image.png?ex=679e07fb&is=679cb67b&hm=5d0a19c60737a6792e46ed5da08d135f6ac48db480abf9d5ee8cddd42599087c&

Did you drop in

UseStaticWebAssets

somewhere?

nooooo, that's illegal 😛

I agree, but you might need it lol

I tried all combinations of the cache buster already, but that doesn't help. Also, it is a very empty Umbraco, created from the 13.5.2 dotnet template. So I made no changes to the Program.cs. As far as I know, you should not (and need not) to add UseStaticFiles because Umbraco takes care of that.

Yeah I agree, it was one of the solutions I came across, but it was a v9 post, so lots has changed since

left field, but check for a web.config file that has autogenerated and has a location set for the aspNetCoreModuleV2

<location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\IrishLuxuryTours.Web.exe" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="inprocess" />
    </system.webServer>
  </location>

can't remember if it was a smidge issue like you had.. but removing the limiting location sorted our issue. https://cdn.discordapp.com/attachments/1334850297603821568/1335005681023193099/image.png?ex=679e986d&is=679d46ed&hm=3fc4d64d0489380d9adf41cbc6b5fa7818ccca3d6919993b3235e406926eb7ea&

> Umbraco is a Razor Class library, so the files are not physically present in my project. Until you publish it... then they're whipped out of the RCL and become plain old static files on disk (publish your site to a folder... and see). When you run in your (local) development environment, dotnet serves the static files right out of the RCL. > but as soon as the runtime mode is set to production and I build Umbraco in release mode You can't just run a build of Umbraco once the runtime mode is set to production, you have to publish the site first and then run the output of the publish.

It says 'The application is built/published in Release mode', suggesting it can either be build or published. I build it in release mode, but I guess thats not enough in that case. The reason we're investigating this issue is that we have a very serious issue of a backoffice that simply won't work anymore on a production environment. Everything boots and runs, the delivery API works, but the backoffice wont load and only shows a white screen. So im trying to replicate the issue locally. Thanks for your input, ill check it out.

Hmmm, good point.

Yeah its very weird, it worked before and it works in every other environment. Also going back to an older build that used to work doesnt work anymore, so we have ourselves a mystery 😆

Only reason backoffice lost styling (or became "white screen") for us has ever been misbehaving plugins with broken manifest files or missing files. The Smidge logs haven't always pinpointed the culprit unfortunately. Don't know if there's a way to enable backoffice Smidge in development mode (which might show you the error) or disable it in production mode (which might temporarily "fix" backoffice).

You were right. I needed to publish the project and you're also right that the RCL files are actually copied over in that case. I guess I learned how RCLs work. I thought the files were actually served from the dll, like embedded assets. I got the local Umbraco working in production mode. @kdx-perbol thanks for the input. The issue is that it's only the production environment that is acting weird, every other environment works file. So if it were a faulty manifest file, all other environments should have the same issue. Maybe something has gotten corrupted, but it such a weird issue... The who reason I was trying to get Umbraco to run in production mode locally is to try to find a way to replicate or reproduce the issue, but so far Ive been unable. And now that I got our main branch to run in production mode locally, I guess I"m back to square one...

So the 404s and smidge errors were just from trying to run locally? You're not getting that in production?

Tomorrow I'll be going back to the issue and see if I have more details, but the issue is that Umbraco on our production environment is just a white screen and the backoffice will not load. No other environment has this, so I was trying to get the local instance as close to production in terms of configuration as possible. So yeah, I thought that I found the issue because I was seeing the same behaviour in my local machine and thought it was similar (or well, the result is similar). So right now from home I'm not sure if the production server ACTUALLY has the same errors or not, need to check that tomorrow. Didn't you do the talk about threads on Codegarden last year Jason? Perhape I need some more threads? 😛

This should get you pretty close:

dotnet publish -c Release -o E:\Release

to publish in an existing (empty) directory locally in release mode Then in

E:\Release

(or wherever you put it):

dotnet MyProject.dll --urls "https://*:5001"

This will run the published version, you will see no output in the console, which is why I added a URL, so I know where to go:

https://localhost:5001/

Think the default port is 5000, but just adding the port number so I am sure where to look if it does not work.

Well, what I meant was that it's only in production mode that smidge bundles backoffice assets (afaik), so you wouldn't see this in the other modes (development/developmentbackoffice). But maybe you are running them all in production mode. Sorry for being unclear.