If you’ve already developed COM APIs with .Net, typically in C# with VBA as the consuming language, you’ve probably leveraged two powerful features:
by-reference parameter passing that allows the API to change the input object itself, not only its content.
This is marked with ref in C#:
void LoadData(ref string data)
optional parameters that allow the caller to omit them when calling into the API:
void SaveData(string data = "DEFAULT")
Sometimes you want to have both for a parameter: the ability to omit it and to change it.
This is something COM supports but unfortunately this is not supported by C#.
Recently one of my customer needed precisely that for a COM API developed in C# migrated from VB6 where it was plug-and-play.
The original developers of the API had done a quick study and concluded that it was not possible with the new C# API and indeed it was not documented at all.
From experience I know that COM is not used a lot today and that resources are scarce, so, to be sure, I’ve done my due diligence and reexamined the issue, digging a little deeper and testing undocumented stuff.
I’ve finally found a solution that I would describe as a “trick”, because it’s not documented, and that I’ll present in detail in this article. Continue reading →
En tant que développeur et formateur WPF depuis plusieurs années les nouvelles orientations de Microsoft pour les plateformes clientes, avec la montée en puissance du tout nouveau WinRT, m’ont quelque peu inquiétées.
Et pour cause : j’ai directement subi l’échec et l’abandon de Silverlight et comme dit le proverbe “chat échaudé craint l’eau froide”.
Depuis 2009 j’ai beaucoup investi, personnellement et professionnellement, dans WPF, l’utilisant pour développer des applications LOB dans le secteur financier, et désormais je dispense même des formations sur le sujet.
Par conséquent le futur de WPF est critique pour moi, c’est pourquoi j’ai étudié cette question de l’avenir de WPF plus en détails, mettant en oeuvre mon expertise sur le sujet et ma récente découverte de WinRT.
Dans cet article je partagerai avec vous les résultats de cette “étude” en toute objectivité et transparence, afin de vous aider en tant que partie prenante dans votre veille technologique.
J’espère que vous fournirez vos propres informations, afin que la communauté toute entière puisse avoir une meilleure vision des perspectives pour WPF.
Dans la dernière partie de l’article je fournis des stratégies pour les entreprises et les développeurs utilisant WPF.
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.
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
Recently I’ve worked with a web API, the Cometdocs API, in order to use their converter of documents, particularly for automating some conversions from PDF documents to Excel spreadsheets for data extraction.
I wanted to use this API from my two favorite development platforms: Java and .Net/C#, so I needed to build what is called a language binding, i.e. a small library that acts as a proxy between the application code and the web API.
The development of these two bindings was really interesting from a technical point of view, and I’ve learned a bunch of things during the process.
I’d like to share the interesting stuff with you, it should be of interest even if you don’t have any plan for interacting with a web API because all the technologies and techniques I’ve used (the HTTP protocol, JSON data binding, SSL/TLS…) are applicable to other types of developments.
Today if you ever need to consume a web API, or produce one, chances are you’ll need to use JSON.
And there is good reasons why JSON has become so prevalent in the web world:
secondly JSON is less verbose than XML (see my other article on the subject) and can be used for most scenarios where XML was historically used
So whatever the language and platform you’ll use you’ll need a strong JSON parsing component.
In the Java world there is at least two good candidates: Gson and Jackson.
In this article I’ll illustrate how to use Gson: I’ll start with a (not so) simple use case that just works, then show how you can handle less standard situations, like naming discrepancies, data represented in a format not handled natively by Gson or types preservation.
Sometimes we need to modify some global state, but when we do that it’s critical to ensure we leave things as we’ve found them; you know like when you lift the toilet seat: forgetting to put it down afterwards could get you in trouble!
It’s similar in programming and you need to use the right tools and practices.
In this article I’ll show you how they can be used to scope global state changes in a fluent manner, a pattern I’ve used for years to enhance reusability and readability of this kind of code.
In the first part I’ll illustrate this pattern with a small and hopefully fun example, and then in the second part I’ll describe how it can be applied to other situations like culture settings and Excel development. Continue reading →