Question

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:

    <rewrite>
       <rules>
       <clear />
          <rule name="Redirect rule1 for Static404Redirects">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
               <add input="{Static404Redirects:{REQUEST_URI}}" pattern="(.+)" />
             </conditions>
             <action type="Redirect" url="{C:1}" appendQueryString="false" />
           </rule>
        </rules>
    </rewrite>

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!

Answer 1

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.