Archive for July, 2008

ASP.NET Development life after a Vista SP1 installation

Today I was prompted to install Service Pack 1 of Windows Vista on my development machine. "Sure why not, what’s the harm" I thought… Famous last words…

So machine goes through the various stages of re-genesis and restarts a new machine, to the point where I get the following error when I attempt to debug my ASP.NET project…

Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web server is running and that incoming HTTP requests are not blocked by a firewall.

Ok, so what’s the issue.  Hmm.. seems my Web server isn’t running, and according to IIS it won’t start until I start the following services:

  • Windows Process Activation Service
  • World Wide Web Publishing Service

So I start them and get my web server up and running again when I notice… Blam… I’m getting a heap of Javascript errors on my site??? After a little bit of checking I figured out that my .axd files for hosting the dynamic scripts were breaking with the following error:

HTTP Error 500.21 – Internal Server Error

Handler "Reserved.ReportViewerWebControl.axd" has a bad module "ManagedPipelineHandler" in its module list

After some reading on the Internet I discovered this is apparently due to my IIS7 Application Pool being configured for IntegratedPipeline when it needs to be in Classic mode… but this is strange because my site is already in Classic mode… turns out my app was expecting IntegratedPipeline mode (as denoted in the web.config by having handlers with preCondition="integratedMode") but the installation of Vista SP1 had changed it to Classic… weird!! Anyway changed my application pool from IIS Manager and everything started working again…

Here’s the steps to change your Application Pool:

  1. Start IIS manager
  2. Right click on the site you are having issues with and select Advanced Settings…
    image
  3. Select the application pool with the appropriate Pipeline mode for your web.config
    image

 

Oh dear, hope this helps someone else (and my time wasn’t wasted figuring this out)…

Here’s some useful reading on the subject:

Leave a comment

Hosting a WCF Service with ASP.NET Compatibility Enabled Kills my inner child

We host a couple of web services that integration partners connect to. One of the big challenges when hosting these services is ensuring nothing breaks for our integration partners when we upgrade the service with new features. The way we implemented this in WCF was to create a new Service Contract (or interface in C#) for each version that has new operations added to it. Then a single class can implement multiple versions.

Example

using Version1 = MyServiceApp.Version1;
using Version2 = MyServiceApp.Version2;

public class MyServiceClass : Version1.IUsersService, Version2.IUsersService
{
    public void AuthenticateUser(string userName, string password)
    {
        // Act like a V1 and a V2 web service
    }
public void SomeVersion2Method(string someVersion2Param)
{
// Act like a V2 web service
}
}

To ensure that the web service consumers are aware there is a new service we like to host each version at a separate web address. We name each service with the month that implementation for that version began, as this is usually a constant that doesn’t change throughout development, unlike release dates which can be pushed… 😉

Example

Version1 hosted at http://www.ourdomain.com/API/2008/01/UserService.svc 
Version2 hosted at http://www.ourdomain.com/API/2008/06/UserService.svc

So IIS hosts our services in a single Web application and this was fine for our Version1 of the service… until we deployed Version2…

Problem

Every time we access one of the endpoints the other one gives an error resembling:

InvalidOperationException: The address "blah" is already registered:

We tried everything:

1. Explicitly specifying the ListenUri for Version1 gives…

A registration already exists for URI ‘http://www.ourdomain.com/API/2008/01/UsersService.svc’.

But only after accessing the Version2 service first, then accessing Version1 crashes, if you access Version1 then Version2 crashes.. ARGGH!!!

2. Explicitly specifying the Address for Version 1 and Version 2… Same thing…

3. Explicitly specifying the Address and ListenUri for Version 1 and Version 2… Same thing again…

I was stumped until I noticed that the web.config had this in it:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> 

"This couldn’t have anything to do with it… surely" I thought to myself… Sure enough, turn this off and viola! The same service can be hosted from two separate endpoints (or addresses) with both endpoints supporting both contracts, and the Config’s needn’t say anything about how to do it. This makes it easy for us to ensure backwards compatibility while making it clear to any developer what the latest version of the service contract is… Huzzah!.

Final Web.config

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
    <services>
        <service name="MyServiceApp.MyServiceClass"
                 behaviorConfiguration="StandardServiceBehavior">
            <endpoint name="SecureEndpoint"
                      binding="basicHttpBinding"
                      bindingConfiguration="AnonymousSecure"
                      bindingName="AnonymousSecure"
                      bindingNamespace="http://www.ourdomain.com/API/2008/01"
                      contract="MyServiceApp.Version1.IUsersService"
                  />
            <endpoint name="SecureEndpointVersion2"
                      binding="basicHttpBinding"
                      bindingConfiguration="AnonymousSecure"
                      bindingName="AnonymousSecure"
                      bindingNamespace="http://www.ourdomain.com/API/2008/06"
                      contract="MyServiceApp.Version2.IUsersService" />
        </service>
    </services>
    <bindings>
        <basicHttpBinding>
            <binding name="AnonymousSecure" maxReceivedMessageSize="10000000">
                <security mode="Transport">
                    <transport clientCredentialType="None" proxyCredentialType="None"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
...
</system.serviceModel>

2 Comments