I have to agree with John. Since the calls to the server are being made
by the ChartFx controls, and you say these request are not seeing your
client configuration for proxy servers, then it is very likely that there
is no code you can add to your own application to make this work. The
exception case, and I would anticipate there to be this case, would be a
property on the chartFx controls that you can set from your client-side
load code to use a proxy.
Is there some reason that your clients need to use a proxy for internal
addresses? very often proxy settings bypass the proxy for local IP
addresses. I suppose that in some environments, the business wants to be
able to monitor every page every user goes to. <brrrrrr>
Dan Rogers
Microsoft Corporation
--------------------
From: "Codex Twin" <co***@more.com>
References: <eE**************@TK2MSFTNGP14.phx.gbl>
<OW**************@TK2MSFTNGP09.phx.gbl>
<Om**************@TK2MSFTNGP14.phx.gbl>
<Od**************@TK2MSFTNGP10.phx.gbl>
Subject: Re: Rerouting Requests via a Proxy because of .NET "bug"
Date: Fri, 3 Dec 2004 17:54:22 -0000
Lines: 60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Message-ID: <up**************@TK2MSFTNGP11.phx.gbl>
Newsgroups:
microsoft.public.dotnet.framework.aspnet,microsoft .public.dotnet.framework.w
ebservices
NNTP-Posting-Host: 193.115.152.15
Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP11
phx.gbl
Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.webservices:7804
microsoft.public.dotnet.framework.aspnet:280780
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices
"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Od****************@TK2MSFTNGP10.phx.gbl...
"Codex Twin" <co***@more.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
... John
The scenario is this: The server application I have built uses the
ChartFX (by SoftwareFX) control. This control causes the download of half a
dozen or
so "client-side components". These are nothing more than .NET assemblies
which allow all the fancy dynamic chart customisation tools on the
browser.
One of the conditions for the client-side dlls to work is that the
client machine has to have the .NET framework installed.
These same machines, being behind the firewall, uses the automatic proxy
discovery script to determine the proxy server settings.
Now, because of the problem detailed in the first article
(http://support.microsoft.com/default...5BLN%5D;307220) and
the
fact that the .NET Framework does not support proxy discovery scripts,
the client machine cannot see get the proxy server settings and the charts
fail.
Please be more specific. Exactly what do you mean when you say "the charts
fail"?
When the machine.config file is amended as the article explains, then it
works. I do not have access to their machine.config files, hence the
programmatic way of supplying proxy server settings as detailed in the
second article, which as you have rightly said, only deals with Web
Services.
My problem has been where to impose this programmatic code, and what the
correct code is.
Whatever the solution is, it will be client-side.
Have you spoken to SoftwareFX about this? You may not be the first to have
this problem.
John Saunders
SoftwareFX have not responded (yet).
I'm halfway there, but have not been able to simulate a Request from a
ChartFX client object. So not there at all, I guess.
Thank you and have a nice weekend...