What is the recommended folder to write the web application log files?
c:\inetpub\wwwroot\Logs, App_Data folder... ?
I prefer App_Data which is always writable by design and closed to access from the browser by ASP.NET filtering module.
You should consider keeping your logs on a separate drive to the one that contains your Windows installation. This is because it is possible for your log files eventually to use all the space on your system drive, at which point your server will stop responding - keeping logs on a separate drive avoids this issue.
There is no standard location for application logs. Use what you and your team agree on.
IIS 6 logs normally live in %WINDIR%\Logs.
IIS 7 seems to default to %SystemDrive%\inetpub\logs\LogFiles.
You may need to give special permissions to that folder , so make sure (for security reasons) it resides outside the web application folder
This really depends on you where you want it to store. i will recommend you to use elmah
(Error Logging Modules and Handlers for ASP.NET) which gives you flexibility to handle logs
Chetan
http://chetanwarade.wordpress.com/
Related
I wrote an XML Web Service that run with an unmanaged dll which creates a file for writing.
But when my unmanaged dll tries to use _wfopen to WRITE something into an existing file, it causes a security issue: ACCESS DENIED!! And then _wfopen receives a NULL back.
I originally used _wfopen with r+b to access file. To test the permissions it had,
I tried to change it to use rb (Read file only), then the file opened successfully. This means I can access the file with READ access.
I also found that directly accessing the file through C# code does not cause this problem.
(e.g. if I use File.Create etc.).
The OS I'm running is WinXP Professional SP3 with IIS 5.1. So there should not be directories or files permissions not set properly in such a system.
Is there a way to solve this problem?
After lots of Code Fighting, I came to a conclusion: THIS MAY NOT BE A CODE PERMISSION ISSUE.
So I tried to configure my web service in IIS.
I finally found that configuring the ASP.NET tab of the property page can solve this problem.
On the ASP.NET configuration page, I go to the Application tab and check Impersonate in Identity Settings, and input username/password with my computer login data.
After that, everything went well and the problem was solved.
I hope this helps for those who have the same problem as me.
Thanks for any advice!
Background: I support a classic ASP environment. I have a development setup locally on my machine as part of that support. I am running IIS7.
To access my environment, I use "http://localhost:99999/" (port # faked for privacy purposes). I have not had a problem with this -- until today.
I built an application that is intended to run in this environment. The app is ASP.NET v.4.0 (for sake of example, I'll say it's called "http://localhost:99999/DotNetApp/"). Of course, in order to run this, I had to set up my environment application pool to support it (which it now does).
Problem: after configuring this, I am now getting:
Server Error in '/' Application.
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to '[filepath]\SourceFiles'.
I did NOT get this before I set my IIS configuration. Why am I getting this now?
Note: this ONLY happens with "http://localhost:99999/"; this does NOT happen if I try "http://localhost:99999/default.asp" (the page comes up with no problem).
Anyone have any insight?
Thanks in advance . . .
Edit: Additional symptoms: I tried playing with the application pool settings. The problem goes away if I change the .NET Framework version to either 2.0.50727 or to "No Managed Code." Changing it to 4.0.31319 breaks it. Of course, if I use any of the other two versions, my ASP.NET app won't run.
Edit #2: This problem occurs on ALL links that go to a folder or directory (e.g. "http://localhost:99999/somefolder/"), not just the web root.
Edit #3: I have a workaround: set "http://localhost:99999/" and "http://localhost:99999/DotNetApp/" in separate application pools. The first runs in .NET 2.0, while the latter runs .NET 4.0. (I'll post this as an answer once my 8 hour limit is up.) Probably not the best answer -- I'd prefer something that isn't as much of a kludge -- but for the time being, it'll get the job done. However, if anyone has a solution that enables me to run everything in the same app pool, by all means, post away!
You probably must specify "default.asp" as allowed in your "Default Document" settings in IIS7
EDIT: Check if ASP has been installed: Control Panel -> Programs and features -> Windows Features -> Internet Information Services -> Www services ->Application Development Features-> ASP
EDIT Final solution: The IUSR account is missing from the folder the website is in.
Set the default page for your site in IIS.
Try to set permission "Everyone" for directory "[filepath]\SourceFiles/" or/and "Allow" for other user names and groups in folder properties.
when I clicked on Browse *;80(http) I got this screen in IIS..what could wrong? please give me solution.
Try installing the ASP.Net Frameworks.
Also check whether you have configured web config file in a proper manner.
All frameworks are very important as far as the configuration goes.
Hope this helps!!
The issue you are running into is a common problem for developers since they start developing on their Desktop or their Documents folder without realizing that only they have access to them. In other words those folders only have ACL's for you. This works ok when you use Visual Studio since they run the process as your identity which makes it all work, however when you use a real server, such as IIS that runs as a service it will no longer run the process as your identity but some service account which will NOT have access to your directory.
You will need to add ACLs for IIS to be able to read the files (IIS_IUSRS or the AppPool Identity like IIS APPPOOL\DefaultAppPool, depending on the settings of your apppool), or move it to a folder that has enough access such as \inetpub\wwwroot\
Is it possible to look into multiple virtual directories, using a single web application?
I'm trying to develop a web app; which can create a site, save this site to a virtual directory in the same server, and make changes (i.e. add/edit webpages).
The web app will handle multiple domain names (IIS will handle the bindings going into the single web app), which are routed by the web app to their respective virtual directories.
Can anyone point me to the right direction?
Thanks!
First of all, you need a certain permissions in order to manipulate the IIS metabase. The default ASP.NET user account doesn't have such permissions so you might want to use an impersonation. You can read more here (what is impersonation) and here (how to impersonate programmatically).
To configure the IIS programmatically use the classes from the System.DirectoryServices namespace. You can read more about how to do this here (tagged as for IIS6). You can also use the Microsoft.Web.Administration namespace (which seems more specific to IIS7) but in this case you need to download and install the corresponding SDK.
Hope I clarified things for you a bit.
Writing to a file is not working after hosting the web application, whereas they were working while developing and testing in my localhost on debug mode. What could be the problem in writing to a file after hosting? Is there any special permission that should be given to the folders/file?
Without knowing the OS version or the code you're trying to use, I'd say the most likely culprit is permissions. The ASP.NET user (which varies based on version of Windows) needs write access to the folder you're trying to write to. This is likely not enabled by your host.
Yes, you will need read, write, and modify permissions to the directory you wish to write to. You need to ensure that the account under which ASP.NET is running has those rights set up.