What is needed to run a webapp in IIS with absolute paths - asp.net

I previously made my "Web Applications" type of projects inside some individual directories
and have been making "Web Site" types (based on visual studio's project types") inside IIS.
Although It should be a repetitive task but I want to know the most usual needed steps for doing so
What I need :
Access to the media with absolute paths
As an example
I placed my project inside "IIS Root folder/ProjectBase/Project"
and convert that to Web Application via IIS.
It seems that I couldn't access to my stored media files within the Project Folder.
What is the exact problem in this case ? Is it related to folder permissions of the "Project Folder" ?
Also should I make the "ProjectBase" Folder also a virtual directory ?
the program is running via cassini,
At first I want to have access to my Project based files via "absolute paths"
As a conclusion
Having "Web Application" Type running with possibility to access to its files via absolute paths.
It should be an easy task for the Pros, but, anyway I'm in hurry and needed good-fast advice.
thanks in advance

Could be a file permissions issue. You can resolve that by going through IIS and setting the permissions on the folders. Grant read/write to the IIS user for that machine. If you're actually writing anything back you may need to grant access to Network_Services as well.
Also you can look at adding a virtual directory to the website in IIS and point that to the actual physical directory on the box. That has solved some file access issues for me in the past.

Related

Asp.Net is looking for the web.config in the wrong place

I've got a strange issue - Up until now I've only worked on this application on a single machine. I've downloaded an asp.net web app onto a dev machine in a clients office.
When I try to run the application in debug mode through Visual Studio I get 500.19 error - typically this means a permission problem. I went through the motions of checking the permissions before I noticed the directory it was looking for the config file in.
The 'Config File' shown on the error is
\\?\C:\Users\{my-name}\Documents\{project-name}\web.config
however the correct location is actually
C:\Users\admin\Documents\projects\{project-name}\web.config
Does anyone know where the location of the web config is specified? I had always assumed it could only ever be in the root directory.
As it turns out the cause of this was upgrading to Visual Studio 2015.
Rather than a .suo file the new Visual Studio has a .vs folder with files specific to an instance of a project. The root directory of the development site is included in here.
I deleted the files and added .vs/* to my .gitignore file and had no more problems.
At our infrastructure it turned out that inside the web.config withing the node <system.webServer>, we had a nested node named <rewrite />. That one wasn't recognised by IIS.
By either removing that node or installing the missing feature (url-rewrite), the application started as expected.
In my case, the top level website in IIS had a physical path of:
C:\Users\MyUserName\Documents\My Web Sites
For some reason, this meant IIS refused to look anywhere else, even though my projects underneath had been converted to applications.
Fix for me:
Go to IIS
Right click on the top level website (i.e. 'Default Web Site', or the problematic website at the same level)
Select 'Manage Website > Advanced Settings'
Change the physical path to C:\inetpub\wwwroot
Save and reload website
I could then have any path for my applications and IIS could work it out as expected.
Assuming you mean Documents\projects\{project-name}\web.config instead of Documents\projects{project-name}\web.config you're seeing the effect of Application Scopes.
In IIS, multiple entirely separate web-applications can be part of the same website by being split-up into "Application Scopes" - which usually works by specifying a prefix path followed by the Scope root (prior to IIS7 an Application Scope could be a physical or virtual directory, since IIS7 they're always virtual directories, but can still represent a physical directory).
Open IIS Manager and select the (virtual )directory that Visual Studio created for your project and right-click it in the left-side Navigation pane and choose "Convert to Application", then ASP.NET will look for the web.config file (and the bin directory, amongst others) in this folder only, rather than the website root.
Note that the website root is also considered an application scope root, hence the common error message "Exception in "/" application". If you get a YSoD in another application root you'll see "Exception in "/subFolder" application" messages.

the element 'buildProviders' cannot be defined below the application level

I have created an asp.net C# application developed in visual studio 2010, which is running without any error on my PC, but when i tried to run the same application on another computer with visual studio 2010, it gives following error,
The element 'buildProviders' cannot be defined below the application level.
Following article at http://forums.iis.net/t/1160248.aspx?The+element+buildProviders+cannot+be+defined+below+the+application+level+
You probably need to convert the virtual directory to application. I encountered this when deploying my app (using NancyFX).
You can open IIS Manager->Right-click the diretory of your web application->Click Convert to Application.
I faced this problem and i found out that somehow i had another version of my website within the subfolders of my webstie.
Meaning that my website is in a folder called "FrontEnd". Withing this folder there is a subforlder called backup that contains a backup of my website.
when i removed the backup folder, everything went ok.
If you recently upgraded your solution, check for the backup directory for crystal report within your solution. The backup directory can get created when you upgrade visual studio. To resolve this error, closed the solution. Went to the solution directory
and delete or move the backup directory to a different location outside of the solution directory. This solved the problem for me
You can fix this problem either defining the element in the web.config file of the root dir or setting Virtual Directory as APPLICATION in IIS.
For doing this with IIS 6.0, you first have to set the the directory in which your site is present as a Virtual Directory and then define this virtual directory as an Application.
All physical directories under Inetpub\Wwwroot are not considered applications until the following procedure is used:
Open IIS Manager.
Expand the Default Web Site node and look for the subdirectory that you want to designate as an application root.
Right-click the directory that you want to mark as an application root, and then click Properties.
On the Directory tab, in the Application Settings section, click Create.
In the Application name text box, type the name of the application, and then click OK.
The virtual directory is now an application root.
Maybe on oppening website you were selected upper project directory as website root
In my case, the issue was that the web.config inadvertently existed in a subfolder of the applications root folder. I had a "temp" subfolder, and I had placed a copy of the web.config there, unaware of the unintended side effects. The solution in my case was to remove the dup copy in the subfolder. Hth
(In my case name of project was repeating in directory )
The problem's solution is very simple: check its root directory in Solution Explorer. If there is a name folder within another name folder then this error will occur. Your web site contents should be very first after your web site name folder. In other words, contents should not display in another same name folder.

ASP.NET - Publishing a web site to IIS

What is the difference between publishing a website to {localdrive}\inetpub\wwwroot and anywhere else on the web server e.g. C:\Website.
I have noticed that I am always left with a directory and a website in the IIS console if I publish to {localdrive}\inetpub\wwwroot.
After reading articles on MSDN, I am still unclear of the difference. I realise that there is probably a simpe answer to this, but I cannot find it.
The web path / is already mapped to c:\inetpub\wwwroot, so /abc is mapped to c:\inetpub\wwwroot\abc automatically.
When you publish to c:\website, you need to set up a virtual path manually.
Nothing too much as your website path in IIS can point to any directory. However, that being said always double check your directory permissions and security settings. In addition, I guess if a hacker did compromised your webserver... the default c:\inetpub\wwwroot is well known.
And just for good measure in case you are having issues - check out the Aspnet_regiis.exe tool on MSDN as it usually solves a lot of issues for folks.
{localdrive}\inetpub\wwwroot is usually used for the default web site that comes with IIS.
Additional Microsoft products use the same directory and take advantage of the virtual directories that exist in the default site.
If this is your personal web site, or a web site you created from scratch, you can publish anywhere you want.
Before you publish, you need to make sure IIS knows where the directory will be, and you need to assign the correct permissions for that folder.
The default website in IIS is mapped to C:\inetpub\wwwroot by default, so publishing to wwwroot makes it easy to add applications as virtual directories.
However, you can publish wherever you like, and either point a virtual directory or new website at your publication location. You simply need to make sure user the App Pool is running as (usually IUSR under IIS7, IUSR_MachineName under previous versions) has read/execute permissions on the folder you are publishing to.
Although they say Virtual Directory created by default for your website in wwwroot and you don't have to configure it again. Many times I found we still have to go there and click on Remove and then click on Create button again :)
Thus it is almost no problem if you create your website outside wwwroot, only difference outside you have to give full path of VD and inside you have to click Remove and then Create button
The problem I had was different from all of the above. I was trying to publish in "C:\inetpub\wwwroot" and the publish failed every time. Than i changed the publish folder to another and it worked. When I launched visual studio as administrator I could copy to C:\inetpub\wwwroot also without problems

asp.net log files permissions

Our asp.net app writes errors to a text log file in the web sites root folder. This has lead to all sorts of permission problems, different flavors of IIS and windows allow different things by default.
So what I am wondering is there a location somewhere in Windows where all types of users can write a file without any extra permissions that will also work for all IIS and flavors of windows?
I am thinking of the ApplicationData folder, but did this exist in Server 2003 ?
Thanks,
AJ
The easiest solution would be to use the App_Data subfolder of your web application for this. By default it's not viewable from the web, so Internet clients won't be able to read the logs.
Depending on your deployment method, you might have to change the permission to allow write access to this folder (to the user under which your web application is running).
Alternatively, there is a place where every user can write to: It's that user's temporary folder, which you can access through Path.GetTempPath. This, however, does not sound like a suitable location for log files.
You should always first think about wwwroot folder (%systemdrive%\inetpub\wwwroot) because it has the required permission.
The permission you need is to set a full control for IIS_IUSRS
Edit: you can simply give Everyone Full Control (not recommended at all) but this solves most of ntfs permissions issues with IIS

ASP.NET MVC - Website paths

I am using a 3rd party component which creates settings files based on hard-coded file paths i.e. they are compiled into the DLL e.g.
%APPDATA%\Vendor\Settings.ini
I have created a few console/service applications that use this and work very well. However, I am now trying to use a similar approach via my ASP.NET MVC web application and the settings file never seems to write out!
Usually if the application is running under my acconut for example the file would be written to somewhere like:
C:\Documents and Settings\James\Application Data\Vendor\Settings.ini
So I thought if the website AppPool was running under the same account the file would be saved to the same place....However, it never appears. The account is an admin account running under Windows server 2003.
Any ideas?
Thanks.
Have you checked to see if the settings file is created in the App_Data folder in the web application? If not, could you put an existing settings file there and see if it uses it?
It's not about the webpool account, it's about guest user's account.
Go to the properties of your site in IIS, Directory Security and in the anonymous access click on the Edit button, there you'll see wich account is been used when someone access your site.
Couldn't find a solution to this, so I decided to develop a local WCF service (which would create the settings file in the correct directory path) and just accessed it via my web application.

Resources