redgate‘s decision to start charging for their Reflector .NET decompiler sent ripples through the .NET development community. Personally, while I do not think that the 25-69 EUR price is outrageous, I must agree with many people – redgate promised to keep Reflector free after the acquisition.
But, whatever happens, happens for the best. New decompilers started appearing like mushrooms after the rain, and JetBrains, the famous maker of e.g. ReSharper and TeamCity, came with its own free dotPeek decompiler, which is in the EAP or Early Access Program stage now. Knowing and using JetBrains’ products, I believe that dotPeek has all chances to become the de-facto standard for a .NET decompiler eventually, so I will keep an eye on it.
I had a problem debugging my solution consisting of C#, C++/CLI, and native C++ projects. I was not able to get breakpoints working in the native C++ parts – after running the solution with breakpoints set, they were turning gray with warning sign, and their tooltip stated that “The breakpoint will not currently be hit. No symbols have been loaded for this document.” despite all debug properties were set right on those projects and all debugging symbols existed. After fighting it for a few hours and almost giving up, I started to think that the problem might not be with the native C++ projects, but rather somewhere else, e.g. in the StartUp project, which is C#. Checked that project’s properties, and guess what! Debug > Enable unmanged code debugging option was off!!! Switched it on, and voila – breakpoints work fine in native C++ DLL now!!! :)
I did not actively search for the subject, but once I bumped into a three-part article about the MSBuild script debugging (Part I, Part II, Part III) on The Visual Studio Blog I immediately though that it is worth remembering about it when (I am not saying if, but rather when here) I need it in the future. The blog itself is also worth checking, as there is much information about VS IDE, MSBuild, and extensibility from the Visual Studio development team.
DebuggerVisualizers – Boost C++ Libraries has nice introduction to custom Visual Studio debugger visualizers.
memcpy() Is Going to Be Banned article at InfoQ talks about dangers of memcpy (and other memory/string related functions). Microsoft has more in-depth explanations as well as the list of Security Development Lifecycle (SDL) Banned Function Calls at MSDN. Also available from Microsoft is banned.h header file that, once included, will produce warnings for all the banned functions. Alternatively one can use the /W4-C4996 compiler option.
How to Debug Crashes and Hangs article by Kirill Osenkov [MSFT] summarizes useful things about debugging in Visual Studio.
Schitech .NET Memory Profiler has plenty of features that will make your life easier when you try to fight memory-related problems in your .NET applications. Nice touch – it is able to track unmanaged resource usage (e.g. HWND, HBITMAP and unmanaged memory) and present it together with the .NET memory information. Just this single feature alone saved my day when I had to find unmanaged memory leak in the mixed-mode .NET app (C# and C++), and all other profilers just $@% badly – I had the bug fixed in less than one hour after I downloaded the trial version of the tool (that 1 our included “learning curve” as well!!!). Recommend!