That's the 404 error.

About the only thing that I can think of now is that file permissions are somehow set incorrectly. The IIS Worker Task that runs the installation's App Pool needs to have full permissions for all of the files in the installation's directory. Those are system level permissions.

Yep - was hoping after the cache clears to see more but it looks like it's only generic 404s.

Thanks for your help as always, Joe. Can you point me to where I might access those settings?

The only other thing that sets this site apart from the other DNN installs as far as I can tell are that I'm getting some Page Naming Conflicts in the admin logs. They're not affecting the site in any way and in fact a lot of them are listing URLs related to the install that are not used. I don't think they're listing the pages in question but the logs date back to 10/27 which is around the time I noticed this file issue happening.

If I can't figure it out I've considered uploading the .js through Site Assets and redirecting my modules to look there. A few extra hoops to jump through but a short term inconvenience is better than nothing.

After reading this thread, I think this might be related to the fact that in IIS7+ all files served run through the  .NET Integrated pipeline (by default).

Explained here: https://weblog.west-wind....llrequests-in-iis-78

This means that even an HTML file will be handled, at least partly, by .NET
I would start by comparing the < modules > part of the web.config with one of the sites that don't have this issue.

 

Can you point me to where I might access those settings?

 

File Explorer, right click on the directory and select Properties.

 

 

Posted By Timo Breumelhof on 03 Nov 2020 03:26 PM

After reading this thread, I think this might be related to the fact that in IIS7+ all files served run through the  .NET Integrated pipeline (by default).

Explained here: https://weblog.west-wind....llrequests-in-iis-78

This means that even an HTML file will be handled, at least partly, by .NET
I would start by comparing the < modules > part of the web.config with one of the sites that don't have this issue.

 

Thanks for the adivce. I did a comparison and the only difference is one without the issue has 

add name="Services" type="DotNetNuke.HttpModules.Services.ServicesModule, DotNetNuke.HttpModules" preCondition="managedHandler"

-- unsure what that indicates. I scrolled through some of the other differences and while they're largely the same, I noticed the one without the issue has HttpGet and Post protocols in < WebServices > while the one with the issue does not.

I'll follow up on Joe's thread too. Hoping azure does not obfuscate that process too much. Is it possible these things could have changed without my knowing? This site isn't new (it's over 5 years old) but the issue is very new, so it's hard for me to think that its base settings or web.config were changed. Then again, this is not my area of expertise.

 

Posting an update for posterity as I haven't made much progress on the main issue, but a good workaround is to upload the 404ing .js files through SiteAssets and then direct there from my modules. It's an extra hoop to jump through, but not so bad.

Have you actually done a manual synchronization of the file system?

Posted By Joe Craig on 05 Nov 2020 01:17 PM
Have you actually done a manual synchronization of the file system?

By this you mean Site Assets --> Sync this folder / Sync this folder and subfolders?

If so yes, I've tried that. It doesn't synchronize or include any files added through the azure scm or through FileZilla.

 

 

Are the extensions of the added files allowed extensions?

Good catch. They weren't last time I tried, apparently. That's good news that I can synchronize, but unfortunately the Site Assets directory even at Root doesn't include DesktopModules so I can't synchronize those .js files -- right?