Archive for the ‘.NET Memory Profiler Releases’ Category

.NET Memory Profiler 3.1 Beta Released

Wednesday, December 5th, 2007

After a lot of work with the finishing touches, we finally released the first beta of .NET Memory Profiler 3.1. This release contains several new features, such as Visual Studio 2008 support, improved presentation and navigation of snapshot data, etc. You can read more about this release and download the beta here.

We did find a few last minute problems before releasing the beta, so the release was delayed a bit. Since installing .NET Framework 3.5 caused problems with .NET Memory Profiler 3.0, we had to quickly release a maintenance release of this version (v3.0.142). So now both 3.0 and 3.1 support the latest .NET Framework release. If you’re using .NET Memory Profiler and have installed .NET Framework 3.5, I highly recommend that you download either the latest .NET Memory Profiler release, or the 3.1 beta.

Visual Studio 2008 to be Released before the end of November

Tuesday, November 6th, 2007

Microsoft’s S. Somasegar recently announced that Visual Studio will ship by the end of November.

Since support for Visual Studio 2008 is not included in .NET Memory Profiler 3.0 it has been our intention to release .NET Memory Profiler 3.1 before Visual Studio 2008 was released. Unfortunately, it seems like we probably will not be able to succeed in that ambition. However, we will prepare a beta of .NET Memory Profiler 3.1,which will be released as soon as possible after Visual Studio 2008 RTM is available for download.

.NET Memory Profiler 3.0.141 Released

Sunday, August 19th, 2007

We recently released a maintenance release for .NET Memory Profiler 3.0 - v3.0.141.

It can be downloaded from http://memprofiler.com/download.aspx.

This release contains fixes for several problems, both minor UI fixes and other more serious issues. See the release notes for more information about whats new in this release.

Unrelated to this release, I must say that so far I have not written blog posts nearly as regularly as I planned. I have some topics in mind, so I hope that I will find the time to do some blog writing.

.NET Memory Profiler 3.0.113 Released

Sunday, May 6th, 2007

We recently released a minor maintenance release for .NET Memory Profiler 3.0 - v3.0.113.

It can be downloaded from http://memprofiler.com/download.aspx.

This release only contains a single fix, related to profiling WPF applications under a 64-bit OS. For some reason the dispose tracker caused an error when injecting code in a WPF assembly. And this error only occured when running under a 64-bit OS. Luckily, we had previously written another “code injector” which used another approach for code injection. I believe the implementation of the new “injector” is better, but we never included it, since the old one seemed to work OK (don’t fix it unless it’s broken?), and we wanted to perform some additional testing before replacing. Anyway, now we have replaced it and everything seems to be working OK; even for WPF applications under 64-bit Windows.

.NET Memory Profiler 3.0.108 Released

Friday, April 27th, 2007

We recently released a maintenance release for .NET Memory Profiler 3.0 - v3.0.108.

It can be downloaded from http://memprofiler.com/download.aspx.

This release contains a few minor fixes, for example:

When unloading an unsaved project from the projects explorer the profiler did not prompt you to save the changes. 

There was a timing issue in the profiler that could cause the profiler and the profiled process to get stuck. This happened when identifying root references while collecting a heap snapshot under .NET 1.1. It is normally very unlikely that this should occur; we have only had a single report about this, and yet the problem has probably existed since the first release.

The code that handles side-by-side DLLs in the unmanaged resources tracker contained an error. Fixing this error requires some time, so we have only included a temporary solution in this release. The resource  tracker will only track instances that are created by the firstly loaded DLL. This is probably not a big issue, most resource instances will still be tracked correctly, but it might occur in the GdiPlus DLL when working against Microsoft Office components. We are currently working on a better solution.

For more information see the release notes at http://memprofiler.com/releasenotes.htm.