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.
Related
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.
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 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.
I have to implement ability to show "site is under construction" page during doing some maintenance work on site. There are a lot of ways to implement such behavior (using global.asax file, using IIS and so on). So I would like to know waht is the most used ways of impletenting this feature.
Thanks in advance.
I prefer App_Offline.htm file in the root.
Take a scrape of your site template, stick it in the App_Offline.htm file and place a message in it. Just dropping this file in the root folder of your web site effectively disables your site.
Meanwhile, upload/manage a second instance of the web-site using a temporary domain/URL and when tested/ready, re-point the old site to the new site in IIS.
The change you're deploying now is a simple change to a single page. But sometimes you deploy larger changes, or you deploy both code and database changes, and the site might behave incorrectly if a user requests a page before deployment is finished. To prevent users from accessing the site while deployment is in progress, you can use an app_offline.htm file. When you put a file named app_offline.htm in the root folder of your application, IIS automatically displays that file instead of running your application. So to prevent access during deployment, you put app_offline.htm in the root folder, run the deployment process, and then remove app_offline.htm after successful deployment.
Source: https://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/deploying-a-code-update
I have a situation where I have several root applications that will reference the same virtual application. The root applications are the "branded" front-ends that are fairly light, with the virtual application doing most of the work.
I was planning on having the virtual application use the Master File of the root application by referencing it with a "/" prefix, but have found out the hard way that this isn't allowed.
I have seen options such as compiling the Master Page as a .dll but I don't think I can apply this to me scenario because the Master Page will be different for every root application.
Does anybody have any ideas on what I can do as an alternative? Is it possible to get creative with an inline Response.WriteFile call from the virtual to the root calling User Controls, or is there a downside to this?
Any ideas or assistance would be greatly appreciated. Thanks!
One way around this problem is to not create the virtual application as an application in IIS. By doing this, master page files from the root can still be used since there is only 1 app domain. The downside is that you will have to merge your "bin" folders together under the root.
I don't see a very clean way to do this other than what has been proposed by the other users.
Creative thinking:
Cheap hack #1:
One way would be to use mklink on the server to create a directory junction. Cheap but you could easily script it and both folders would get updated at the same time.
Cheap hack #2:
Have your master pages include an iframe to the shared vdir.