My team is currently working on a new Blazor app and we are facing some strange behavior. We deploy our APP using Azure Dev Ops, but it seems that sometimes things go wrong. If we deploy the same version with the the same pipeline, the issue could be solved...
This is the error we (sometimes) get in every browser chrome, firefox, edge, ...:
admin:1 Failed to find a valid digest in the 'integrity' attribute for resource 'https://domain/_framework/dotnet.timezones.blat' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
This seems to be happening completely random. We have tried everything... like disabling compression, checking IIS settings, clearing cache, ... We also read the complete Microsoft Documentation. Some other guys also had this problem and they have a solution by clearing the obj/ folder. But we never have this issue locally... So this isn't a solution for us.
Does anybody have any idea what could be the problem? Because it seems completely random to us so far.
The app is ASP.NET core hosted and not stand-alone.
Any help would be very much appreciated!
Kind regards,
Evert
I just ran into the exact same problem. My VS solution compiled and ran under VS 2022 no problem. But when I published to my dev or prod web server I got the same message that you encountered. I solved it by clearing the bin, obj, and .config folders in all my projects in the solution. You mentioned that you don't have the problem locally -- neither did I and this still resolved the issue when I deployed. I suspect an older version of a file is getting into the deployment pipeline somewhere. Mine is also a hosted solution under .NET 6.0.2.
Related
I'm strugguling to deploy a netcore 3.1 web api in an IIS inside a windows Server, I already tried a lot of tutorials that give some steps like this one https://codingsonata.com/deploy-asp-net-core-web-api-on-iis/ , but I'm always getting a error.
Now that is what I see:
Does anyone knows what I could try to fix it? I already tried a lot of things, change things in the webconfig, I activated everything in the Windows features but I always get this. I already spent a lot of time on it and without success. :/
I have NextJS app with SSG. This functionality was added recently and according to it I should do next-export after next-build to get static files. But after appearing in 9.4 of Incremental Static Regeneration I need to keep server on by npm-start command (in my case I use custom server file with next-express functionality). It works good locally and It works good when I get artifact from Azure. But It doesn't work globally when it will be deployed finally. Help please
Through my attempts, I found that it is impossible to install globally or use next in Azure Web App. That is, it cannot be deployed through Github.Deploying using other methods such as FTP cannot run successfully. It should be related to the azure node environment.
But the method provided in this post says that it can be processed by adding web.config. I think it should be useful and helpful to you. Please read it carefully and try it.
You also can read this document, maybe it useful to you.
I've been browsing the web for a couple hours now looking for an answer to my problem. I am trying to deploy a Web API on Azure Web App Service using VS2017. Everything builds and works fine when running locally but once deployed on Azure (through VS2017) I get this error:
D:\home\site\wwwroot\bin\roslyn\csc.exe
My project is an ASP.NET Web Application (Using Azure Web API template) .NET Framework 4.6.1. I use Microsoft.CodeDom.Providers.DotNetCompilerPlatform Version=1.0.6.0
I also made sure that csc.exe is located in:
Visual Studio 2017\Projects\DeviceManagementAPI\DeviceManagementAPI\bin\roslyn
Just had the same problem and it seems it's a known issue with Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6 and 1.0.7.
Downgrading to 1.0.5 solves the problem.
Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 1.08 worked for me
After a while I simply uploaded manually the roslyn file directly into the server through Kudu. It seems to solve the problem but I still don't know why it won't upload automatically.
Same issue might be caused by missing or incorrect relative packages path. If you're changing solution folder structure make sure all imports have proper path's to avoid missing Roslyn files.
Generally suggest to replace auto-generated ../../../packages/... rabit hole with parameter which will point to correct Nuget folder.
<Import Project="$(NugetPackagesPath)\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('$(NugetPackagesPath)\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
I have created a foxx app for a mobile app I am working on. But, the URL's I have exposed sometimes work correctly but sometimes they fail with following response:
{"error":true,"code":404,"errorNum":404,"errorMessage":"unknown path 'contactspace/initiateRegistration'"}
I did not face this issue when I tested the app in dev environment.
I am not able to figure the reason for the issue. How can I debug the problem ?
Thanks,
Vikas Tandi
I can finally confirm it was a problem that had nothing to do with the actual code of your Foxx application.
We have been struggling to reproduce the issue for quite a while, but were able to do so and fix the problem today.
A fix for this has been pushed in the 2.3, 2.4 and devel branches, and will be shipped with ArangoDB 2.3.5, 2.4.1 and 2.5.
This happens when I try to deploy a Sharepoint WebPart solution. Is there a file or configuration option that I have missed that is causing this error to occur?
Thanks.
I assume that you're using VSeWSS 1.3 to deploy you solution and that these error occur when you try to deploy the solution. I'm not 100% sure but I think I had the same error some time ago. Unfortunately I could remember what I exactly did to solve this problem. But I'm quite sure the problem was related to some network issues as VSeWSS 1.3 uses web services to handle solutions.
So I would advise you to double check you network settings. For example you could try to adjust your hosts file so that your computer's name could be resolved.