Automatic proxy configuration in .NET Framework 2.0

PROBLEM DESCRIPTION
===================
The outcome of the execution of PAC file seems to change when called from IE or from a .Net 2.0 client. The internal URL we want to call is http://webapps.custname.com and the IP address of the web apps server is 141.122.180.192.

For example, here is a sample PAC file

function FindProxyForURL(url, host) 
{ 
    if (isInNet(host, "141.122.0.0", "255.255.0.0")) 
    { 
        return "DIRECT" 
    } 
    else 
    { 
        return "PROXY 169.12.232.25:8080" 
    } 
}

When called from IE, the internal url http://webapps.custname.com is directly connected to the web server without using a proxy. So the PAC file returns “DIRECT”.

When called from a .Net 2.0 application, the same url (http://webapps.custname.com) is redirected to the internal proxy 169.12.232.25:8080. If he uses the IP address of the web Server ( http://141.122.180.192 ), the isInNet function seems to work as the request is not redirected to the proxy anymore.

I used the code below to test the differences between .Net 1.1, .Net 2.0 and IE (taken from http://msdn.microsoft.com/msdnmag/issues/05/08/AutomaticProxyDetection/default.aspx ).

using System; 
using System.Net; 

public class Test 
{ 
    public static void Main(string[] args)     { 
    IWebProxy iwp11 = GlobalProxySelection.Select; 
    
    Console.WriteLine(iwp11.GetProxy(new Uri(args[0])).ToString()); 
    
    //comment the following 2 lines when compiling on 1.1 
    IWebProxy iwp20 = WebRequest.DefaultWebProxy; 
    Console.WriteLine(iwp20.GetProxy(new Uri(args[0])).ToString()); 
}  

SUMMARY of TROUBLESHOOTING
==========================
This behavior is by design in .NET2.0 because with the introduction of IPv6, isInNet needs to be more specific on what to compare. Therefore, IP address needs to be specified in isInNet if the PAC is to be used in .NET Framework 2.0.

I read a draft (MSOnly) version of the KB article which will address this same issue (but I don’t know when it will be published); in the meantime…

UPDATE:
The KB article has been published: http://support.microsoft.com/default.aspx?scid=kb;EN-US;922778

Cheers
Carlo