Is there a possibility to move App_Data catalog in ASP .net application? I want it to be stored at C:. I tried to change path in my Web.Config file, but all the time i get a different errors, like access to the path is denied (I have copied all the permission to my new App_data folder).
If you are attempting to store something in a specific directory like C:\, you'll need to make sure that IIS have the appropriate permissions to handle performing these actions (as generally it will only be able to access the directory of the application and IIS' root directory).
If you are debugging your application locally, you might ensure that you are running Visual Studio with Administrative Rights (i.e. Right-click > Run as Administrator) as the process spawned from it will likely not be able to access directories that would otherwise require it.
Otherwise, you can check the permissions on one of the following roles, which will vary depending on which version of IIS you are using and ensure that it has the proper permission(s) :
IIS_IUSRS
IIS APPPOOL\DefaultAppPool
NETWORK_SERVICE
Generally speaking, it's not a good idea to give root access to your applications. If you are going to be using this in any kind of production manner (outside of a quick and dirty utility application running on your local machine), you should consider using a sub-directory from within your application and referencing the files from there (i.e. drop the files you are attempting to access in your Project and access them relative to your application).
Related
Currently we have following structure:
web
build0001
build0002
build0003
So, each time we deploy new version of web application, we create folder with build number and then change path in IIS to use that directory.
Now question is, can I do same thing with msbuild:
1) publish to web\buildxxxx
2) and update IIS setting to use web\buildxxxx for that site.
While currently I doing all this in same server, in the future I'll need to do this on remote servers also, meaning that I'll running msbuild from different server than IIS is.
So far I've came to this:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe"^
-verb:sync^
-source:contentPath="c:\stageDir"^
-dest:contentPath="c:\web\build0004",computername="https://remoteServer:8172/MsDeploy.axd?site=MySite",UserName="DeployUser",Password="xxx",authType=Basic^
-enableRule:DoNotDeleteRule^
-allowUntrusted^
-postSync:runCommand="C:\windows\system32\inetsrv\appcmd.exe set vdir MySite/ -physicalPath:c:\web\build0004"
Problem with this approach is, that is requires a lot of permissions, because of these things:
build0004 at the moment of syncing is out of current website's folder (say build0003), so it requires DeployUser to have administrative rights.
I need ability to use runCommand, which requires even more - allow WMSVC to run commands.
Can I safely delete the contents of this folder
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root
on a Windows 2003 R2 standard system, given that I am not using IIS (6/7) on it?
If that is the case, could you please point me to the relevant documentation about ASP.NET's runtime and maintenance tasks such as this?
Yes, it's safe to delete these, although it may force a dynamic recompilation of any .NET applications you run on the server.
For background, see the Understanding ASP.NET dynamic compilation article on MSDN.
Just an update on more current OS's (Vista, Win7, etc.) - the temp file path has changed may be different based on several variables. The items below are not definitive, however, they are a few I have encountered:
"temp" environment variable setting - then it would be:
%temp%\Temporary ASP.NET Files
Permissions and what application/process (VS, IIS, IIS Express) is running the .Net compiler. Accessing the C:\WINDOWS\Microsoft.NET\Framework folders requires elevated permissions and if you are not developing under an account with sufficient permissions then this folder might be used:
c:\Users\[youruserid]\AppData\Local\Temp\Temporary ASP.NET Files
There are also cases where the temp folder can be set via config for a machine or site specific using this:
<compilation tempDirectory="d:\MyTempPlace" />
I even have a funky setup at work where we don't run Admin by default, plus the IT guys have login scripts that set %temp% and I get temp files in 3 different locations depending on what is compiling things! And I'm still not certain about how these paths get picked....sigh.
Still, dthrasher is correct, you can just delete these and VS and IIS will just recompile them as needed.
The Background (skip to the bottom if you want the question)
Recently I upgraded an SVN repository (hosted on assembla) to SVN 1.7. After doing so, we started to intermittently encounter lots of File Access Denied errors on the ASP.NET site pages that sit in the local working copy of the repository.
Some folders also started to get weird file permissions (they became marked read-only) and user sharing got removed from them. These problems would only start occurring after an update/commit cycle, via AnkhSVN's Visual Studio plugin, but not all the time; it seemed highly temperamental.
The only temp-fix we've found so far is to commit any outstanding changes, delete the local copy and re-checkout a full working copy (with TortoiseSVN). However, that is not a viable fix, and it is seriously impacting on productivity.
This site is an Azure based ASP.NET WebWorkerRole. It has never given problems before the upgrade to SVN 1.7. I tried fiddling with the internal IIS permissions to get around the problem, however, no dice.
My Environment
Visual Studio 2010 Ultimate 10.0.40219.1 SP1
AnkhSVN 2.3.10509 (latest version, supports SVN 1.7.1)
TortoiseSVN 1.7.1, Build 22161 - 64 Bit
Running in Debug Mode via the Azure emulator environment
The Question
Is it possible for SVN 1.7 or any of the tools in my environment to break file permissions so that the files become unusable in an ASP.NET site? and more importantly, how do I fix this?
The exact file permission error dumped out is this:
Access to the path '//file//' is denied.
Description: An unhandled exception occurred during the execution of
the current web request. Please review the stack trace for more
information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the
path '//file//' is denied.
ASP.NET is not authorized to access the requested resource. Consider
granting access rights to the resource to the ASP.NET request
identity. ASP.NET has a base process identity (typically
{MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and
the configured application pool identity on IIS 7.5) that is used if
the application is not impersonating. If the application is
impersonating via , the identity will be
the anonymous user (typically IUSR_MACHINENAME) or the authenticated
request user.
To grant ASP.NET access to a file, right-click the file in Explorer,
choose "Properties" and select the Security tab. Click "Add" to add
the appropriate user or group. Highlight the ASP.NET account, and
check the boxes for the desired access.
But a clean working copy will not generate this error. Comparing the permissions of the two, it seems the working copies that are not bugged are shared (with IUSR and the local account), whereas the broken ones have zero sharing, yet the sharing is never changed by the user.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place.
(Subversion doesn't change the permissions itself on Windows)
I solved this by accessing the security settings for the website folder and and clicking Advanced and then Change Permissions for the IIS_IUSRS user. I checked the "Replace all child object permissions with inheritable permissions from this object" and clicked apply.
Before that, I had given the IIS user full permissions to the hidden tmp folder in the root of the checkout, but I don't know if this helps with anything.
I'm not sure if this is a permanent fix, but in case it is not, you can at least use it to reapply permissions for all the files in a single operation.
Much information is located in .svn folders inside directory where project was checked out. So in my opinion better use SVN separately from advanced integration tools. Also this deals with solving problem like this.
I found this exact same issue happened when I did a 'Revert' using:
Tortoise Svn 1.6.16
AnkhSVN 2.3.11269.1348.
Visual Studio 2010 Professional
Windows 7 - 64 bit.
I was completely puzzled the first time I encountered the permissions error and started off by thinking it was my code. After a while of fiddling about I ended up deleting the whole project and re-downloading from Subversion which fixed the issue.
When this problem happened again I looked more closely at the reverted file, and I found the permissions on the reverted files do not match the permissions of the other files. Specifically 'Users' permissions, for the machine that Visual Studio is running on, is missing altogether.
So I just added it in by:
Right clicking on the problem file. This caused the file properties window to appear.
Then clicked on 'Edit...'. The permission window appears.
Then clicked on Add and the 'Select Users, Computers, Service Accounts, or Groups window appears.
Click on the Object Types button and check all the boxes.
Click on the Locations button and make sure your machine name is selected.
Type in 'users' then click the 'check names' button.
Click OK on all the windows to close them.
Your website should now run without the permissions error.
When creating a new database with SQL Server Express 2005, the database files (.mdf and .ldf) get stored in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data by default.
However, with the tutorials I've seen for ASP.NET MVC (e.g., Nerd Dinner), it seems to be common practice to keep the database files in the ASP.NET project's App_Data folder.
Questions
Is there any significance to the App_Data folder, or is it just a convenient place to store database files if you happen to use Visual Studio's designer to create a new database?
Will there be any negative repercussions if I don't use or even delete the App_Data folder?
Update
One thing I'm still not getting. If you have a production database on the server, why would you even want to replace this database with what is in App_Data. Wouldn't you normally just want to have update scripts that you run on the production database when you release a new version of the app? Even for initial deployment, I'd rather script database creation than physically copy over the files. Also, with SQL Server (Express) databases, copying is not enough. You have to detach the database to manipulate the files then reattach when you are done.
So, I have to say, the point of App_Data still escapes me. Can someone enlighten me?
You can delete App_Data without any negative repercussions, but when it exists (by folder name) inside an ASP.NET website then it has the special website power of disallowing direct linking to download its contents - this is a security feature to protect your database from being downloaded directly over the web (e.g. by a web browser) even though it exists in the website. However your application can still access the files in the App_Data folder just as it accesses other website content.
Microsoft states it as:
Note: The content of application
folders, except for the App_Themes
folder, is not served in response to
Web requests, but it can be accessed
from application code.
Microsoft describes their special ASP.NET folder structures including App_Data here.
There are a number of advantages of placing database files in the App_Data folder:
As some have mentioned, that folder is secure from people browsing it directly on the web. This is also true of placing the database in folders outside of your web site, though.
You can "xcopy deploy" your application by copying the entire folder from your local development machine to your hosting web site.
Various components in Visual Studio can offer extra assistance in building your application by having your database files there. For example, you can double-click on a SQL Server Express MDF file and have it automatically open up in Server Explorer so that you can change the database's schema or view its data.
There is absolutely no need to use the App_Data folder. It's just a convenient place to keep your database files together with your site. The decision to use it or not is more a matter of preference / policy than anything else.
yes, when you are simply using an express database which will exist within your webroot it is best to use the app_data folder. The primary reason is that the asp .net isapi implicitly knows not to fulfill any requests for files from this directory. The same goes for the app_code folder. There is no stipulation that you have to but its good practice to be prudent.
You can also store sensitive xml,access dbs and any other data files in here for added security.
I've only ever used it for local development before pointing the web.config at a SQL server instance rather than the db files.
I have a web application running on IIS. Instead of using a database it reads and writes to a couple of XML files. I currently store these files in the Application Data folder in windows. This folder (\Documents and Settings\All Users\Application Data in win 2003) however requires at least "Power Users" privileges to write!
Reads are OK and are granted to everyone but writes are not allowed as long as your not in the one of the more privileges groups on the system. Why is this so? Is there a better place for a application to write to and one that does require me to add the user of the application pool to a more privileged group?
My second question is that if I have file that just needs reading. Can I then read this directly for the folder where I have my web application deployed (say a folder in "Program Files") or should I at all times use the Application Data folder?
The idea here is that this files sometimes need manual change and using the folder where the web application runs from would basically make more since to normal users I think (especially on win 2008 where the Application Data is hard to find).
Reads are OK and are granted to everyone but writes are not allowed as long as your not in the one of the more privileges groups on the system. Why is this so?
You don't want to allow just anyone to write to the file system via a web application.
Using ASP .NET, people usually use the APP_Data folder to store data files that need read/write access to an account such as Network Service.