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.
Related
I've a .Net/C# Windows application which can create text/pdf files. My requirement is to make these files accessible via http links for another internal application inside my organization. The internal application only accepts http links (ftp and others are not supported).
I know this can be done manually by placing these files in an IIS server. I would like to know whether there is any easy way to do this programmatically? Once the file is created locally in my application, I should have a http link to access the file.
I'm not sure if I understand your need correctly. You can point it out when anything wrong.
Assuming that the application create pdf files in a folder named PDFile. On IIS, you can add a site and set it physical path to PDFile folder. If you enable Directory Browsing, you can see all files when enter the url of this site in browser like this:
When you want to access these file from an external machine, just enter the url http://serverIP:port/PDF file name for example http://xxx.xxx.xxx.xxx:80/mycustomefile.pdf. No need to set anything programmatically.
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.
In my Azure Web Site I have in my AppSettings section in Web.Config some references to files on my disk. When deployed to Azure those references doesn't count any more. I know that you can overwrite AppSettings in Web.Config in the Azure environtment. But what is the file structure there?
A couple of examples from my web.config that I have to solve:
<add key="DataMapPath" value="d:\inetpub\MyWebApp\App_Data\map.xml"/>
<add key="CuteWebUI.AjaxUploader.TempDirectory" value="C:\Temp\WebApp\Attachments\UploaderTemp"/>
The first file tells our code to look for the map.xml-file in the App_Data-directory.
The last one tells our upload-controll where to upload files. I maybe should have used Azure Blob Storage here instead but that would need some major refactoring of our code.
Is there som best practices on this topic?
Our WebApp is running in production today, but I want to try out MS Azure. But I doesn't want to do to many code changes to make it work in Azure.
I have also read you can spin up an Virtual Machine (Windows Server) but that is overkill for my needs right now. We may go that way in the end, but for this testing-purpose it should be made simple.
Any suggestions on how this could be solved? Someone done this before? I guess someone has. Indeed.
If I do have read and write access to the file system for my Web Site I maybe could use this:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TheFolder");
This would be appropriate for both on-premise and Azure deployment. But then I have to do some changes in our code.
You have multiple options:
Option 1: Use the App Settings of your web app to set custom settings for your website.
Option 2: Create multiple versions of your web.config (Visual Studio supports this) and deploy different versions to Azure and your local machine
Option 3: Make your path's relative to the paths of Azure Web App's environment variables
There's a HOME environment variable in your Azure Web App that resolves to the equivalent of inetpub for your site. Your app data folder is located at %HOME%\site\wwwroot\AppData.
There's also a TEMP environment both on Azure Web Apps and on your local machine. You can make your second setting relative to the TEMP environment variable value.
Actually you won't have this kind of "control" using azure web sites. To keep your app as it is, use Azure Virtual Machines.
I have created a web service which gives the data in JSON format, I am going to read this data to create a high-charts. When I coded this web service , I get values in string which I have serialized into JSON format and store it my folder on system, but problem is when I will deploy my web service in remote machine that time I will face the problem to store the file since I have provided local path as explained in below code,
System.IO.File.WriteAllText(#"C:\Json\Json.json", jSearializer.Serialize(modified_listofstrings));
Can anyone please suggest what I am suppose to do so that I can store this file in such a way that it will be easy to access after deployment of my web service in remote machine?
Is that possible or I will have to create a simple asp.net application and consume that web service and store that file in the folder of that newly created application?
I am very new to this concept hence I don't know about storing in virtual folder or something like that, I got suggestion to do so, It will be very grateful if someone explains me the concept as well...
You have two ways:
Give write permission to your application identity to write in c:\json folder, which is not a good idea.
Change your code to use relative path:
File.WriteAllText(System.Web.HttpContext.Current.Server.MapPath("/json"), "json-text");
Server.MapPath maps a virtual directory to it's equivalent absolute directory in OS. For example, if your website is hosted in c:\websites\json-project\, then using Server.MapPath("/foo") would be translated to c:\websites\json-project\foo path.
By default any ASP.NET application has full access to all of its folders.
You can find the physical path to your application by giving relative path something like Server.MapPath("/Json/Json.json")
for more information check below SO question
Server.MapPath("."), Server.MapPath("~"), Server.MapPath(#"\"), Server.MapPath("/"). What is the difference?
I have the need to read and write files on the server file system from within a WCF service hosted in IIS. This service is called via a Silverlight 4 application and RIA services. The file paths can be fixed to a known location on the server but we are having issues getting passed security issues and continue to get "Access Denied" errors. The application itself uses Forms Authentication and the web server is configured for anonymous access.
We haven't gotten passed this issue in our development environment and I'm assuming that in production we can specify a specific account in IIS to host the site under and then grant that account specific rights to the file system. In development using the VS 2010 development web server what are our options?
Our goal is to do something as simple as creating new files or deleting files from a known path on the server (i.e. "C:\Temp\") from within a method call to the WCF service. it's acceptable that it even be a temp folder underneath the virtual directory.
Your best option here: don't use the dev server for this; use IIS. Fighting tooling issues in something unrelated to what you are trying to do is a waste of time, so try to mimic your deployment environment as closely as possible.
You might also be able to use IISExpress for this, but since you know you already have nuances, I'd just go the whole-hog and use IIS. This also lets you hone the deployment process, which is a dev task.
Once setup, just create an app-pool and associate it with new account (not your account, unless it is going to be your account in production).