I am new to IIS 7.5, and I'm trying to use the AutoStart feature, as described in ScottGu's blog and MSDN.
I implemented my own Preload() in my own IProcessHostPreloadClient and I just print to the log and event viewer there.
But it seems I never reach the Preload(), since nothing is being printed. I expect to see the prints when I restart the Application Pool, but, as I said, nothing is happening.
Any suggestions as to what he problem could be? Or how can I check the reason for the problem?
I just print to the log and event viewer there
That could be your problem. Are you sure you can write to the event log at all from within your web app? Traditionally you won't have enough permission to do it in an asp.net app hosted in IIS running the standard permissions.
Try putting a test page in your web app that writes to the event log to make sure your print to event log code is working. If it's not, can you go the simple option of writing a text file to your app_data folder? You've normally got enough permission to write to it.
Related
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
I wrote a classic ASP script (.asp) for a customer a while back. it was running on IIS v6.1 Windows 2003. The customer contacted me and said they had a catastrophic server failure and restored from backup but my script isn't running now. I logged onto their server to check it out and IIS is serving the file (I am prompted to save when I browse to the script) but not executing the script.
Several people's hands were in the server before they called me, I think this is probably a simple config setting someone tried before they figured out how to enable the "ASP" web server roll feature. But for the life of me I can't figure out how they did it. this is obviously not the default behavior. If I was trying to get this behavior I would add the .asp extension to the MIME types, but I checked and it isn't there.
What could cause IIS to serve the source of the ASP script without executing it?
Based on your question I am assuming your restored server is also windows server 2003 ... in that case you will go to the file\folder and the permissions and select execute permission to enable a server side script processor to handle that request. Been almost a decade that I have touched a 2003 server so I can’t give you the exact steps ... but, you want to enable script permissions on that folder(I think, don’t remember if it’s granular enough to drill down to a file). Also, why on earth are they still running server 2003? Is that version even supported yet?
If it’s IIS 7, you want to make sure your app pool is in Classic ASP mode first off. Then go to site and then the handler mapping section, click edit and configure it that way.
I need to determine WHY the application pool is recycling. (its for no obvious reason)
Is there any way to determine this inside of the application_end sub in the global.asax file?
I have put some basic logging in there, so I know WHEN its shutting down, but I cannot tell why.
(and its nothing obvious... it just seems like every couple of requests certain operations cause the application to end. I have turned off every normal reason for recycling such as time outs, memory checks, etc, etc, etc. Same code is working fine on a different server, so I am sure its something wrong with this setup, but what?...)
You don't have to incur overhead to add custom logging, ASP.NET 2.0 health monitoring does the job for you. You can add the following configuration which will log events in the eventlogs with information why Application pool is restarted.
To turn ASP.NET health monitoring ON, you can edit the "master" web.config file, normally found in %systemroot%\microsoft.net\framework\v2.0.50727\config.
First, look for <healthMonitoring> in the master web.config
Inside the healthMonitoring node, find the <rules> node
Inside rules, add the following:
<add name="Application Lifetime Events Default"
eventName="Application Lifetime Events"
provider="EventLogProvider"
profile="Default"
minInstances="1"
maxLimit="Infinite"
minInterval="00:01:00"
custom="" />
Reproduce the issue and look in the Application event log fpr a source of ASP.NET 2.0. This should log why application pool is recycled.
Try looking in the EventLog. When the app pool recycles, there is an entry written to the log along with the reason.
The following link describes the errors codes you'll see in the eventlog for IIS 7.5
http://technet.microsoft.com/en-us/library/dd349270(WS.10).aspx
If there are not already log entries in your troubled machine's event viewer, you can modify IIS to log all app pool recycles.
Article from Microsoft on how to do it is found below
http://support.microsoft.com/kb/332088
I have a massive problem: I have a WPF application that makes a WcF service call. That call functions well if the user is an administrative user. It crashes simply without a chance to catch an exception (none is reported in Windows event logs too). What user right is required to have the service beeing called as a standard user in Windows Vista?
Thanks
Solved through changes on the server side. I don't know the reasons nor do I know what changed. A colleague deployed a new version and: there we go...
I'm just taking my first steps with Azure and the first thing I see in the development fabric is a bunch of console style logging windows. So I figure that's going to be handy and decide to figure out how to write stuff there and stumble upon this:
Microsoft.ServiceHosting.ServiceRuntime.RoleManager.WriteToLog("Information", "Message);
Cool, except I don't see anything in the log. Saw a post somewhere that after first install you need to reboot before this will work, so I tried that but still nothing.
I've checked with a break point that the code is executing and I've checked the logging level in the dev fabric.
Is this supposed to work, or am I completely off base?
Just to add some more information about what I'm doing:
Started with VS08's new project wizard for Cloud Service
In the wizard added a single ASP.NET Web Role project
In the Page_Load method in Default.aspx.cs I added the WriteToLog line shown above
Ran the project and in the dev fabric UI, drilled down the tree to web role instance "0"
Nothing in the displayed log except some role instance start up messages followed by a bunch of health status messages.
Tried reloading the page a few times, the breakpoint in Page_Load gets hit but nothing in the log.
Logging Level is set to information, and the other events are level information so I don't think it's a logging level issue.
Logging level is the common gotcha, but there's also a delay before logs start showing up in the dev fabric, so make sure that this message is getting logged at least 10 seconds after the application starts.
After some more googling, seems like this is a known issue:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481184