As a WPF developer for years I was recently concerned by the new direction chosen by Microsoft on its client platforms with the rise of the brand new WinRT framework.
I was concerned for good reasons: I’ve suffered from the collateral damages of the Silverlight failure, and as the proverb says “once bitten, twice shy”.
Since 2009 I have put a huge personal and professional investment in WPF, using it to develop LOB applications in the financial industry, and now I’m even providing training on this topic.
So as a professional developer and trainer the future of WPF is critical for me so I’ve studied this issue more thoroughly.
In this article I’ll share my findings with you, in a completely objective and transparent manner, and I hope you’ll provide your own facts, so that the community can have a better vision of the future of WPF.
In the last part of this article I provide some strategies for businesses and individual developers.
I’ve recently passed the Microsoft 70-483 “Programming in C#” certification which is one of the entry point into the .Net and WinRT developers certification cycles.
To be well prepared I’ve read the two books entirely dedicated to this certification : MCSD Certification Toolkit (Exam 70-483): Programming in C# and Exam Ref 70-483: Programming in C#.
I strongly recommend you read both of them if you intend to pass the certification.
Indeed both have been my main material to prepare for the certification and they have perfectly done the job.
This article is a complete review of MCSD Certification Toolkit (Exam 70-483): Programming in C#.
This is the first book you should read because I think this is the one that will best prepare you to get the certification, but paradoxically the worst from a technical point of view, and you will quickly understand why.
J’ai tout récemment passé et obtenu la certification Microsoft 70-483 “Programming in C#” qui est l’un des points d’entrée des cycles de certification développeur .Net et WinRT.
Pour m’y préparer j’ai notamment lu les 2 livres qui y sont dédiés (en anglais) : MCSD Certification Toolkit (Exam 70-483): Programming in C# et Programming in C#: Exam Ref 70-483 dont je vous conseille vivement la lecture.
Ils ont en effet constitué mon support principal pour la préparation de la certification et ont bien remplis leur office.
I’ve recently wanted to demonstrate the relevance of the .Net ReaderWriterLock[Slim] synchronization primitives.
It’s good to hear from the vendor that it’s better, faster, stronger, but when you can it’s always good to evaluate it yourself; not that I don’t trust vendors, but because I like to have hard numbers, particularly when I assert something that can be critical for my participants’ developments.
So I’ve built a small, simple and I hope relevant benchmark to measure the performance impact of ReaderWriterLock[Slim] compared to the naive and uniform use of a Monitor using the C# lock construct.
I wanted to check these two things:
that the RW locks behave as advertised,
what is the profile of the gain function.
In this article I’ll explain the rationales behind the benchmark, how I’ve implemented it and finally present the results.
First a warning, this is a difficult article which goes really deep inside the .Net machinery so if you don’t get it the first time (or even the second or third time…) don’t worry and come back later.
For a training session I’ve taught at the end of last year I wanted to demonstrate some subtleties of multi-threading, and more specifically some memory visibility issues that should cause a program to hang.
So I developed a small sample that I expected would be showing the issue, but instead of hanging as expected the program completed!
After manipulating the program further I obtained the behavior I wanted, the program was hanging, but it still didn’t explained why it managed to complete with my original version.
I suspected some JITter optimizations, and indeed it was the case, but I needed more information to completely explain this strange behavior.
As often, the StackOverflow platform was of great help; if you’re curious you can have a look at the original SO thread.
In this article I’ll “build” and explain the issue step by step, trying to make it more understandable than the SO thread which is indeed quite dry.
This is a small article about an issue I had recently trying to save some big documents represented as .Net objects in MongoDB using the MongoDB .Net driver.
While saving a “relatively” big document I’ve received the following exception:
System.IO.FileFormatException: Size 32325140 is larger than MaxDocumentSize 16777216.
at MongoDB.Bson.IO.BsonBinaryWriter.BackpatchSize() in c:\projects\mongo-csharp-driver\MongoDB.Bson\IO\BsonBinaryWriter.cs:line 697
at MongoDB.Bson.IO.BsonBinaryWriter.WriteEndArray() in c:\projects\mongo-csharp-driver\MongoDB.Bson\IO\BsonBinaryWriter.cs:line 294
at MongoDB.Bson.Serialization.Serializers.EnumerableSerializerBase`1.Serialize(BsonWriter bsonWriter, Type nominalType, Object value, IBsonSerializationOptions options) in c:\projects\mongo-csharp-driver\MongoDB.Bson\Serialization\Serializers\EnumerableSerializerBase.cs:line 408
at MongoDB.Bson.Serialization.BsonClassMapSerializer.SerializeMember(BsonWriter bsonWriter, Object obj, BsonMemberMap memberMap) in c:\projects\mongo-csharp-driver\MongoDB.Bson\Serialization\Serializers\BsonClassMapSerializer.cs:line 684
at MongoDB.Bson.Serialization.BsonClassMapSerializer.Serialize(BsonWriter bsonWriter, Type nominalType, Object value, IBsonSerializationOptions options) in c:\projects\mongo-csharp-driver\MongoDB.Bson\Serialization\Serializers\BsonClassMapSerializer.cs:line 432
at MongoDB.Driver.Internal.MongoInsertMessage.AddDocument(BsonBuffer buffer, Type nominalType, Object document) in c:\projects\mongo-csharp-driver\MongoDB.Driver\Communication\Messages\MongoInsertMessage.cs:line 53
at MongoDB.Driver.Operations.InsertOperation.Execute(MongoConnection connection) in c:\projects\mongo-csharp-driver\MongoDB.Driver\Operations\InsertOperation.cs:line 97
at MongoDB.Driver.MongoCollection.InsertBatch(Type nominalType, IEnumerable documents, MongoInsertOptions options) in c:\projects\mongo-csharp-driver\MongoDB.Driver\MongoCollection.cs:line 1149
at MongoDB.Driver.MongoCollection.Insert(Type nominalType, Object document, MongoInsertOptions options) in c:\projects\mongo-csharp-driver\MongoDB.Driver\MongoCollection.cs:line 1004
at MongoDB.Driver.MongoCollection.Save(Type nominalType, Object document, MongoInsertOptions options) in c:\projects\mongo-csharp-driver\MongoDB.Driver\MongoCollection.cs:line 1426
Well the message is clear: seems like I’ve exceeded the MongoDB max document size threshold which is 16MB, fair enough this is quite a sane design decision.
First I’ll explain why I had this issue, then how I’ve solved it.
As you may know event handlers are a common source of memory leaks caused by the persistence of objects that are not used anymore, and you may think should have been collected, but are not, and for good reason.
In this (hopefully) short article, I’ll present the issue with event handlers in the context of the .Net framework, then I’ll show you how you can implement the standard solution to this issue, the weak event pattern, in two ways, either using:
the “legacy” (well, before .Net 4.5, so not that old) approach which is quite cumbersome to implement
the new approach provided by the .Net 4.5 framework which is as simple as it can be