I have a CI pipeline using VSTS to deploy an asp .net core application to a web app hosted on Azure
Every time I successfully deploy to the web app it seems that Azure isn't serving the latest changes to the sites homepage. I have verified using the Kudu advanced tools that the files are in fact the latest but it seems that Azure isn't serving them and is somehow serving older files.
This seems to only affect any pages from the home controller as all other routes and static files seem to update fine.
Does anyone know why Azure may be showing older or cached version of certain pages?
If your web app uses local cache, you need to restart your site to get the latest changes. Check if you have set the value of WEBSITE_LOCAL_CACHE_OPTION to ‘Always’ in your Application settings.
Also, set WEBSITE_DYNAMIC_CACHE value to zero and check.
You have mentioned that files are updated in Kudu console. As others suggested, if you haven’t done this already, try clearing browser cookies, history and cache. Also, test this on another browser or private mode and see if that helps.
Related
Trying to migrate a legacy ASP.NET WebForms/MVC hybrid application from Cloud Services to App Services. All runs fine locally in debug Visual Studio (V2022). The app is predominantly webforms but MVC has been retro fitted and is in use for some pages. It's using .NET Framework 4.8.
Deploying directly from Visual Studio. We have created a new App Service and App Service Plan. The site appears to deploy correctly but the endpoint returns the below as raw text, i.e. the web browser doesn't even attempt to render it, presumably as there is no header information specifying html content-type:
Have checked the configuration for the app service, all appears normal (same as other app services that run quite normally). It's set to ASP.NET 4.8 with all the other standard defaults. The default documents includes Default.aspx which matches the application. The application is using Forms authentication and defaults to a Login.aspx page. We have tried removing this and redeploying but we still get the same result. Configuration and Management diagnostics section on the Azure portal shows no significant errors.
In Kudu (advanced settings) if I access the debug console, I find my app is deployed to c:\home\site\wwwroot> as expected, however if I click "Site Root" it flips me to c:\local>
Could it be IIS is pointing to the wrong path for the site?
In the end found some rogue code that was causing the issue. The different paths under Kudo was a red herring.
To diagnose the problem we moved from VS deployment to CI deployment and still had same issue. This meant it was not publishing settings. We compared web config with other solutions that ran fine as app services and found no significant differences. This ruled out IIS settings from web.server section. We checked for errors on the app and found no errors being reported.
In the end we trawled through the code and eventually found something that was URL specific.
I have built a web app in VS2019 that is a .netcore 2.1 application. It builds and runs fine locally in debug and release mode.
I have bought space from a hosting site on there server and have a registered a domain, they stated that they can run .netcore apps.
I have deployed the web app to the servers file server, I have used Visual studios publish functionality and used filezilla, my site is in its httpdocs folder which is where there sample html index file was before I deleted them, now in this It has the webroot folder and the dll's here.
When I look up the website online it shows a 500 error.
I have never set up this type of thing before, am I missing steps, Is there something that I have missed.
Just to note, I have looked up other similar questions regarding this but havent helped.
Assuming you are trying to host this inside IIS, you need the followings to be installed on the server. You can download the same from here.. Please make sure you choose the correct hosting bundle for your application.
Once that is installed, make sure to open IIS and create an apppool. Make sure you select No Managed code.
Then you can add the web site, and assign the above apppool to the website.
Hope this helps. Happy coding <3
I have deployed my newly created web app developed in Asp.net core 2.1 on a windows based shared plesk hosting.
When i tried to browse the site, it give me this error
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
I have searched it on google but all the help is coming for .net framework not for the .net core framework. Existing solution has suggested me to put this code in web config
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
but in .net core 2.1 there is no web.config in the project..
Bottom line issue is still there, don't know what to do.
First of all ensure that the your shared hosting provider support .NET Core hosting as it requires .NETCore Hosting Bundle installed and .NET CLR Version set to No Managed Code
Next publish your ASP.NET Core web app which will generate web.config file and then upload the published files on the server.
You may need to look at hosting's website or get in contact with them to determine whether they support .NET Core, at what runtime version and what needs to be done to have it set up for a website. They may need to do it manually and you may need to downgrade to their version.
The simplest way to handle this with shared hostings is to publish fresh template that works locally, copy it over to hosting (or use Web Deploy to do this directly from Visual Studio) and if it errors, write a ticket that your .NET Core site isn't working and it's up to them to install and set up everything that is necessary.
If they can't get it working, then you won't be able to either. Nothing else you can do, but to change hosting provider.
Literally just stumbled on this question after finding a resolution to the exact same problem.
My scenario is:
I was trying to move hosting providers - website already live, running from old host's webspace.
New host was a shared windows-based web hosting provider, running Plesk.
I was therefore trying to publish my .Net Core 2.0 project to my new host.
...and I kept getting a "403 - Forbidden Access" error.
Here's what I found, which I think might have been part of the problem that the OP faced.
Even though I had published the website to the remote server correctly, the 403 error kept coming until the new host's technical support pointed me to one of their knowledgebase posts, which exactly described my scenario and the issues I had, along with how to overcome them.
Essentially, I didn't have my domain name's DNS settings configured yet (as it was still in use, pointing to my previous hosting provider's webspace) and as such, the DNS are getting 'confused'.
The short-term workaround was to add a temporary entry to my hosts file on my PC, which directed the traffic for my website to the IP address of the NEW web hosting provider. (Once full go-live, these are deleted).
Something like this:
123.123.123.123 mywebsite.com
This allowed me (on my PC) to bypass the DNS settings on my domain name, and to reference the web content on the new web host's webspace, to continue setting-up and configuring the website, prior to full migration
Here's the link to their knowledgebase article, which I'd have never of thought of, until they mentioned it. (And then it made perfect sense!!)
I installed Wordpress for Linux as an Azure WebApp. I set it up and installed a few plugins only to find out later that they were gone. A little investigation revealed that the storage in the container doesn't persist across container restart and hence why my plugins were not persisted. I then enabled WEBSITES_ENABLE_APP_SERVICE_STORAGE, but now my site shows up with the empty Web App Template:
Your App Service app is up and running
It looks like turning the App Service Storage maps the Web Server to Azure Storage and my container is now "useless". How do I retain files and have Wordpress running at the same time? I would imagine that Wordpress is a little useless without being able to persist storage...
I think this one is out of date.if you are using Wordpress for Linux as an Azure WebApp, Below readme.md maybe help.
https://github.com/Azure/app-service-quickstart-docker-images/tree/master/wordpress-alpine-php/0.4
For a long time I have been performing dated deploys to our IIS servers, basically this means that each deploy gets its own dated folder within the web site folder (c:\sites\my-site\20140824-1236 for example). I then redirect the web app to the new deployment folder.
This gives us a quick role back capability if things go pear shaped.
The problem is that we are looking at moving deployment over to the new web deploy techniques, while we have been using the new techniques within QA and UAT for a while - the standard behaviour is to simply replace the files at the location defined within the IIS web site.
Before I go and start looking at remote PowerShell to re-configure IIS before executing the web deploy.. does anyone know how I can achieve this using standard web deploy.. maybe with msbuild extensions or something?
How about using the automatic backup capabilities in Web Deploy v3?
http://www.iis.net/learn/publish/using-web-deploy/web-deploy-automatic-backups