When I make changes to a file, Mono ASP.NET doesn't see my changes, I have to do this:
sudo /etc/init.d/apache2 restart
I remember when Mono ASP.NET executes ASP.NET it caches the compilation somewhere. Before, when the updated page doesn't come up, I just delete that cached compiled code. I just forgot the exact path
How to make Mono ASP.NET detects the changes I made in program, without restarting the web server?
It sounds like the FileSystemWatcher cannot see changes coming from the windows side.
After you update on the windows side, go to the linux side and do:
touch Web.Config
or any file on the directory. This should notify ASP.Net to load your new code.
This is the command to restart your App, and recompile if its needed. (with out restart the web server).
Can you test it if do the work ?
HttpRuntime.UnloadAppDomain();
The other way is to create a file app_offline.htm on root, upload your changes, and then delete it.
Related
Environment: ASP.NET Core 2.1, Ubuntu.
In old style ASP.NET, when I did a bin deploy (uploaded some dll files for example), the webapp would detect that and reload itself - very useful.
With Core it doesn't do that. I need to stop and restart the dotnet MyApp.dll process.
How do I make it detect changes to binaries and reload?
There are file watchers in Ubuntu that can issue restart commands whenever files are changed like systemd or inotify, but I would strongly advise against that. Uploads can pause or be slow and when uploading 50 files imagine restart after every single one every couple seconds. Server has no way to know when you have finished uploading last DLL. IIS has same problem, it's reliable in development because you refresh the page after the full DLL rebuild. But when in production you don't want random visitors to boot your site midway while it's still uploading. Errors, file locks, all kinds of weirds things can happen.
As pointed by Chris Pratt you want to script your deployment workflow. Idk what environment you are developing on, but if you have Visual Studio and WinSCP it's as easy as writing couple lines of code with Scripting and Task Automation.
Then your publish workflow can be for example as following:
Hit publish in Visual Studio
VS will execute winscp script after publish is finished
Authenticate on remote server
Upload publish folder to a remote folder
Remove old files
Prune logs
After all done issue systemctl restart kestrel-myapp command
Then your site is deployed, cleaned and restarted in the most reliable fashion with a single click.
There's nothing I'm aware of that will do this for you. IIS watches things like the bin directory, web.config, etc. and recycles the App Pool when it detects changes, but that's because it knows to. It's also a full-featured web server, and App Pool recycling on file changes is one of those features. Kestrel, which I assume your using is not. It's a very simple web server that does just what it needs to do as strictly a web server. That's why a more traditional web server like IIS, Apache, Nginx, etc. is normally used as a reverse proxy in front of Kestrel - to provide more advanced functionalities.
All that said, though, this is really just a matter of your release strategy. Personally, I'd encourage you to go with something far more robust that copy-pasting DLLs, but if you want to go that route, you can also script it. Create a shell script to copy the bin directory and restart your app. Your release should be one rails as much as possible. Every time human intervention is called for, you have a potential point of failure, because humans are inherently fallible. A script, however, once tested and ensured to work, will pretty much work every time, because it always does the same things in the same order.
We have a problem. We are using IISExpress 8.0 for Asp.net WebForm application(.net 4.0).
Comupter is running under Windows 7 x64.
Sometimes without any reason ApplicationPool restarts. I know that it will restart after 15 aspx\ascx file changes. But in that case it restarts without any changes.
On ApplicationEnd we found a reason of this restart. It's ApplicationShutdownReason.BuildManagerChange.
Search in the Internet won't give anything usefull details. Mostly all recomends to use IIS instead of IISExpress.
Do you know what could be a reason for it?
UPDATE:
Digging deeper into .Net 4 source code give two reasons of this shutdown.
One of them is triggered when someone changed hash.web file from Temporary Asp.net folder. For example - "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\app\a83dcad1\be4aa699\hash\hash.web"
Second reason is when BuildManager built some object and cached BuildResult in HttpCache. And then if it's expired it checks that this BuildResult require ShutdownAppDomainOnChange on cache expiration. And if it's require it, then it triggers BuildManagerChange shutdown.
UPDATE2
In our case restart was caused by hash.web change. Seems IISExpress updates it without any source code change, but why?
UPDATE3
Microsoft has an issue about it - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running
They say that they fixed it in Visual Studio 2012 Update 2.
This is not a full answer, so take whatever benefit from it you may take.
It seems like two things are happening: the hash.web change is probably because IIS uses the temporary location to store the application DLL that you build. When this file changes, IIS understands that you built a new version of the application, and need to restart it; that may explain the application pool reset.
For the cache expiration, it seems like IIS is trying to unload and reload something in a different app domain. There's no way (in .NET) to unload an assembly without unloading an app domain (I think) once it's been loaded, so this is "the usual" way to achieve this.
Maybe.
I have an ASP.net that I built in VS2010 running in iis7 however when I go back into VS and make updates to the code behind file and re-publish the application still acts as it has before I made the changes. I have tried deleting and republishing all the files and restarting the app pool but it still doesn't affect how the application behaves.
project-->Property's--> Package / product web--> Items to deploy --> All files in this project folders
now publish your project.
your new files also added in publish folder. . .
DO NOT publish your vb and cs file on there server unless you feel like having your source code potentially exposed. There have been multiple vulnerabilities that have allowed code download.
Publish the application to a folder via the visual studio publish menu.
On the server, go into your temporary aspnet folder for example:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
and find your app and delete it. If you cannot delete the files stop the worker process (w3wp.exe) or restart iis.
Republish and all should be good. If you are in doubt if that version is getting executed then add some logging in the new version or trace information.
There are two options for publishing an ASP.NET site to a server:
Copy the .aspx AND aspx.vb (or .aspx.cs) files to the server. The first user to hit the server causes compilation so it takes a little bit of extra time for them. Once that's done, subsequent hits should not be impacted.
Copy just the .aspx files - and a compiled DLL to the server. The DLL contains the compiled code so it doesn't exist on the webserver. The first user does not have to wait for compilation and the VB or C# source code is not on the server, potentially accessible to hackers.
It sounds like you've compiled the site to a DLL but that DLL isn't getting published to the server when you re-publish. Have you recompiled the site before publishing?
I faced similar issue with WPF single file exe publish.
while debugging from VS my changes were visible.
But when I pasted the exe to deployment folder, the changes weren't there.
I had to change the version number to see my changes when I run the exe from the deployment folder.
I may have to do with how single file exes are handled. The extracted cache may not be getting updated.
I have built a few custom applications that run on WSS 3 using the Visual Studio 2010 Web application template. When I compile the application, Visual Studio creates the assembly file in the bin directory which I copy over later to the production server (another machine) with WSS 3. The compiled application dll file is copied into the bin folder inside the virtual directory of WSS and runs fine in there.
As the project requirements / applications grew over time I now face the problem that the first hit on the assembly triggers dynamic compilation which I would like to avoid.
Even if applications are running fine I would like to use the asp precompiler on my development machine in order to reduce the delay when the page is first requested.
I have used the following command to precompile the entire Web Application:
aspnet_precompile -v / -p PATH_TO_WEB_APPLICATION C:\WebApp -errorstack
The compilation runs fine without any errors and I end up with a couple of .compiled files and also a Web_App_xxxxx.dll file inside the C:\WebApp\bin folder.
From here onwards I am a bit lost on how to proceed.
Could you please give me some advise to which folder I need to copy the compiled files on the production server ?
Do they need to go into the bin folder on the server or better into the folder where the aspx pages are located?
Additionally I would like to know if I can precompile the Web application on a development machine without the IIS metabase using the -v and -p switch and later use it inside WSS?
I copied all files from the C:\WebApp\bin folder to the server bin folder but unfortunately the csc compilation process still kicks in when looking with process monitor at the server events.
Cheers,
Mathias
The files just need to be dropped into the bin folder and everything will work fine. As for the -v switch you do need to have it if you're using the -p flag, but I think it depends how you're compiling the app too. Check this link out for more. I don't believe its a big deal if its wrong / incorrect though.
This kind of scenario sounds like a job for Cruise Control .NET environment.
I found an answer to this precompilation question:
I thought the first hit on the application page takes a long time because asp.net needs to compile it and I can save some time by precompiling. The application runs inside the WSS context and enables the user to go to a web form and update through the form his/her Active Directory profile. The Exchange global address list is also updated on the Exchange forest so the changes are visible through the Outlook address list and also on Communicator.
The complete solution code with reports etc is around 6000 lines of C# code.
My assumption regarding slow compilation due to the amount of lines was wrong.
I downloaded the following hotfix for asp.net:
http://support.microsoft.com/kb/961884
and set optimizeCompilations="true" in the web.config as explained here:
http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx
http://www.paulliebrand.com/2009/09/18/sharepoint-development-to-bin-folder-and-extremely-slow-render-initial-render-times-solution/
Now the first hit on the application is much faster.
Many thanks,
Mathias
I have a question about asp.net compiling. I know the different ways you can compile but my question is with the default method.
Microsoft says that pages and code are compiled on their first use and then cached. My question is, when does that cache clear...
when the app pool recycles? Or, does it cache it until it's changed even through server reboots. Basically, if it compiles once and then caches it until it's changed I'm ok with it... if it recompiles with every reboot or app pool recycle I'm going to go the route of pre-compiling.
The cache is cleared upon app pool shutdown, at each app pool startup it is re-compiled and cached.
Whenever you change something to the source files it will recompile.
On startup (after shutdown) it will recompile too.
Changing something to the web.config reboots your web
So the files are created in a temp folder but do not get cleared on shutdown. They will only be recompiled if something changes. So if you restart IIS or reboot the machine, they will not recompile. Just reload them from the temp folder.
Changes to any of the files of the project, or any files the project is dependant on will cause a recompile.