In c# what the hell is the difference between const and readonly? I looked this up today and:
Here’s what I found.
- 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.
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).
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.
I’ve created and uploaded some sample code for using Linkedin’s oauth library in a c# desktop app. Faith Yasar’s c# code was my starting point. A bit of a refactor of the oAuth librarie to include the oauth_callback parameter was needed, as well as code for displaying the login dialog.
Code can be found here in a forum post I made on linkedin.
The code contained includes a test harness as well as the oauth libraries for oauth login dance and Linkein API requests. Oauth login is handled with an embedded webBrowser which is shown modally for the user to login. Upon login completion, dialog will be closed and the token and verifier will be available from the dialogs property.
To use the code, simply Add your Linkedin consumer secret and Consumer key to the OauthLinkedIn.cs file:
private string _consumerKey = "ENTER_YOUR_CONSUMER_KEY";
private string _consumerSecret = "ENTER_YOUR_CONSUMER_SCRET";
Then you can make api calls following a few steps:
OAuthLinkedIn _oauth = new OAuthLinkedIn();
String requestToken = _oauth.getRequestToken();
String accessToken = _oauth.getAccessToken();</div>
Hope that helps