We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
Related
Recently I reinstalled my PC. I had my project hosted on IIS server, I remember that in Visual Studio I had to prepare IIS profile in debug options with hosting model OutOfProcess and then when I made some changes in code and hit refresh button in browser, project was automatically recompiling and giving me new results. It was basically live coding.
Ofc just refreshing page without any changes in code didn't trigger recompiling and browsing project was smooth.
I have no idea how did I achieve that, I was looking through internet for a while and coulnd't find solution. Every solution I found says to use dotnet watch run.
Right now I have same setup and it kinda works, but I have to hit compile every time I change something in order to see results on web which is really annoying.
Any idea how to achieve live coding with IIS?
EDIT:
I found the option I was looking for, but seems like it is set correctly and refresh doesn't trigger an rebuild.
I found partial solution, when I select:
Or:
It does work, however I think before it was working automaticaly without triggering an browser from VS. I'd appreciate any solution without it, however it is good enough for now.
I have a site where I am getting:
I had to do a full re-install where this previously all worked fine, and this is going to Azure. I re-imported my publish settings from Azure and see this. That looks good too so I assumed we were back to normal.
Except that the "Publish Succeeded" stuff, when I visit that actual URL I publish to (which I had to blur), none of my changes are there.
Any ideas?
I'm fully checked-in on the git branch and this runs fine locally.
From your comments I understand you're using FTP to make changes to your Azure project. That's not really the best way of deploying an application in 2020, but for this particular issue that you're facing it doesn't matter what method you use.
The most likely scenario is that when you visit the URL you are being given a cached version of your website.
That can happen for multiple reasons:
1) Your browser stored a cached version of the website
2) You are using a CDN (content delivery network) such as Cloudflare, which most often comes with an enabled cache feature that ensures your users will get your static pages lightning fast
3) Your web application implements one or more caching procedures
If none of those is the case (ie: you have tried using incognito mode, you don't use a CDN and you haven't implemented a caching strategy) then you might need to double-check you have pushed to the correct branch and that the commits contain your recent changes.
EDIT: if you actually have everything checked, including that your Git repo is properly synchronized, then it might be worth trying a different deployment method -- normally it shouldn't affect the end result, but there is the possibility that the Microsoft Azure platform has certain hidden bugs - this being one of them.
Have you thoroughly check the directories and stuff if its correct? most of the time issues like this are some minor errors like cache, wrong directories, and same output from previous files etc.
I recently changed my project from a Website Project to a Web Application project so I could use build events.
I'm having all sorts of problems now trying to develop.
When I build the project and reload it in the web browser, it hardly ever loads the right version (sometimes it does).
Like if I make a simple update to some text, it will load the last page, like it's using a cached version of the page or something.
Also when I try to debug, it will never hit the breakpoints. I'm not sure what I need to change to fix this issue, any help would be greatly appreciated.
What browser are you using? The chances are the pages are being cached. With most browsers you can do Ctrl + F5 to force a reload of the cached files.
In Internet Explorer, you can change the option for Temporary Internet Files to 'Every time I visit the webpage', but be aware that this affects all sites you visit.
If you are talking about changes to binaries, you might need to do an iisreset. If you are still having issues, try deleting ASP.NET temp files.
I'm using Publish/Web Deploy to deploy an asp.net aplication from Visual studio 2010. It works perfect, but there is a problem. If the new release is not working as expected, the old version is already replaced by the new one and there is no easy way to roll back to the working version. How is this best solved? I wish it was possible to keep the old version on the server so I could just switch back if needed.
With WebDeploy there is no built in rollback feature, so once you've deployed that's it.
There's a number of hand rolled strategies you could put in place, for example:
Limited Access e.g. Shared Hosting:
Where you don't have full access to the machine -
Backup the live site beforehand by downloading it.
Keep copies of what you deployed so you can push the previous version should something break
Full Access:
Maintain two sets of folders for the application and map your site to one or other of these folders. When you come to deploy switch the IIS site's physical path to the other folder then deploy. If the site fails then just knock the site back to the original folder. Each successful deploy would alternate between these two folders.
For stuff like user uploaded content you'd need to map virtual directories to a place on the file system that's always the same place because you don't want to be copying these around each time.
You're not the only one who has encountered these issues. Have a look at this article by Rob Conery and his observations about the state of affairs regarding ASP.NET deployment.
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Using some form of Source Control would be another alternative. We use subversion, so if the publish goes bad, we can just update back to the last-good revision, and publish that. Even if you're the only developer, using source control can be very useful.
we've recently stumbled across the excellent Dispatch for ASP FTP deployment plug in. It looks great apart from one thing: It doesn't work with Visual Studio 2010, at least for us, anyway. (It's supposed to work fine.)
(Yes, we've tried everything: We've managed to get Dispatch working for another FTP site, but not the main one we regularly deploy to. We have managed to connect to our main site through FileZilla FTP, so the site itself is configured correctly. All settings have been triple checked, but the software still throws up weird errors (always to do with its internal libraries).)
So does anyone know of any other comparable FTP-based, deployment plug-in for Visual Studio?
Here's what Dispatch does (and so any suggested replacement must do):
Monitor any altered files
in the project. When a file is
changed, it's added to a list of
files to be deployed.
To deploy these
files to the live site, all we need
to do is click "Upload" and the plugin will
connect via FTP to our live site and
upload the selected files.
We can filter out
any filenames we don't want to be
monitored/uploaded (e.g. .cs or
web.config or /Images/, etc.)
I think that's all the features that we need. Thanks for any suggestions!
Note: If you're wondering why we need such a service, it's because we deploy many site changes over the course of a single day. Publishing the entire project to a folder, zipping it up, then FTPing that zip file, only to have to unzip it, and then install the entire project into the live wwwroot takes far too long. With Dispatch you're able to upload individual files in a single click.
After much back and forth between me and the creator of Dispatch, we managed to narrow down the problem to the library he was using (Rebex FTP). I posted a question about the issue on the Rebex forums, and it was revealed that their software might have a bug with IIS7.5. They suggested a quick hack/fix, which I tested and discovered worked.
Mr. Dispatch then quickly implemented this hack/fix into his software, and lo! I had a fully working copy of Dispatch... So no need for a replacement any more!
(And from what I've seen, there isn't even any other plug-ins offering this functionality, so it's just as well.)
Just an update - Dispatch does not work with VS 2013 so if you have VS 2012 with Dispatch installed, Keep it. Also the website is gone so it looks like all development has ceased. I have been using Dispatch since VS2005 and it has been great for just sending single files up when I need to. Too bad it is gone.
I built a very simple one for myself - you right click the file in Solution Explorer and it then uploads that file based on a settings file you create.
It's super crude but it works and the source is there to make it better if you like -
https://github.com/garazy/vs-2017-ftp-upload
Big enhancements have been added to VS2008, VS2010, VS2012. Below is the article. I found that Microsoft did all the above while I was searching. Since this came up high in what I was searching, thought should share this knowledge.
Deploy a Web Application Project Using One-Click Publish Without Web Deploy