We are migrating some ASP.NET applications from IIS6 to 7. In IIS6, you could create a website and then REMOVE the application. We have several sites with static content to migrate so we would like to do the same in IIS7 but cannot seem to find a way to remove the application.
OTOH is there any overhead to having a website in IIS7 that has an application but nothing ever compiles or 'executes'?
Yes, the non-executable applications are now called Virtual Directories. Map the "applications" as that.
Related
Is it possible to nest one ASP.NET website within another, for example:
http://example.com is an application root
http://example.com/differentsite is also an application root
If it is possible, what should be stuck in the web.config file of the parent website to prevent it interfering with the child site?
Note: This is for .NET 4.0 shared IIS7 hosting
Thanks in advance
Right click on the nested folder is IIS manager and click on "Convert to Application". This way they can live together. If you want them to run in separate processes so they won't have the same Application Pool settings, Create another application pool and assign one of the sites to it.
BTW, if the site folders are nested, they don't have to always appear in IIS manager as nested. You can add application to the default web site (or create a new site) and point it to the nested folder.
Yes, you can nest web sites by making folder an application, or adding a virtual folder that points to another application.
You need access to manage IIS on the server to do that, though.
I have a asp.net website in the IIS which is available on internet as www.xyz.com now I have been asked to prepare another website which will be accessed via www.xyz.com/abc.
For this, do I need to create a virtual directory under the website folder XYZ in IIS? or is there any other way to achieve this.
You need to make the subdirectory an IIS application.
Keep in mind that inner apps like yours will be inheriting configurations from the top-most web configuration, so be careful clearing those settings you don't want in the child applications.
Yes a virtual directory will work, however note that if abc is a full-blown app you will have to add it as an application not as a virtual directory
I have a Asp.Net Web Site deployed as a WebSite inside IIS 7.5.
http://localhost/WebSite
Then I have a second Asp.Net MVC 2 web application which is deployed as Sub Application inside the above WebSite. So the mvc aplication should work on the following Url.
http://localhost/WebSite/MvcApp/
The web site works fine but when I browse the mvc Url http://localhost/WebSite/MvcApp/
It gives following error.
HTTP Error 403.14 - Forbidden The Web
server is configured to not list the
contents of this directory.
UPDATE: I have got this working. The issue was that I was missing the Web.Config inside the Views folder in the Asp.Net MVC 2 application.
You might need to create a virtual directory for the ASP.NET MVC application which will be associated to its dedicated application pool.
I know I had the same problem some time ago. In my case the two applications ran a siblings, not one inside the other. The problem was the web.config in the root directory (above the two sites) conflicting with the the web.config in the seperate sites. I solved it by just deleting the root web.config (since I have nothing running in the root.
So my advice (I know it's definately not a solution) is to check for conflicts in your web.configs.
Is you Asp.Net MVC site running ASP.NET 4.0? If so, make sure the app pool for that MVC site is setup asp ASP.NET 4.0 and not ASP.NET 2.0.
From within IIS Manager, you can right click any folder in the tree to be converted to an application. Have you tried it?
It sounds to me like the mvc routing module is not executing on your requests. You might want to check to make sure that not only is the web.config in your base web application not loading a module to supersede the routing handler, but that the web.config for your mvc application is handling routing properly. Take a look at this article for a rundown of the dependencies for routing and how it is configured internally within iis.
I have a ASP.NET 3.5 web site, which is password protected (form authentication). But yesterday I found I was able to browse the list of directories (which is unexpected).
I searched the web, one article said we need to config it in IIS. But I'm a developer and I'm working on my local machine (no IIS installed).
My question is: are there any way to hide them other than IIS configuration? like set web.config?
This must be configured in your webserver - you cannot handle this in the website itself. Since you are working locally it shouldn't matter that the root directory is browsable. If you need to be able to control the site in this way you really ought to set up a webserver.
if you don't have IIS, you're likely working on your local ASP.NET development server (called Cassini possibly?), in which it is only available locally, so no security worries there.
When you deploy your app, you will likely be on an IIS server, so the configuration will be available
Directory browsing in IIS is controlled in the virtual directory/site configuration.
When you deploy your application to a real server you can configure directory browsing there.
Directory browsing on your local machine shouldn't matter, but this may work for you.
In IIS6: http://blog.crowe.co.nz/archive/2006/03/18/603.aspx
In IIS7: http://technet.microsoft.com/en-us/library/cc731109(WS.10).aspx
In IIS - Website properties, Home Directory tab, untick Directory browsing.
In Cassini (the ASP.NET development server) I don't think it can be turned off. But the server only runs while your debugging.
I am making this in a proactive attempt to head off any potential problems which could arise from this. The situation is that we are developing an ASP.NET application for a client which will handle the online ordering from their customers. This application is going to be using the same database that their current WinForms application uses (no real issue here).
At the same time we are developing a new front-end website for them using DotNetNuke. The DotNetNuke app will simply be linking to the ASP.NET application for the customers to submit their orders (no need for them to communicate back and forth, etc.)
The plan is to host both applications on the same box at the client location. What I am looking for are potential problems or setup tips which would prevent possible conflict between the two apps (web.config conflicts, etc.) Is there a problem with having both hosted on the same location, how should IIS be set up, etc.?
If there are any external resources also available which could address this, please feel free to link them as well.
Option 1: Make all the apps separate virtual directories off of the root website. Then have the root document redirect you to the proper subdirectory for the default application for that website(DNN).
Option 2: (DotNetNuke in root, other site in subdirectory) There will be many issues with web.config inheritance if the new application is not built with DotNetNuke, but you can get around these by blocking inheritance of the root web.config. Basically you add the following to your root web.config(DNN) file.
<location path="." inheritInChildApplications="false">
<system.web></system.web>
</location>
Option 3: As Scott said, create seperate sites with differnt subdomains and link them together. You can setup a redirect so whatever.com/order sends a user to order.whatever.com.
Just an FYI, if you use
inheritInChildApplications in DNN 4.7-4.9.2 (haven't verified 5.0) you will run into ScriptManager errors, previous versions of DNN don't have the problem.
We host a DNN site for our corporate site on the same Windows 2003 server with a bunch of other sites (.NET 2.0, SugarCRM, and even some WordPress instances with PHP extensions in IIS). These sites are 'separate' websites, and not subwebs of the default site. It's a real melting pot, and it works well. We did create some separate app pools for the PHP, .NET 2.0, and .NET 3.0/5 sites to ensure that they did not foul each other.