BizSquawk

Hunting .NET memory leaks is like playing Whack-A-Mole

swilde — Thu, 14 May 2009 19:34:26 GMT

We have a .NET memory leak in our GUI application and though I have tried a few commercial tools (RedGate and AutomatedQA) I find that there is just too much information and I find that I can't see the wood for the trees. So my tool of use is good old WinDbg and the SOS2 extension.

In the end I narrowed the main leak to a private static collection in a 3rd party library - which required the use of reflection to make it let go. Now to hunt the other ones down...

References (mainly for me actually):
John Robbins - http://msdn.microsoft.com/en-us/magazine/cc163833.aspx
Tess Ferrandez - http://blogs.msdn.com/tess
Prashant Sinha - http://debuggingblog.com/wp/

PS - I'd like to say use Google but there is so much screen scraped rubbish out there I kept coming across the same stuff. over and over again.

Useful BizTalk Tools from codeplex

swilde — Tue, 27 Jan 2009 16:30:22 GMT

Okay this is probably going to be old news for anyone reading this but...

BizTalk Documenter - Document your code
http://www.codeplex.com/BizTalkDocumenter

BizUnit - Test your code
http://www.codeplex.com/bizunit

BizTalk Orchestration Profiler - Useful for code coverage when used with BizUnit
http://www.codeplex.com/BiztalkOrcProfiler

I am doing a lot of refactoring (Unit Test and Profiling a must to check for code breaks) on an inherited BizTalk solution - so far I have replaced 40% (target is 90%) of the orchestrations with simple web services and removed some really complicated maps (a big performance drain) by getting SQL to produce the documents in the correct XML format rather than use a different format and then transforming it. Using the documentation tool to check for unused maps.

As I write this up - I find a better post with even more referenced goodies - http://geekswithblogs.net/benny/archive/2007/06/14/113218.aspx

Cleaning up Past Builds in TFS

swilde — Mon, 11 Feb 2008 00:04:08 GMT

Decided to a bit of spring cleaning on the TFS Continuous Integration box, deleted the code, deleted unused/unwanted drops and defragged the drive. Noticed we have had over 3000 builds in the past 13 months. Which alas was making the Visual Studio view of past builds a bit sluggish. Lamented over the lack of Visual Studio support to manage/delete these builds, and realised that this was going to take a lot of command line calls. Being lazy I looked to the internet but could not find anything that matched my criteria; rolled up my sleeves and knocked out a script similar to the following,

use tfsbuild

select 'tfsbuild delete http://mytfsserver:8080 MYPROJECT '+ BuildNumber + ' /noprompt'
from builds where starttime < dateadd(day, -30, getutcdate())

Ran this on the TFS database, copied the output to a command file and executed it. Job done, well will be when it finishes, which I estimate to be sometime tomorrow morning.

Yes I know it culd have been more elgant and I could have developed a fancy tool but I had a rugby match to watch; in hindsight my time would have been better spent developing the said tool (we won but it was not IMO convincing).