ThinkGeo.com    |     Documentation    |     Premium Support

BingMaps & Google Maps WebProxy

#1

Hi,



It looks like we need to use the BingMapsLayer.Proxy property so that it works properly  in some of our client networks (Same for GoogleMapsLayer as well).   However, this property uses the WebProxy concrete class, not the interface.   This is an issue as the reccomended way of doing this is to use something like HttpWebRequest.DefaultWebProxy or WebRequest.DefaultWebProxy, both of which return IWebProxy (not WebProxy).   I’ve had a look, and IWebProxy has been supported since .Net2 so changing this shouldn’t cause any issues.

Is it possible to change this for your next (major or minor) release?



Thanks,

Steve




#2

Hi Steve, 
  
 Thanks for your suggestion, Changing the WebProxy class to Interface IWebProxy seems more reasonable, but there might be another reasons why we chose the WebProxy rather than IWebProxy. Besides, the change also will bring many changes in our product lines. 
  
 But we still can switch to the other proxy by registering the SendingWebRequest event of the BingMapsLayer: 
  
  
BingMapsLayer binglayer = new BingMapsLayer("KEY");
            binglayer.SendingWebRequest += new System.EventHandler<SendingWebRequestEventArgs>(binglayer_SendingWebRequest);

void binglayer_SendingWebRequest(object sender, SendingWebRequestEventArgs e)
        {
            e.WebRequest.Proxy = HttpWebRequest.DefaultWebProxy;// or WebRequest.DefaultWebProxy
        }
 
  
 I test the way and it also works fine. 
 Hope it helps and thanks for your suggestion. 
  
 Regards, 
 Troy

#3

Hi Johnny,

The issue with doing that is those older properties are deprecated now.   The ones that return IWebProxy are the ones that are reccomended as of .Net2.0.   Also note that the deprecated properties are not available with WinRT at the moment.   I would imagine at some point they will be removed from the main version of .NET



I know that I _can_ use those deprecated properties. (its just that I _shouldnt_).   I understand this may not be a trivial change, but one, I feel, that should be (eventually) made.



Thanks,

Steve

#4

Hi Steve, 
  
 I might be incorrect, but I checked the WebProxy class in MSDN and didn’t find it was marked as deprecated except its GetDefaultProxy method. msdn.microsoft.com/en-us/library/system.net.webproxy(v=vs.110).aspx 
  
 Actually, if we don’t assign an instance for the WebProxy, then the Bing/GoogleFeatureLayer would never use the proxy for the request as the Proxy will always empty in the WebRequest. Therefore, I don’t think we will encounter the deprecated issues except we use the WebProxy.GetDefaultProxy() method to get WebProxy instance. 
  
 But I am agree with you and so I posted this enhancement into our Gimini issue system and I believe our development team will take it into consideration in the next release. 
  
 Regards, 
 Troy 
  
  


#5

Hi Johnny,

Thanks for looking into this.

Thanks,

Steve

#6

Steve, 
  
 You are so welcome. If any other queries, don’t hesitate to let us know. 
  
 Regards, 
 Johnny

#7

Hello Johnny, is there any update on this topic? We also face with the same problem.

#8

Hi Piotr,

It looks our development team hadn’t modify the class type.

Do you think the solution mentioned by Johnny before is helpful for your issue?

Regards,

Don