My deployment process for an MVC5 website looks a little bit like this:
Get nuget package from TeamCity build and extract that to a new directory e.g. C:/website/r1.0.1
Update IIS Website and Virtual app physical paths to point to this new directory
Delete old directory
I found yesterday when I deployed a new version of the site that the virtual app was still referencing the old directory (which broke as it had been deleted), even though the physical path in IIS was pointing to the new directory. I fixed this by recycling the App pool for the virtual app.
I was wondering how this might have happened. Does IIS do some sort of caching that may have caused this? Should I simply make recycling the App Pools after setting the physical paths part of the deployment process?
Related
I am struggling to make the necessesary configurations to run the Draw.io Asp.net samples (https://jgraph.github.io/mxgraph/dotnet/index.html). According to the docs To run the ASP.NET examples in IIS, a virtual directory must be created that maps /mxgraph to the top-level directory of this distribution. To do this I have opened an IIS Manager and in Default Web Site I have added a virtual directory called mxgraph however, this did not solved the issue. Also, I have tried to create new Web Site in IIS and mapp to mxgraph folder which again di not work. Anyone has a clue how to make this work?
How do I specify the physical path as an expression with a variable like release-n when managing a virtual application in an ADO IIS Web App Manage task?
We're just getting started with ADO Releases to IIS servers. We have IIS Web App Manage and Deployment tasks working, but only to a static physical path on the server.
I would like to store the new releases in versioned directories, and have the virtual application updated to point to the version being deployed.
For example
Default Web Site
/card-poc <-- web application stored outside of wwwroot
/release-1
/release-2
...
/release-n <-- IIS virtual application physical path is pointed to here
So in an ADO Release IIS Web App Manage task, how do I specify the physical path as an expression with a variable like release-n?
I've tried d:\IIS_VDs\CARD-poc\Release-$(rev:r)\ to get the release name, but I get the error
The given path's format is not supported.
The expected outcome is that the directory would be created, the virtual application would be altered to point to the new directory, and then the subsequent IIS Web App Deploy task would copy the files to the new dir. The goal is to allow a server operator to roll back an application to a prior version without knowledge of or access to to ADO, Version Control, or really anything except the IIS server.
I tested $(rev:r) and got the same error as you. I think the problem is getting the value of the $(rev:r) variable. I try to Write-Host "$(rev:r)" in the powershell task, but the task cannot get the value of $(rev:r). According to this ticket , it seems $(rev:r) is a special variable format that only works in the Number field in the editor.
As workaround, you can try to use Release.ReleaseName predefined variable.
Release.ReleaseName : The name of the current release. Example: Release-47
I have published my IIS application to C:/inetpub/wwwroot/appDirectory and it's have different configuration in web.config file.
and in development version solution directory i have another web.config file and When i build solution my IIS start pointing to solution directory.
that's too annoying, every time i need to remove application from iis and again make application on IIS itself.
Go to properties of your web service in Visual Studio.
Navigate to Web tab
Either Change the local IIS to express or you can give a different application name so it wont replace your deployed application.
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
As I deploy my web site, I found that I could convert a folder into a virtual folder or web application, I am totally confused about these 2 concepts.
Why there are two different types?
What's the purpose of each?
A Virtual Folder or Virtual Directory is just a link to a physical folder somewhere on the server. This folder becomes part of the website structure and you can use the virtual directory in the path part of URLs. Code that executes in Virtual Directories will execute in the same "Application" as it's parent.
An Application is where the code that runs inside that "folder" has it's own Session state and Application state. It is in effect a new standalone application living underneath the root application.
For example, if you were to deploy an ASP.NET application into a site that had an Application folder called /myapp then that application would have it's own application domain, session state, application state completely separate from another ASP.NET application running in /. For example: if you set an Application value Application["Thing"] = 123 in the root application and then did the same but with a different value in /myapp then Application["Thing"] in the root would not be overwritten by the assignment in /myapp.
Another thing you can do with Application's is specify a different Application Pool to run under. For example your root / application might contain an ASP.NET 2.0 application and run in a pool configured for .NET 2.0. However you may want to run a blog or forum application written in ASP.NET 4.0. Now because you can't mix ASP.NET runtime versions in the same application pool, you can specify an alternative application pool specifically for ASP.NET 4.0 applications.
Applications can also behave like Virtual Directories and you can point an application folder at a physical folder elsewhere on the server.
If you're interested in the underlying mechanics of Virtual Directories and Applications on IIS7 then have a look at this answer I posted a while back:
Using ServerManager to create Application within Application
To add an informational detail to what Kev has very nicely mentioned - All virtual directories by default run under a pre-defined app pool named DefaultAppPool. DefaultAppPool comes by default with IIS whenever you enable this feature in windows. For WebApps you can always create fresh/new appPools and run your webApp inside your newly created appPool. These appPools provide you that physical/separate process space (in form of worker processes) with the help of which IIS is able to provide services like sessions state, application state etc in silos to a webApp when it has its own appPool defined. Whenever your webApp's appPool crashes, the other webApps (using their own custom appPool) or virtual directories (using DefaultAppPool appPool) remain completely unaffected.