Take the 2-minute tour ×

I have to apply some redirect rules on IIS7/VS2008 and have question on how to deploy it. We have a website and not web application and hence most of other SO questions were not useful to me.

in order to apply rule like below in website:

       <clear />
          <rule name="Redirect rule1 for Static404Redirects">
            <match url=".*" />
               <add input="{Static404Redirects:{REQUEST_URI}}" pattern="(.+)" />
  1. in Bin folder there is no websitename.dll. just some other dlls like Ajaxtoolkit.
  2. Should it have any dll/assembly/GAC being a website?
  3. I can simply copy test server web.config to production w/o using any IIS UI for rules part and It should work.
  4. Also will the application need to be restart from IIS after web.config change? or new change comes into affect by itself on saving web.config?

Is this correct? or will I need anything else to do? I am afraid will web.config change make any assembly changes/dll/version or any other changes that I should think of first? As I mentioned its website project and it doesnt even have VS2008 installed on Prod. Basically I want to be sure I know what am I doing.

thank you!

share|improve this question
Are you sure you have IIS6 installed on Server 2008? That doesn't make sense. –  pwdst Jan 16 '13 at 23:02
Thanks for reply! you are right, i was told it was IIS6 and just now heard back from my sr. that its IIS7.0. –  user704988 Jan 16 '13 at 23:08
Aren't these all just .config? It shouldn't matter as long as they're in the application root folder, IIS should just pick them up? –  Lloyd Jan 16 '13 at 23:09
It is in root folder, so will it be just fine to update web.cofing and nothing else to do? I have no idea if/what I have anything to do with GAC/assembly stuff. –  user704988 Jan 16 '13 at 23:15

1 Answer 1

up vote 1 down vote accepted

Assuming you are in fact using IIS7 (AFAIK it is not possible to install IIS6 on Server 2008) the code above is in the syntax of that used by the IIS7 Rewrite Module. This is an extension and not installed by default with IIS, it will need to be installed separately on each server.

1 + 2) A web site (as opposed to a web application) can either be deployed compiled or uncompiled. If the site has been compiled then there will be one or more dll files in the bin directory which contain the code to build the objects used in your site, with placeholder files for the aspx pages. The advantage of a compiled site is that it will perform faster, particularly from a "cold start" (where the site is not held in memory on the server). If the site is not compiled it will either have .aspx.cs/.aspx.vb files containing the code, or

<script runat="server"> // code here </script> 

tags within the .aspx file itself.

3) The IIS GUI is simply an easier way of generating the rules that will be placed in the web.config file. Copying a file between servers should work, as should copying from your dev to live environments (usual rules about changing connection strings etc. to those appropriate for the live environment apply). Some devs will create rules on their dev server or local machine and deploy them in just this way. If you want you don't have to ever touch the IIS GUI at all, but just write the rules in code. For the rules to work you will need to have the IIS 7 Rewriter module installed on each of the servers.

4) Saving or "touching" the web.config file will force a restart of the application. In process session data will be lost (as a negative) but the rules should be working with immediate effect - no IIS reset is required.

Changing the web.config to add new rules should not break any of your code or compiled assemblies beyond obviously damaging changes as long as the attributes and XML syntax remain valid - changing or deleting application keys or connection strings, the target framework, custom errors or debug mode will obviously all affect your site. There is no need to republish though. As XML is intentionally fragile with syntax errors I'd strongly recommend testing your changes on a non live site first, messing up a web.config is one of the fastest ways to take down an entire site.

share|improve this answer
Thank you so much for explaining these. I safely assumed it was a uncompiled website as server has .aspx.cs files but I was starting to get confused if it had some assemblies/dll at some other place I am unaware of. and if I had to deal with GAC/command line tool etc. –  user704988 Jan 16 '13 at 23:50
As a side question how about deploying a module in IIS on Prod ? Ex document link In that case, can I continue using only web.config from devel to prod? –  user704988 Jan 16 '13 at 23:54
I haven't any real world experience of writing and deploying custom IIS modules, and I'm not sure I understand the question, so you might be better off creating a new question with the appropriate tags so someone with more specific IIS experience can answer. –  pwdst Jan 17 '13 at 19:44

Your Answer


