When you’re working on a .NET application and you need to call into a platform specific COM Assembly there are a few issues in play that can be a bit confusing. In my own exploration I found a lot of different articles that were helpful/interesting to varying degrees (if a bit incomplete WRT my scenario and conflicting in a few cases), so I figured I would post my own notes.
The important thing to remember is that native code is always specific to a given platform, while managed code can either be specific to a platform or it can be set to ILONLY which allows JIT to compile to either architecture. If you want your app to be platform independent and you have both 32 and 64 bit flavors of the native COM Assembly you can register both versions and create a COM Interop assembly that isn’t platform specific and the Interop assembly will pick the correct COM object.
The following steps illustrate how to create a runtime callable wrapper for a COM assembly and reference it from your project (or you can just reference the COM assembly directly in Visual Studio and it will do essentially the same thing under the hood):
1. Use tlbimp.exe to create a RCW:
tlbim.exe foo.dll /out:Interop.Foo.dll
2. Register the COM assembly (not the RCW) if you haven’t already:
3. Reference the RCW (eg. Interop.Foo.dll) from your application.
If you’re using Visual Studio, writing XML comments, and aren’t using GhostDoc then you’re wasting time. It’s one of the handful of tools that I install alongside VS first thing on any clean install. Just wrote a new method to solve world hunger? Ctrl + Shift + C and GhostDoc will take a stab at filling in the comments for you. The hit ratio isn’t perfect, but it’s always faster to tweak the results and fill in blanks than starting from scratch in my experience and another side effect is that it encourages you to give a bit more thought/consistency to method/variable names.
As part of a recent reorg my team on Microsoft Bing moved under the Engineering Fundamentals team to play a role in the effort to streamline the Bing engineering process. While planning for our next major release I’ve been doing a bit of research on how other companies in the online service world handle common challenges around things like branch management and integration, deployment tasks, and mitigating live site incidents. I stumbled upon this gem from the engineers who do deployment at Facebook and found a lot of the content fairly interesting… for starters the fact that 3 engineers handle deployment for the entire company.
A few other points that struck me as interesting:
1. Developers checkin to a single trunk branch
2. Code goes to prod daily, the entire branch goes weekly
3. New features are deployed to prod and then dialed up via a gatekeeper
4. Karma is tracked for developers based on history
5. Modified BitTorrent helps speed up prod deployment
6. Features have to be 100% backwards compatible
Many of these jive with the way we do development at Bing, but one big departure is the single branch model (versus the 100+ branches that our 1k+ developers check in to today). I’m slowly but surely being won over by the idea of a “trunk only” model to save the overhead involved with branch integrates and coordinating getting things from one branch to another.