Is it possible to update the site dll for a precompiled site without stopping IIS.
Currently, if I try to just copy the new file to overwrite the current file, All users receive runtime errors while the file is being copied. Is there a way to avoid this?
even if you don't stop, any change to the web.config file, BIN folder, App_Data or App_Code will force the .NET compiler to perform ...
and you will loose any Session variables in memory.
What I do is to use Session State in SQL Mode and if your system is set up like this, user will remain in the site (after a longer exposition to a page reload)
.NET will still invoke the compiler in order to compile the new set of instructions but soon it is done, all sessions will be read from SQL Server and because they are still there (and not lost with a memory refresh) users will remain in the website with current credentials.
it is a little bit slower than In-Memory Session State, but much more reliable, specially with Shared hosting :) this is the way to increse/decrese the minutes in your session, as Shared hosting do not allow it to change even if you do
Session.Timeout = 5;
their machine configuration will override everything you do, with SQL Session State, you will be able to set your time as this is all made by SQL Server.
Fell free to read this article to know how everything is done.
Hope it helps.
Related
I am using VS2013 Premium to publish a site to Windows Server 2012.
All files publish ok except these:
SqlServerTypes\x64\msvcr100.dll
SqlServerTypes\x64\SqlServerSpatial110.dll
SqlServerTypes\x86\msvcr100.dll
SqlServerTypes\x86\SqlServerSpatial110.dll
I get this kind of errors for each of the above files I tried to publish:
Web deployment task failed. (The file 'msvcr100.dll' is in use. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
Interrestingly, these files were published the first time (when they were not on the server), then they are no longer overwritten. Tried with 2 different web servers.
I have followed the guide here:
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
...But it only managed to put the site offline (VS is placing the app_offline.htm) but publish still fails with the same error.
All other files publish perfectly.
Any ideas?
You can take you app offline during publishing which hopefully should free up the lock on the file and allow you to update it.
I blogged about this a while back. The support outlined was shipped inside of the Azure SDK and Visual Studio Update. I don't remember the exact releases but I can find out if needed. Any update dating around/after that blog post should be fine.
Prerequisites:
VS 2012 + VS update / VS 2013 + VS Update / VS2015
MSDeploy v3
Note: if you are publishing from a CI server the CI server will need the updates above as well
Edit the publish profile
In VS when create a Web Publish profile the settings from the dialog are stored in Properties\PublishProfiles\ as files that end with .pubxml. Note: there is also a .pubxml.user file, that file should not be modified
To take your app offline in the .pubxml file add the following property.
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
Notes
ASP.NET Required
The way that this has been implemented on the MSDeploy side is that an app_offline.htm file is dropped in the root of the website/app. From there the asp.net runtime will detect that and take your app offline. Because of this if your website/app doesn't have asp.net enabled this function will not work.
Cases where it may not work
The implementation of this makes it such that the app may not strictly be offline before publish starts. First the app_offline.htm file is dropped, then MSDeploy will start publishing the files. It doesn't wait for ASP.NET to detect the file and actually take it offline. Because of this you may run into cases where you still run into the file lock. By default VS enables retrys so usually the app will go offline during one of the retrys and all is good. In some cases it may take longer for ASP.NET to respond. That is a bit more tricky.
In the case that you add <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline> and your app is not getting taken offline soon enough then I suggest that you take the app offline before the publish begins. There are several ways to do this remotely, but that depends on your setup. If you only have MSDeploy access you can try the following sequence:
Use msdeploy.exe to take your site offline by dropping app_offline.htm
Use msdeploy.exe to publish your app (_make sure the sync doesn't delete the app_offline.htm file_)
Wait some amount of time
Publish the site
Use msdeploy.exe to bring the app online by deleting app_offline.htm
I have blogged how you can do this at http://sedodream.com/2012/01/08/howtotakeyourwebappofflineduringpublishing.aspx. The only thing that is missing from that blog post is the delay to wait for the site to actually be taken offline. You can also create a script that just calls msdeploy.exe directly instead of integrating it into the project build/publish process.
I have found the reason why the solution at
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
did not work for the original poster, and I have a workaround.
The issue with the EnableMSDeployAppOffline approach is that it only recycles the app domain hosting the application. It does not recycle the app pool worker process (w3wp.exe) which the app domain lives in.
Tearing down and recreating the app domain will not affect the Sql Server Spatial dlls in question. Those dlls are unmanaged code which are manually loaded via interop LoadLibray calls. Therefore the dlls live outside the purview of the app domain.
In order to release the files locks, which the app pool process puts on them, you need to either recycle the app pool, or unload the dlls from memory manually.
The Microsoft.SqlServer.Types nuget package ships a class which is used to load the Spatial dlls called SqlServerTypes.Utilities. You can modify the LoadNativeAssemblies method to unload the unmanaged dlls when the app domain is unloaded. With this modification when msdeploy copys the app_offline.htm the app domain will unload and then unload the managed dlls as well.
[DllImport("kernel32.dll", SetLastError = true)]
internal extern static bool FreeLibrary(IntPtr hModule);
private static IntPtr _msvcrPtr = IntPtr.Zero;
private static IntPtr _spatialPtr = IntPtr.Zero;
public static void LoadNativeAssemblies(string rootApplicationPath)
{
if (_msvcrPtr != IntPtr.Zero || _spatialPtr != IntPtr.Zero)
throw new Exception("LoadNativeAssemblies already called.");
var nativeBinaryPath = IntPtr.Size > 4
? Path.Combine(rootApplicationPath, #"SqlServerTypes\x64\")
: Path.Combine(rootApplicationPath, #"SqlServerTypes\x86\");
_msvcrPtr = LoadNativeAssembly(nativeBinaryPath, "msvcr100.dll");
_spatialPtr = LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial110.dll");
AppDomain.CurrentDomain.DomainUnload += (sender, e) =>
{
if (_msvcrPtr != IntPtr.Zero)
{
FreeLibrary(_msvcrPtr);
_msvcrPtr = IntPtr.Zero;
}
if (_spatialPtr != IntPtr.Zero)
{
FreeLibrary(_spatialPtr);
_spatialPtr = IntPtr.Zero;
}
};
}
There is one caveat with this approach. It assumes your application is the only one running in the worker process that is using the Spatial dlls. Since app pools can host multiple applications the file locks will not be released if another application has also loaded them. This will prevent your deploy from working with the same file locked error.
There are known issues with IIS and file-locks (why they aren't solved yet i dont know).
The question i want to ask however is if you even need to re-deploy these files?
I recognize the file-names and recall them to be system-files which should either already be present on the server or simply not need to be re-deployed.
I am not very experienced when it comes to IIS but i have ran into this problem before and several of my more experienced co-workers have told me that this is as i said a known IIS-issue and i believe the answer to your question is:
Avoid deploying unnecessary files.
try again
Reset website
try again
iisreset
I think what would be the easiest thing to do is to make these dll's as CopyLocal as true. I am assuming these dll's are pulled out from program files folder. Try marking them as copylocal true and do a deployment.Try to stop any IIS local process running in your local machine.
Watch out you don't have one of those new-fangled cloud backup services running that is taking file locks - and also you don't have things open in explorer or a DLL inspection tool.
I think it's kind of ridiculous that MS doesn't make better provisions for this problem. I find that 9 times out of 10 my deployment works just fine, but then as our traffic increases that can become 1 in 10 times.
I am going to solve the problem with :
two applications MySite.A and MySite.B, where only one is running at a time.
I always then deploy to the dormant site.
If there's a problem during the deployment it will never cause the whole site to go down.
If there's a major problem after deployment you can revert back very easily.
Not quite sure how I'm implementing it, but I think this is what I need to do.
I am building a Web Application that will be installed many times. The application needs to be able to save certain setting itself upon request.
I have an installer (InnoSetup) but I want to very careful about what permissions I give the Web Application.
I can't use a database.
A default install always leaves the web.config as read-only. (Most secure)
The registry can be problematic. Unless there is a set of keys a DotNet webapp can always write to by default (IIS_IUSR)...
I was considering App_Data, but the default permissions are no longer useful and Inno-Setup can't easily fix it correctly:
https://support.microsoft.com/en-us/kb/2005172
Security and Ease of Setup are both big issues..
I also don't want to make a mess of the machines I install to.
A FAILED solution was to write to the user portion of the registry:
Microsoft.Win32.Registry.CurrentUser.CreateSubKey("Software\\MyCo\\MyApp\\");
var reg = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\\MyCo\\MyApp", true);
reg.SetValue("MyValue", (string)dataString, Microsoft.Win32.RegistryValueKind.String);
But I found out that writing to HKEY_CURRENT_USER is also not allowed by default on Server 2012 and likely others. The server error page is helpful and gives options such as explicitly giving the IUSR_{MachineName} explicit permission but this is a no go for me.
So my final solution is to have the installer create a user configurable folder and then assigning all users Read/Write access to that folder. The administrator can always lock it down more if they want.
If anyone has a better option then let me know.
With InnoSetup I created a new Wizard page to suggest and collect a Data folder from the user. The installer then:
Created that folder and gave All Users Read/Write access,
Added a HKLM registry key telling the Web App where to look for the folder,
Notified the user that they should lock the folder down further to prevent abuse.
I need to shut down my web application during maintenance process, have already gone through many ways like putting app_offline.htm in root directory , disabling the Runtime or disabling it manually via server but i what i need to implement is to do this process completely automated.
What i have is the start and end dates for shut down and flag for those days i.e whether application needed to be shut down on those dates.
Solution that i already have is to create a job in sql server agent which creates and deletes the app_offline.htm file in and from the root directory but what the problem is i need to give static path for the root directory of my application which i don not want to do.
You can use the appcmd command line utility for managing sites on IIS. It's located in %systemroot%\system32\inetsrv\APPCMD. I think it is available in IIS v7 and above only though, not sure if your using an older version of IIS.
To stop and start a site, the command will look like the following:
%systemroot%\system32\inetsrv\APPCMD stop site <Your Site's Name>
%systemroot%\system32\inetsrv\APPCMD start site <Your Site's Name>
More info on the appcmd utility is here: http://www.iis.net/learn/get-started/getting-started-with-iis/getting-started-with-appcmdexe
This is part of the answer which deals with probing the IIS to get the physical path. It might need some tweaking
//eg of site = 'Default Web Site'
//eg of Application = 'MySite'
var appName = "MySite";
//Initializes a new instance of the ServerManager class by using the default path of the ApplicationHost.config file.
ServerManager mgr = new ServerManager();
var applications = mgr.Sites.Cast<Site>().SelectMany(s => s.Applications);
var app = applications.SingleOrDefault(a => a.Path.Equals("/" + appName));
IList<string> physicalPaths = app.VirtualDirectories.Cast<VirtualDirectory>().Select(v => v.PhysicalPath).ToList();
//Calling dispose manually. Per MSDN, cannot wrap the ServerManager instance in 'Using' as it causes memory leaks
mgr.Dispose();
//Releasing the reference to the Server Manager, per MSDN guidance
mgr = null;
return physicalPaths;
One issue that you have here is that web application work on a request basis. You make a request, request is processed and returned. Therefore, to rely on this principle to shutdown your application will not work. What you need is to register a scheduler of some type in Application_Start that would configure itself based on the values in the database. Although I am not sure which scheduling mechanism would be appropriate, you might want to look at Timer (but you must keep a reference to the this object because of garbage collection) or Task scheduler in System.Threading.Tasks namespace.
I might be wrong with a choice of classes but this could be a starting point.
Now, as for you design decision, I would avoid it completely. If your web application can create app_offline.html or rename a file into that one, you have no way of bringing the server back online without manual intervention by removing the file. Instead of that why not create some maintenance Windows Service that can query the database and take offline and bring back online again? If you don't care about bringing the web application online automatically then you should not care about taking it offline automatically.
Another thing to consider is a human mistake in configuring the time when application goes offline. Wrongly configured time can bring down your application much too sooner or much later. Wouldn't it be easier if you created some batch scripts or PowerShell scripts that could take down and bring back up the web application? With the PowerShell script you can query IIS for your application without specifying any physical location.
A couple of questions:
1) How can I update a Classic ASP website/page without interrupting service (users getting an error or service unavailable message) or shutting the website down temporarily?
2) When updating/restoring a MSSQL DB via SQL Server Management Studio, will the website users get an error message?
Thanks in advance.
A smart practice is to use at least one separate development environment with the same setup as your production environment and debug all changes there to ensure that they work. Once your entire site is running and tested on the other, identical environment to your production environment, you should be able to simply move the files and they should work in production. This model being effective is dependent on actually being able to maintain environments as close to identical to each other as possible.
When updating/restoring a MSSQL DB
Be careful with your terminology; UPDATE and RESTORE are two very different commands.
If the database is locked by the changes being made, then it will be inaccessible to users and may cause error messages depending on your IIS and code setup. Scheduling a maintenance period and blocking user access to any pages that access the database is will help avoid messy errors and revealing any information about your infrastructure while the changes are being made.
It seems like you might want to do some basic research on development and databases both in order to make sure you understand what you're doing and can cover all of your bases. Looking up commands like RESTORE and UPDATE and using them correctly is crucial.
For example, when you rewrite one or more of your website files
via FTP, in that very moment when rewriting is taking place,
users will get a 500 Service Unavailable error. How can I avoid this?
This really shouldn't happen, although you could upload the files to a different folder, avoiding any delay there, and sync the files with a diff tool such as Winmerge (also helping you keep track of changes and revert quickly) when done uploading.
I'm wondering if there is an event that can be handled or a method that can be overridden that takes place before the Web.config file is parsed and monitored by the asp.net 3.5 application / AppDomain lifecycle.
The practical reason for this is that I'd like to be able to write the Web.config file from a copy in the database while the application is starting up depending on the deployment environment. The reason for this is because we have a manual application deployment process and a web farm. Web.config changes often fall through the cracks or fail to be propagated to all servers on the web farm because of the manual process. Unfortunately we are going to be staying with a manual deployment process for the foreseeable future. This being the case, it would be great if there was a way for an app to go grab its web config on first startup. If I could get that working, the next logical thing to do would be to create a SQL dependency/notification to cause an AppDomain unload whenever the config file is changed in the databases so new changes would be pulled and written.
So far the only way I've figured out how to manage this is to do something like the below psuedocode that has the unfortunate side effect of causing two application load cycles per attempted start. Additionally, I'm pretty sure the first request that comes in if the app is idle will go up in smoke due to the restart.
// PSEUDOCODE
// In global.asax.cx
protected void Application_Start(object sender, EventArgs e)
{
bool loadConfigFileFromDB = GetConfigLoadOptionFromLoadOptionsConfigFile();
string webConfigPath = GetWebConfigPath();
if (loadConfigFileFromDB) // Most likely false in development so debugging works
{ // with a local web.config
if (File.Exists(webConfigPath)) // We are not starting up for the first time
{ // since app was deployed
if (File.GetCreationTime(webConfigPath) < DateTime.Now.AddMinutes(-1))
{
// Web config is more than a minute old, so chances are we
// aren't in an app restart after writing the config.
WriteWebConfigFromDatabase(); // This will cause a restart.
}
// else, web.config was probably just written and we are in a
// restart after writing the config. In this case, let the application continue on
}
else // First time starting up, so it's safe to assume we can write
{ // the config and restart.
WriteWebConfigFromDatabase(); // This will cause a restart.
}
}
}
Obviously a build or deployment task would be the best way handle replacing the Web.config per environment, but unfortunately I am not in a situation where that can happen.
EDIT
The intent of this is not to have dynamic settings while the app is running, it is to help manage differing Web.config files per environment (Stage/QA/Production). Example, in a separate non-Web.config file we'd have an environment setting. After deployment when the app fired up, it would use the settings in this file (the environment and the connection string) to go pull and write the web config for that environment. The settings would not be dynamic after application startup.
You are doing weird thing.
UPDATE (also removed unrelated text):
Ok. So you need to automatically propagte new version of the application to all servers. I do not see a reason to do it from application itself. Instead it should be another utility/batch/installer that does this kind of stuff.
I believe ASP.NET application deploying itself will hit a lot of issues (what if you will need to deploy assemblies along with web.config)?
I think simple batch-xcopy approach will do the job for you:
Create a .bat file that accepts 1 parameter:Envoronment=[Stage/QA/Production].
Copy all the required files to a separate temporary directory (so you can modify things without touching the original code).
Modify web.config and other things you need (you can use some utility for that) as per Environment parameter.
XCOPY all files to all required servers as per Environment parameter.
There is no need to incorporate the deployment process into the application itself.
For Windows applications it is ok as you can use bootstrapper, but not for ASP.NET.
Application_End is the closest event - it fires just prior to the unloading of the AppDomain for the web application. You could just update the Web.config file there.
In principle it should work - the AppDomain is unloaded, so the config has to be reloaded when the AppDomain starts up again, by which time the latest config would already exist on disk.
Also, I'm assuming that ASP.NET stops monitoring the Web.config for further changes, as it has already decided to shut down the application - my only concern is that writing the file again would cause an infinite loop to occur.
It can't hurt to try. It is a weird thing to do though. It would be good to have some more background on why you are needing to do this in the first place.
I'm wondering if there is an event
that can be handled or a method that
can be overridden that takes place
before the Web.config file is parsed
and monitored by the asp.net 3.5
application / AppDomain lifecycle.
After doing a few days of research I'm going to say the answer to this question is: No, there is no such event that can be handled or method that can be overidden. If someone ever comes along and can show otherwise, I will deselect this as the answer to the question.