Month: January 2010

const vs. readonly in C#

In c# what the hell is the difference between const and readonly?  I looked this up today and:

Here’s what I found.

Constants (const):

  • Are slightly less expensive to evealuate
  • Are static by default
  • Can be declared inside functions
  • Have gotta have compile time value
  • Are set at compile time inside assemblies that use them

Readonly (readonly) instance fields:

  • Must have set value by the time constructor exits
  • Are evaluated when instance is created

So I tend to use readonly fields if I ever think the constant will be referenced outside of my assembly.  Otherwise I’ll take the microsecond and use a const.

C# WebBrowser swallows redirect uri

Using an embedded C# WebBrowser, we developed a Linkedin Oauth login library which would allow a user to receive an oauth access token.  We set the callback uri to something specific to our app – “myapp://success”  Within the WebBrowser_Navigating event, we’d look at the uri.  If it included “myapp://success” we were able to extract the access token from the query params.  However, this technique breaks down in a few scenarios:

1.  Using a Winform browser, the redirected uri was never sent as event arguments if the URI wasn’t http://, or mailto or other special cases.  This meant that we had to use a WPF browser which requires a bunch of overhead libraries to be loaded when all we really need is a winform.

2.  Previous versions of Internet explorer do not honor  passing the redirected uri to the WebBrowser control if the uri doesn’t actually exist.  So in other words, because the system didn’t know how to handle linkedin:// uri’s the browser would never redirect to that uri.

To solve the problem I tried to register a NOP callback in the registry to handle this URI scheme:

Register a NOP command line for the liconnect scheme in the registry as a URL scheme (i.e. a command line program that does nothing).

http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.createsink.aspx

The webbrowser still didn’t honor passing the URI scheme to the navigating or even the navigated event.  The URI being navigated to must actually exist for the Webbrowser to actually pass it to the event.

So, to solve it:

We set the callback URI to a URI that we own.  ie.  “http://mydomain.com”

This way, we’re able to intercept the callback when we see this uri in the navigated event.  I’m not thrilled with this solution since it relies on a server.  You could just as easily redirect to http://linkedin.com or some other known domain, but it still leaves your client code dependent on a server.

I’ve uploaded the most recent code to the original linkedin thread.

“shhhh don’t tell anyone; it’s a winning idea”

I was out for drinks a couple nights ago with a friend who had a “winning idea” that he wouldn’t share with anyone in the room.  I can only imagine that he feared someone scooping his idea.

Much like that evening, whenever I see someone guarding their idea like it was their first born, I can’t help but think they’re going to spill the beans within minutes.  Of course though, they’ll make you swear until you’re blue in the face that you won’t tell a living soul.

In my mind, this person, or anyone who has a “winning idea” has failed already. Ive met enough “ideas people” to know that ideas are worthless; the value lies in the execution of the idea.  So if there’s anything you should fortify, it’s the execution of the idea, not the idea itself.  Better a mediocre idea brilliantly executed than a brilliant idea with a mediocre execution.