We have an ASPNet5 site (angular site and webapi service) running under IIS 8.5 successfully. The issue we have now run into is dnx holding locks on files that prevent us from re-deploying the site from our automated deployment server. The task is simply using robocopy to perform the task but I can reproduce with a simple copy as well. Essentially, the error is "process cannot access the file xxxx because it is being used". The files in question are mostly under the approot/packages dir.
The question is how to work around this. The main goal being able to re-deploy without having to bring down the site which seems impractical.
We are running on Win2012R2, IIS8.5 and clr rc1-update1.
Thanks for your help in advance.
Related
I updated a ASP.NET CORE/ASP.NET 5 RC1 controller cs file with a programming change.
The site has previously been deployed on production on IIS7.5 Windows 2012 Server which makes use of HTTPPlatformHandler installed in IIS.
This is a remote server I have to access via VPN.
The site is setup as an application in IIS and the folder points to the wwwroot directory of the deployed site.
I deploy it currently by deploying it first locally by right clicking on my project in Visual Studio 2015 and selecting publish to local folder. I then copy the contents of the local folder to the remote network IIS7.5 web server site folder.
If I copy for example the appsettings.json or a changed .cs file to the server, the change will not reflect.
If I copy the whole site to the production server I get folders and files in use messages. I have to kill the 'dnx' process in order to copy without getting these messages.
From my understanding if I kill the process dnx it will force a recompile. This is currently the only way I know of to restart the site after updating it but I imagine it is not the best way.
What is the standard practice to restart your website after you update your production sites that run ASP.NET5 RC1?
Also changing my app.settings json file aslo doesn't trigger a site reload like changing the web.config did in ASP.NET 4 so being able to restart a site is important.
If I have multiple sites on the same app pool and I only want to update one in production. How can I only restart the one site to reflect the latest changes?
Is it possibly to restart the website to reflect the change as updating it directly doesn't cause a recompile taking into consideration if I only have access to a shared folder and not the web server itself?
With IISPlatformHandler, DNX process is started by IIS (instructions are in wwwroot\web.config).
IIS knows nothing about your source files, all requests are forwarded to DNX.
DNX does NOT watch source files for changes, because there is no dnx-watch there.
IIS only watches for wwwroot\web.config file changes, so you need to change/edit/touch it to force IIS to restart website (and DNX process).
I use msdeploy to deploy, it has commands to stop and start app pools, using these commands has resolved my file in use errors. There are lots of ways to use msdeploy, below is how I happen to be using it.
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="site/pool",recycleMode="StopAppPool",computername=COMPUTERNAME
msdeploy -source:contentPath='SOURCE PATH' -dest:contentPath='\\COMPUTERNAME\wwwroot\' -verb:sync -retryAttempts:2 -disablerule:BackupRule
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="site/pool",recycleMode="StartAppPool",computername=COMPUTERNAME
I have recently been trying to migrate some websites from a 2003 server with IIS 6 to a 2012 server with IIS 8 installed. I am using Microsoft's Web Deploy tool and have been successful in copying a few web sites one at a time using the following command (changing the site identifier # for each site).NOTE: The reason the mumbo jumbo with replacing the drive exists is because our new server has a different data drive on it, and MSDeploy didn't like that. Could that be breaking things as well?
msdeploy -verb:sync -source:metakey=lm/w3svc/#,computername=SourceServerNameHere -dest:metakey=lm/w3svc/# -replace:objectName=metaProperty,scopeAttributeName=name,scopeAttributeValue=Path,targetAttributeName=value,match="F:",replace="E:" -enableLink:appPoolExtension > migration.log
The main issue is that when I try to navigate to any site one of three errors happens..
1. 503 Service Unavailable
2. 401.2 Unauthorized
3. 404.17 Not Found
These errors start from 1, and progress to 3 as I am trying to troubleshoot the IIS configurations. But this kind of defeats the purpose of using the Web Deploy Tool. Has anyone had any luck migrating sites being completely successful, or does the tool not actually support "IIS 6.0 or higher migration?"
Thanks in advance.
EDIT: So I have been able to get the main page of my site working by reverting the Handler Mappings and Default Documents to their parent configurations, and making sure that the AppPools don't conflict with versions, etc. The problem with this, is that I have to figure out how to do this for every app and app pool under the sites... Does anyone else have a similar problem?
Try using the iisApp provider instead of the MetaKey provider. For example,
msdeploy -verb:sync -source:iisApp=Site1/ContosoApp,computerName=Server1 -dest:iisApp="Site1/ContosoApp",computerName=Server2
https://technet.microsoft.com/en-us/library/dd569054(v=ws.10).aspx
I ended up contacting Microsoft Support to get this sorted out and ended up spending 3 hours on the phone with them...There were multiple issues that came up during the deploy tool's migration.
The bulk of the issues were corrected by changing the application pools to 64-bit and commenting out abomappercustom handlers in the applicationhost.config.
I've got a TFS build set up to build and deploy a web application. I'm passing in the MSDeploy parameters via the TFS build definition's MSBuild arguments. First time round this is working fine. When someone accesses the web app, one of the controls (Microsoft charting control) generates a couple of files in an empty directory I've added to the solution.
When I go to rebuild (or continuous integration is triggered) the next build will usually fail because it can't delete one of the generated files. When I try and manually delete the file it tells me that IIS worker process is using it and it can't be deleted.
Now to get the build building I'd have to manually restart IIS every time, which is not desirable with CI in mind. I've taken a look through Microsoft.Web.Publishing.Tasks.dll and there's nothing there to restart IIS using MSDeploy.
At the moment I'm thinking that adding stubs of the temporary files in the solution might be a resolution (maybe MSDeploy will be able to close the process if the file is a permanent part of the deployment) or I could do some unpleasantness with Exec in the solution file to get an IIS reset.
It's probably a long shot but has anyone come up against this and found a nice solution?
You could use MSBuild Extension Pack to stop the application pool automatically before deployment. There are several tasks in the MSBuild.ExtensionPack.Web namespace to manage IIS, such as stopping and starting an application pool, deleting an application, etc.
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.
I'm trying to re-install a DLL in the GAC, everything seems to work fine but the web application accessing it still seems to be using the old one.
The old DLL is the same version as the new one with only a minor edit, it will be used by 50 different sites so changing the version then changing the reference in the web.config is not a good solution.
Restarting the IIS server or the worker process isn't an option as there are already 50 sites running that must continue to do so.
does anyone know what i'm doing wrong or what i can do to remedy this situation?
AFAIK, you need to restart IIS for it to get a fresh reference to the updated DLL. Your best bet is to perform the reset at a low traffic time. If you are running multiple servers with load balancing, you can prevent new connections from hitting one server until all connections have been closed. Afterwards, update the DLL, restart IIS, and bring the server back into the connection pool. Repeat for each server with no visible downtime to the end users.
Since you don't make a reference to application pools, I'm going to assume you are on the old version of IIS. In that case, what you'll need to do is to "touch" all the DLLs in each site that references the DLL.
The problem is that the code is already loaded and you need to find a non-intrusive way to re-load the application. Recycling app-pools is an effective way to do this. If you are on the old IIS that doesn't have app-pools, then updating the last-modified in the /bin/ folders or web.config files will reload the application without affecting the other sites.
So a script of some kind to do the above is in order. All it needs to do is update the lastmodified on the DLLs in every /bin application directory.