Andreas Zenker

a boy named goo

April 2009 - Posts

Calling a web service from behind a proxy

Once again I need to call out to an external web service from behind a proxy. Last time it was installing WATIR. This time it is just straight up .NET code, but somehow this configuration feels like something I have to learn over each time I see it, so I am going to burn it into my blog.

I am working through some hands on labs configuring the Unity Inversion Of Control Container. The labs come with a sample Stocks Ticker application which calls out to an external web service to get its updates. So when running behind a proxy that requires authentication, by default, what you will see when running this application is:

stockTickerNoProxy

So I open up the MoneyCentralStockQuoteService.vb file, which defines the class that is calling the service, and find this constructor:

Public Sub New(ByVal implementation As MoneyCentralRemote) 
     Me.implementation = implementation 
     Me.Logger = New NullLogger 
End Sub 

My first attempt to resolve the issue is this, setting up a manual proxy reference (an instance of WebProxy), which requires that I not only tell the proxy to use the default credentials but also provide the ISA server’s address.

Public Sub New(ByVal implementation As MoneyCentralRemote)
        Me.implementation = implementation

        'wire up proxy information here 
        Dim proxy As New Net.WebProxy("http://servername:8080")
        proxy.UseDefaultCredentials = True
        Me.implementation.Proxy = proxy

        Me.Logger = New NullLogger
End Sub

This works and I can start working with the sample application:

stockTickerProxy

However, hard-coding the server name seems less than terrific. I then remember that I can also configure the proxy settings in the app.config file like below, which also works.

<system.net> 
    <defaultProxy useDefaultCredentials="true" /> 
</system.net> 

What this approach reminds me of is that I shouldn’t have to hard-code my proxy server address. If the application can load up the correct default proxy information based on a config file setting it should be able to do so in code as well. There must be a way to wire into this default functionality in code. So, back to the syntax drawing board ... and I end up with this, somewhat cleaner option, that gets a reference to the default WebProxy by way of the WebRequest class:

Public Sub New(ByVal implementation As MoneyCentralRemote) 
     Me.implementation = implementation 
     'set up proxy information here 
     implementation.Proxy = System.Net.WebRequest.DefaultWebProxy 
     implementation.Proxy.Credentials = Net.CredentialCache.DefaultCredentials 
     Me.Logger = New NullLogger 
End Sub 

Of the three approaches, I strongly favor setting up the proxy settings in the configuration file, as it is specific to the environment. Are there any options that I missed?

 
 

© Copyright 2009 - Andreas Zenker

 

 

 
 
Posted: Apr 27 2009, 08:55 PM by azenker | with no comments
Filed under: , , ,
The CMD crisis

I really like being familiar with command line tools, however, in reality I often find myself searching on line for some command I know I used before but just can't seem to remember. In a past life (read "job") I was able to turn around and ask a fellow lead dev who seemed to have The Hitchhiker's Guide to the Galaxy and Window's command line syntax burned into his psyche in no particular order of precedence. We called him "Inspector Gadget" because, when you were looking for the odd utility, tool or command, he was your man. Alas, today I had to resort to Google (MS employees here read "Live Search") Here are a few reminders I needed today and some new stuff I learned. Hopefully I'll remember to look here next time.

Ping - Pretty basic stuff

What I did learn, though, is that you can alter the timeout wait period using the -w [milliseconds to wait] flag.

So, if you think that a longer timeout may help diagnose a slow connection you can stretch the wait to 10 seconds like so:
Ping 1.1.1.1 -w 10000

Tracert - up just a notch from ping

I am not a network guy by any means, but if I see slow times between two servers I want to see what lies between.

You can set the same -w flag on tracert that you can on ping and lengthen the timeout if you think that may alter your results

You can also limit the number of hops with the -h flag. With a lengthened timeout, say 10 seconds, and the default 30 hops, you won't be going anywhere for a while if the trace is timing out. So to lengthen the timeout but limit the hops to 10:

tracert 1.1.1.1 -w 10000 -h 10

Printing out the results

I remembered the ">" flag to direct output to a text file like so:

Ping >mylog.txt 1.1.1.1

What I learned that was new (to me) was that I could also append to an existing file with the ">>" flag to build up a running diagnostics log as I went. So to add a tracert to the ping results I could execute this command.

tracert >>mylog.txt 1.1.1.1

Some good command line syntax references

http://commandwindows.com/command1.htm

http://www.ss64.com/nt/

 

© Copyright 2009 - Andreas Zenker

Posted: Apr 16 2009, 10:22 PM by azenker | with 2 comment(s)
Filed under: , ,
Naming UI control variables

 

Discussed variable naming conventions with a fellow developer yesterday, particularly variables that are instances of UI control (e.g. textbox, label, button) Now, the new direction away from Hungarian Notation and toward longer, more readable and, therefore, more meaningful and maintainable field names would seem to spell the end of some old friends such as:  cmdSubmit, btnRun and lblMaxAge.

So, when thinking about naming conventions moving forward here are the three options I argue back and forth with myself, with varying results….

1 - Follow the new "readable" naming conventions (this is the one I settle on most often)

    Combine the purpose of the control with the control type in one readable name. 
    e.g. SubmitButton, AgeText, AgeLabel etc
    This approach, while my favorite from a straight-up conventions point of view, does have one side-effect that may not be desirable. In the VS IDE your drop down of all the controls on the form will no longer be ordered by control type as it may have been in the old days of yore (Hungarian notation)
      clip_image002[5]

       

    2 - Use the old style on controls as an "exception" to the new rule to preserve IDE experience

      One reason I see mentioned to use Hungarian notation still for controls is, in fact, is to have them sorted by control type in the IDE drop down. This can be helpful if you  have a large form with many controls and forgot what you named something.

      image

    3 - Opt for readable names but reverse the order of the words to favor IDE discovery.

      A blend of the two previous suggestions results in this option. Preserve the readability of the full words naming convention but reverse the order. Somewhat less readable but now sorted by control type in the IDE.

      e.g. ButtonSubmit, TextAge, LabelAge etc.

      image

    So, which would you choose?

     

    © Copyright 2009 - Andreas Zenker

    More Posts