I have a website that was building without any issue on multiple servers.
But, when I copy/move it on the same machine from one folder to another folder: I started getting the error
The Virtual Path Maps To Another Application Which Is Not Allowed.
What am I doing wrong?
The source of this problem is that when one copies an ASP.NET Web Site to a new folder -- the properties setting associated with the solution "Virtual Path" is set to the folder name and not the root. The solution is to change the Virtual Path setting from the folder name to "/".
This can be found by right click the project and opening the properties dialog: Solution->Properties->Virtual Path-> Change to "/"
This isn't why your error happened but it may be useful to someone researching the problem who ends up here.
If your web app is running as an application within another IIS site (set via the IIS administration tool) and is attempting to reach resources of the other site by means such as HttpResponse.Redirect, make sure the project isn't set to use a separate IIS in Visual Studio. If it is, it may be firing up inside a different IIS than the rest of the site.
Additional check: Missing global.asax also causes the same error.
If you are creating a new HttpContext and calling any external
service, it also causes the same error.
Key is you should not create new HttpContext, change the existing
context to your needs.
Related
I have the following error after move my website from server to another server
I have already checked iis and make sure the app has an application pool and it points to the correct file path
here is a screenshot of my application pool
I even tried to add virtual directory and add application and still not working
Check siteMapFile attribute of sitemap
The possible reason behind the issue is:
When you create a new web application using visual studio.net, it automatically creates the virtual directory and configures it as an application. However, if you manually create the virtual directory and it is not configured as an application, then you will not be able to browse the application and may get the above error. The debug information you get as mentioned above, is applicable to this scenario. To resolve it, Right Click on the virtual directory - select properties and then click on "Create" next to the "Application" Label and the textbox. It will automatically create the "application" using the virtual directory's name. Now the application can be accessed.
When you have sub-directories in your application, you can have a web.config file for the sub-directory. However, there are certain properties that cannot be set in the web.config of the sub-directory such as authentication, session state (you may see that the error message shows the line number where the authentication or session-state is declared in the web.config of the sub-directory). The reason is, these settings cannot be overridden at the sub-directory level unless the sub-directory is also configured as an application (as mentioned in the above point). Mostly we have the practice of adding web.config in the sub-directory if we want to protect access to the sub-directory files (say, the directory is admin and we wish to protect the admin pages from unauthorized users). But actually, this can be achieved in the web.config at the application's root level itself, by specifying the location path tags and authorization.
in your case the site map section causing the issue. try to remove it from the config file.
You could refer this below link:
Nested ASP.NET 'application' within IIS inheriting parent config values?
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
I am currently putting a new version of my site online. I would like to retain the old site (for purposes of read only access) and have been directed to place it within a subfolder inside the directory where the site use to live. e.g.
www.example.com needs to be moved to www.example.com/old and the new site needs to be moved to www.example.com
Unfortunately I get the classic ASP.NET error when attempting to piggy back sites that each have their own web config.
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.
How can I compeletly seperate off the new site and access it via. www.example.com/old without ASP.NET trying to trickle down through my directories and find the main sites web.config?
Thanks!
Giving the site its own AppPool should work.
You can do this by creating an AppPool and then on the virtual directory in IIS setting the app pool to your new one in the properties.
Make sure that the virtual directory is an application and not just a virtual directory.
You may try the following setting in the site contained in the virtual dir:
<location inheritInChildApplications="false">
Rick Strahl has the same problem and describes his experiences on his blog.
Didn't try it out myself, but found other blog articles which use it successfully with IIS6.
I've tried both creating a new App Pool on the site. That's didn't work -- same errors. I also added the inheritChildApplications attribute directive in my web.config. That didn't work either. The only way I have been able to achieve what I needed was to add a new subdomain in an entirely new folder and put a redirect to it in my www.example.com/old page to old.example.com.
It's not what I was looking to do, but it solved the issue.
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.
I'm moving some ASP code from one server to another. The location names are slightly different and I suspect that now the "global.asa" isn't getting called properly. The location is in c:\Inetpub\wwwroot\myApp.
It belongs in the root folder of your application. Also make sure that that folder is a application in the IIS manager. There is a textbox for application name, and right next to it a button "Create", if the folder isn't already an application.
Make sure that "myApp" in IIS is defined as an application. I would also check the .Net application mappings to make sure .Net is handling your requests.
The global.asa should be in the root of your virtual directory. Note that global.asa is used by asp not asp.net.
You can generally tell by looking at IIS Manager whether or not your directory is a virtual directory as it will not look like a yellow folder. If it does look like the typical yellow folder, right click the parent "Default Web Site" or whatever, and choose new virtual directory.
Alternatively, the global.asa can go in the root of the Web. Which is typically C:\inetpub\wwwroot if you are using the "Default Web Site"
For convenience, I want to keep in a subdirectory. Apparently, you have to designate that directory as an application. Here's a link that describes how:
http://www.calcaria.net/ASP/2006/04/globalasa-file-doesnt-work.html
Generally, I'm against the idea of files which are called auto-magically and not referred to in the code. If you are a noob like me, you can go off the rails for a while, before you track it down. I just lost a couple of hours on this silliness.