Thursday, May 14, 2009
#
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.
Tuesday, January 27, 2009
#
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
Monday, April 28, 2008
#
I eventually managed to narrow down what was causing all the grief and causing the build times to grow (previous post) and I thought I should update you all. The problem was the folders being created in the c:\Documents and Settings\<buildusername>\Local Settings\Application Data\Microsoft\WebsiteCache folder. After my last post I let my build run for 6 weeks and yet again the build times started to increase and I found I had nearly 60,000 sub-folders in this folder. When my build was taking 1 and 1/2 hours to run, this folder had over 406,000 sub-folders. A scheduled clear down of that folder is now in order.
Sunday, March 02, 2008
#
My build box became one of the many victims to the mysterious "Unrecoverable build error", when trying to build a solution that tried to compile a visual studio setup project. After following the advice at http://support.microsoft.com/kb/329214/EN-US/, didn't work, trying repair on Visual Studio, nope, and finally a full uninstall and install of Visual Studio, nah nah; I was still no better off.
I then realised that I could build the setup projects using visual studio and via the command line but the build account could not. The issue was with the account itself it would seem and not some mysterious code error; other than the unhelpul message. Once I started down this path I noticed that the folder for the account under c:\documents and settings was very big, so much so that when I tried to find out how big my explorer ran at 50% and just didn't stop and started to grow in memory usage (memory leak?). It is then I decided to kill the profile of the account.
Finally after some tweaking I got the build to work by doing the following:
- Stop (and perhaps disable) the Team Build Service.
- Remove the profile for the account of the service from the machine.
- Delete the folder under c:\documents and settings that relates to that account. This was still problamatic with explorer so I ended up moving, renaming it, and deleting files and folder at the command line.
- Remove the workspaces using tf.exe (e.g. tf workspace /delete) from that machine that are owned by that account on that machine.
- Login to the machine using the account and at a cmd prompt try tf workspaces /server:<server> ; initally when I tried to restart the service without doing step 4 and 5 I got other errors, e.g. cannot determine workspace and other errors of similar ilk.
- Restart the Team Build Service and run a new build.
On a much more positive side I noticed that my build time has now reduced from 1 hour 20 min to just under 30 mins; which is strangely what it was a year ago; with all the improvement coming from the part of the build that relies on devenv.exe i.e. BizTalk and Setup Projects. And we all thought the growing build times was due to our increasingly complex code. So it may be that this little clean up needs to be added to my regular clean up schedule.
Sunday, February 10, 2008
#
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).
Saturday, February 09, 2008
#
How does one start a blog going and get that first post on the board? Well after thinking for, oh about 5 mins 2 seconds, I decided to start with a very brief bio of myself. So, after taking a deep breath, here goes...
Been involved with software development for about 25 years, first as a teenager with a spectrum (BASIC and the Z80 Assembly language) and then Fortran (Vax) at university. Later moved on to Pascal, Occam and finally C (on a UNIX in '92); depending on the projects I also flirted with Forth and Prolog. Finally entered the workforce in '94 and started using MFC on , Windows 3.11 on Windows NT. Languished in the Microsoft land as OS's and technologies came and went; until finally stumbled upon .NET in '02. A technology that I have thrown my hat in with. I love working with .NET and I have been lucky to have done one project that involved .NET3.0 (WPF and WCF) (ed. Did I really just write that slush!). I still feel that .NET is missing things; I really missed templates and was so relieved when generics arrived (even if it wasn't everything I wanted from it) and I am excited with the new stuff that has arrived I can't wait 'till I get my hands upon it. Thing is I am now much older, have 2 children and, I am ashamed to say, I am damn tired at the end of a day that I don't want to stare at another computer until the next day. Somehow I manage to stay in-the-game but I suspect that is experience rather than youthful exuberance.
Well now you know where I am coming from let's see where it leads...