On a development environment, my web application is properly logging all messages. On the stage environment, the session_end event in global.asax is logged but nothing outside of global.asax gets logged. On dev I can see a basic log when I launch the application showing me logging on, but nothing in stage.
-code is same in both environments
-.NET 4.0 web application deployed to IIS
-log4net.config is same in both environments
-logs to text file on same drive as application that runs it
-logger is instantiated in static class, used through whole application.
-global.asax application_start configures logger by building FileInfo object that points to log4net.config and doing this log4net.Config.XmlConfigurator.ConfigureAndWatch(file);
Does anyone have any advice? I'm sorry if this question is vague or needs more information. I'm unsure where to begin with troubleshooting this. I'll add any requested information.
The user from your application pool needs to have write rights to the logging directory, check is the rights on both environments are the same.
Related
I gather this might be a general asp.net question as well. I'm running hangfire and we have noticed that when we publish the app to the site that is acting as a container for hangfire, the deploy causes the app to stop running and the app never 'restarts'. I have logging in the global asax application_start and application_end, and our applicationpreload.cs. When we publish the site I see logs for the application_end event but nothing for the start event - this publish occurs while the site is running.
I have followed the steps on the hangfire site https://docs.hangfire.io/en/latest/deployment-to-production/making-aspnet-app-always-running.html and there are a few msdn articles I have followed on the newer IIS settings to keep the app pool always running and the site auto start enabled but my assumption is that these only help when there is either an iis site restart, or app pool recycle/stop/start, or a request comes into the site itself. My scenario is that we are using iis as the container, there are no requests hitting the site and we publish while the app is running...
I was also under the impression that changing files within the iis directory would cause the app pool to recycle but have now realize this is not the case (and that actually makes sense). We are using asp.net mvc 5, iis 10.
Any help here would be appreciated!!!!
PS I can see the down votes already on this - which is actually quite comical taking into consideration this question covers some fundamental asp.net knowledge... and yes I'm just being honest here in terms of not knowing the answer :)
thanks
after a lot of testing different variants of solutions I have resolved this.
I have a large Web API project that runs my company's e-commerce site. I just noticed that any request to the web API shows the URI-stem as root in the IIS logs. Is there a way to see the full route to the API end point that was called?
I am trying to use File Beats in our Elastic Search/Log Stash/Kibana (ELK) setup. We got the File Beat setup to monitor the IIS log today and just showing the root does not give us the information that we are looking for in our logging.
Activate the Host(cs-host) field in the IIS managament console logging window. You can also try to add the HTTP_URL custom server variable:
Someone (not me) developed a web site that hits a web service implemented in C#. When I run the web site in visual studio, the project automatically starts the web service. In the web service, I want to log some information to a file for testing. log4net is used in the webservice project, but nothing is logged. I will admit I do not spend much time dealing with log4net, but the web.config hsa values that look like they should produce a file, and it does not.
So, I tried to dump the text of interest to a text file on my local drive.
File.AppendAllText(logPath, txt + "\n");
There are no errors and nothing is sent to the file.
I start the Website, not the web service, so the debugger seems to not know about the web service (so I can't simply set a break point in the web service).
My expectation is that for security reasons things are started in a way that simply disallow this. I vaguely remember that when started in this way, your services are also not allowed to write to disk, so in a development box while running from visual studio, how can I write a simple file to disk.
It seems to me like this should be simple.
First at all, you should call the web service, to log anything. You could use an external program like fiddler or postman, or write a unit test. After the first call, you could attach the visual studio to the w3wp.exe, so you could debug the problem.
The user of the AppPool should be granted the write permission to the log file.
I want to comment at the above answer,but i have no rights.
To set that user to have write permission, for local develop environment,just right click the log folder ,select properties,under the "security" tab,click "Edit",add "EveryOne" with read,write,modify permissions.
In production environment,you should select the real apppool user instead.
Although the answers were useful, and correct, it is not what solved the issue. Also, related, see this:
log4net doesn't create log file when deployed on IIS7
Remember that I chose to start the WebSite, and that auto-starts the WebService. That problem has NOT been solved, but, a coworker burned some brain cells and he thinks that it has to do with how Visual Studio magically starts the web service and that log4net is NOT initialized. If I start the web service by itself, then logging works as configured. I am still testing to see if the above advice allows a lot to be written to a specific directory.
Generally, I would inject TraceListeners and adjust trace level through app.config and Web.config. And I understand that IIS will restart the Web app after the Web.config is updated and the last HTTP request is done and new HTTP requests will be pending before the new instance is created. I have been doing this for years no problem.
However, if I deploy the Web app to Azure managed services, or I have many (clustered) instances of the Web app, I am not sure if updating / uploading Web.config to each instance is still a good practice? Is there some alternative/better method to change the trace level for System.Diagnostics.TraceListeners?
And what if I deploy to AWS or alike for clustered services?
You got it right! updating / uploading Web.config to each instance is not bad but could be tedious task,or error prone approach. Rather,
Would recommend to go with Application Insights,an extensible analytics service that monitors your live web application.
Just install a small instrumentation package in your application, and set up an Application Insights resource in the Microsoft Azure portal.
Performance impact would be minimal as,tracking calls are non-blocking, and are batched ; sent in a separate thread.
Telemetry types such as 'Exception traces from both server and client', 'Diagnostic log traces' and many more helps you understand how your app is performing and how it's being used.
Also you can perform Diagnostic search on instances of requests, exceptions, custom events, log traces, page views, dependency and AJAX calls.
For more information do read : Application Insights - introduction
Thanks,
Kasam Shaikh
Is there any way to specify a permanent port for ASP.NET Configuration site (Web Site Administration Tool)?
I need to add a link to the ASP.NET Configuration site, but I can't due to the port changing each time it starts.
Its the port for ASP.NET Development server
http://msdn.microsoft.com/en-us/library/ms178109.aspx
I'm not sure that you can.
The Web Site Administration Tool isn't really meant to be "linked" to as such, it's a fairly powerful, unsecured application, that's only really meant to be run by a developer/admin.
The "Considerations" section of the documentation explain why:
The following sections provide some considerations for working with the Web Site Administration Tool.
Restarting the Application When Saving
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. This requires the Web site to which the change applies to be restarted. Because this will cause currently active sessions in the Web site to be lost, you should make configuration changes to a staged or development version of the Web site before publishing these changes to the production server.
Saving Your Settings
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. For settings for which the Web Site Administration Tool interface has a dedicated Save button, leaving the Web Site Administration Tool idle or allowing the Web Site Administration Tool to time out before you click Save will cause your configuration settings changes to be lost.
Time Out
As a security measure, the Web Site Administration Tool times out after a period of inactivity. Any settings that did not take effect immediately and were not saved will be lost. If the Web Site Administration Tool has timed out, close your browser, and then reopen the Web Site Administration Tool in a new window.
The Web Site Administration Tool manages only some of the configuration settings that are available to the Web site. Many other settings require direct modification of configuration files either manually, by using the MMC Snap-In for ASP.NET, or programmatically, by using the ASP.NET Configuration API.
From that you can see that this isn't something that's intended to be kept around.
That said, with a little bit of hacking around, you could probably shoot yourself in the foot achieve what you're after:
If you right click on the ASP.NET Development server task tray item for the admin tool, and select "Show Details", you can see that the virtual directory that the tool runs under is mapped to (something like):
C:\Windows\Microsoft.NET\Framework\v4.0.30319\asp.netwebadminfiles\
If you were to create (and secure) a virtual directory on your application mapped to that path, you might well be able to get this all up and running as you want.
As pseudocoder points out in his comment below, while going down the Virtual Directory route does "work", there are some limitations to the tool that, coupled with the security issues mean that you probably wouldn't want to use it going forward.
If you were to stick with the Development Server option, the tool won't respond to non-local requests, and once you've deployed the site to a proper web server (IIS) for users to access the Admin site won't be running anyway.
It would probably be better if you could explain why you want to use this permanently so we can advise you on some better options - for example the Membership, Profile and Role providers both provide nice APIs for managing user details that can be easily built into a custom admin area.
Tricky one, however I think to get this working correctly, you're going to have to spend some time doing something, and it's probably better for you in the long run to spend that time doing the right thing rather than hacking in the wrong option.
The Development server can be started from a command line, using a commands along the lines of:
call "C:\Program Files\Microsoft Visual Studio 9.0\vc\vcvarsall.bat"
"C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.exe" /port:3900 /path:"PATHSITE" /vpath:"PathSite"
The first line sets up the CMD instance to use the variables and path settings needed to run most of the Dev tooling
You'll want to change the path to the DevServer as appropriate for your environment (mine's in \10.0\ for example, and has a 2.0 and 4.0 version).
Armed with this information, you could do something along the lines of:
Add a link to your site to a page called /StartAdmin.aspx or similar.
In that page, you would then need to have the logic to:
Check through the running processes for the instance of the DevServer that was previously used to host the Admin site.
Close that process down.
Spool up another instance of the DevServer with a known port, pointing to the path for the WebAdmin Site.
Redirect the user to this new site.
All of which is possible, but it's not trivial, and you'll find you'll need to be doing odd things with the process your starting, and you'll need to be very careful you don't shut down the instance of the DevServer that's actually running your site by mistake.
However, this would probably take as long as it would to knock up a quick set of user admin screens, and you'd learn something more useful along the way*
* Which isn't to say that learning how to start and leave running a process isn't useful, it's more to say that I'm guessing its not what you're supposed to be learning at the moment, and you should probably be focusing on that ;)