How to Log output in a webservice run from Visual Studio - c#

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.

Related

WebAPI routes in IIS Logs

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:

Changes to Website Files Not Showing Up in IIS 7

I have migrated 2 DLLs and an aspx page to an existing web application on a production server. The changes in the file do not show up when I run the web application.
I have restarted the web application, restarted the associated application pool, run iisreset, deleted the Temporary ASP.NET Files. The changes do not show.
I have created a new html file in the root of the application, but it returns a 404 File Not Found error.
In IIS, I right-click the web application and choose Explore just to make sure that I am in the correct directory. I am. I see my updated files there. I can view the text of the aspx page, and my changes are there. My test html file is there.
I have searched StackOverflow, implementing all of the prior solutions I have seen that have fixed other poster's questions. Is there anything else I can do to IIS, the file system, or anything else to get these changes to show?

It sounds like you are not hitting the website that you think you are. Check your bindings and host headers, maybe another site on the server is intercepting the request.

Logging working on all environments but one - log4net

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.

Relative paths in class library for asp.net application

I'm having some trouble with reading and writing files on the server with my Web-Application.
I have a c#-class library for my business logic and a ASP.net Web Application as front-end.
The whole application works fine when I start it from Visual Studio.
When I first tried to deploy it I got an error that I don't have permission to write on c:/inetpub/wwwroot/myfolder...
Then I tried to use relative paths like /myfolder but I always get the message cannot access C:/myfolder! And I really don't know where the "C" is coming from?

I would assume that you are trying to write to the file system from your application. In that case the "C" comes from the server. ASP.Net and IIS know where your application resides on the server and are mapping the path from the URL to the file system (C:). It works when you start things from Visual Studio because it's being run under an account that has write permissions to the file system. The IIS Application Pool User that is running on your server does not have write permissions. To resolve this issue you can give that user write permissions. You can see how to do that in this post.

How to specify a port for the ASP.NET Configuration Site?

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 ;)

Categories

Resources