Be Explicit

Two fixes: Rar Decompression bug fixed. Error only occurred on some files Rar Decompression will throw an exception when another volume isn’t found but one is expected. sharpcompress.codeplex.com

New release with a couple fixes.

Someone is actually using it or looking at it.

Previously I discussed a novel new way of implementing INotifyPropertyChanged based on code I saw during a Build session.

As of yesterday, February 29th, the Visual Studio 11 & .NET 4.5 Betas are out, and included in the .NET 4.5 Beta comes a handy new feature, the CallerMemberName attribute. It is one of three new Caller Information attributes that have been added in this .NET Framework release.

It is joined by the CallerFilePath and CallerLineNumber attributes. These attributes tell the compiler to include information about the caller as a parameter when compiling a method call (no runtime logic).

With this new functionality we can code things like logging & tracing routines and INotifyPropertyChanged implementations without having to use string literals, slow reflection code, complex expression tree logic, or code weaving.

Leveraging CallerMemberName, we can now rewrite our previous implementation as the following:

public event PropertyChangedEventHandler PropertyChanged;   private void SetPropertyT>(ref T field, T value, [CallerMemberName] string name = "") { if (!EqualityComparerT>.Default.Equals(field, value)) { field = value; var handler = PropertyChanged; if (handler != null) { handler(this, new PropertyChangedEventArgs(name)); } } }   private int unitsInStock; public int UnitsInStock { get { return unitsInStock; } set { SetProperty(ref unitsInStock, value); } }

Fast, clean, maintainable, and no outside dependencies!

Last, but not least, for those of you who may prefer a more conventional INotifyPropertyChanged approach, the updated .NET 4.5 MSDN documentation page for INotifyPropertyChanged uses the CallerMemberName attribute in it’s implementation example. (-;

Good stuff. The reflection always bothered me.

The Lync client for Apple’s OSX platform was released recently - much to a sigh of relief from most Apple users. While Communicator 2011 was ‘OK’ it was on OCS 2007 R2 experience, not Lync, and so felt like the poor cousin of your fellow Windows Lync users.

Anyways, I ran into a problem. On all of my Mac machines Lync just wouldn’t run - I’d fire it up, sign in, and bang, it would crash. Nothing in the crash logs indicated much. It’s been infuriating. My google skills on this issue were pretty weak - searching for Lync for OSX/Mac didn’t result with any useful posts as the client was so new.

So, with much gritting of teeth I set about trying to track it down. Built up a new OSX Machine in this order:

Lion 10.7.0 -> Worked

Lion 10.7.1 -> Worked

Lion 10.7.2 -> Borked

RIght, easy you think - it’s 10.7.2 right? Oh if only it were that simple. Essentially what I worked out was that if I logged in to a machine that had syncronised Keychains from another machine running 10.7.2 then bang, Lync wouldn’t run.

So, to be clear, this machine running 10.7.0 on new account - just fine. Log in to account with sync’ed Keychain from another machine running 10.7.2 and it didn’t work.

Got closer then….So, after much digging around in the Keychain, I noticed something a bit odd in certificates - namely an ‘Unknown’ certificate:

After checking a clean 10.7.0/10.7.1 account this was not there - it’s only there on 10.7.2 generated accounts. Guess what - delete it, and your Lync client will work just fine.

How infuriating is that?

Reblogging this.

Just remember the point that you’re not cool until you have continuous integration.

It’s interesting that normal .NET is not affected but ASP.NET is since it uses a different hash function than the one available in the framework.

Also, it is interesting how many platforms are affected as well.

Use Compression

You can reduce network bandwidth requirements by employing a compression scheme, such as gzip. Using compression is even more important when using an XML-based format like Atom. You should consider using compression to reduce the network requirements when you use the OData client for Windows Phone, which only supports the Atom XML format.

Implementation

Enable compression at the server, and make sure it is configured for the MIME type of the response from your service (such as application/json or application/atom xml). For more information, see the post on IIS Compression in Windows Azure. To request a compressed response from the web server, set the Accept-Encoding header in the request to the supported compression scheme, such as gzip. Windows Phone does not currently have its own compression library, so you must use a third-party compression library, such as SharpCompress. The OData library for Windows Phone enables you to set the headers to request compression. It also provides an API to access a compressed response stream and return the decompressed response for the library to materialize into objects. For an example of how to use compression with the OData client for Windows Phone, see the article OData Compression with Windows Phone 7.5 (Mango).

The using Windows Phone on Azure page mentions using SharpCompress for the GZipStream. I guess no one else has bothered compiling the GZipStream into Silverlight/Windows Phone 7 :)

Threading was never so easy since .NET 4 with the TPL has been released. I know I am a bit late but there are so many nice things which might still be new to many of us. The IEnumerable interface has become famous with the introduction of LINQ but many of us have not yet realized that IEnumerable<T> and  T[] or List<T> can be exchanged in many cases but there are cases where it is important to fall back to a pure IEnumerable<T> if you want to support lazy evaluation. .NET 4 has for example taken advantage of the lazy nature of IEnumerable<T> with the introduction of Directory.EnumerateFiles which returns immediately until the first file is found. Previously you had only the option to call Directory.GetFiles which does potentially search for a long time and will only return when all matching files have been found. This can make a big difference if you search recursively in a big file tree or a directory with many files. I had up to 40s delays in some applications which did process a large directory. 40s waiting time until you can process the first file is certainly not something you want. I did solve this issue in .NET 3.5 with DirectorySearcherAsync which did work quite well.

I’m needing to remember this to keep responsive UIs.