PrimordialCode

Many email readers (like Windows Mail, Outlook, Thunderbird...) use this format to store emails in files; I needed an easy way to create those files to send emails using the default email program the client has configured on his system.

Looking the the framework class documentation I’ve found that the SmtpClient class, specifying its DeliveryMethod to SmtpDeliveryMethod.SpecifiedPickupDirectory and PickupDirectoryLocation to the destination folder you want the files to be placed, can generate those files for you, without the need of any external library.

The code was quite straightforward:

/// <summary>

These days I made myself and my bro a ‘Christmas Gift’ and I bought a couple of 10k rpm hard drives to give our systems some speed up. In my childlike mind I thought: migrate the system will be easy..just clone the HD data to the new one, maybe perform a quick system repair to adjust and driver assignment letter issue that can arise and we are cool.

Well...it was a long journey to figure out how to resolve all the problems we had, today we start with the Windows XP migration, in a next article I’ll talk about the Vista migration.

To successfully migrate a Windows XP installation you need 3 different tools, I tend to use all free stuff if I can:

• A disk cloning tool: EASEUS has a nice and free solution that worked well for me: EASEUS DISK COPY
• A partition manager tool: again EASEUS to the rescue with the free version of EASEUS Partition Master Personal Edition 
• To fix the boot issues that will arise you need to use the Partition Saving suite (in the download section look for the ‘spartiso.zip’ file).

Here are the steps I made:

1. Burn the Disk Copy and Partition Savings in two bootable CDs.
2. Connect the new HD to the system and start Windows from your old IDE drive, this step is needed to let the system load the SATA drivers if required.
3. Boot the Disk Copy tool and perform an copy of the Windows partition to the new drive (it will have the same size of the original one, that’s why you need a partition manager tool after)
4. When finished, just to be safe, remove/disconnect your previous HD and try to boot from the new HD.
5. If it all work you can go to step 14.
   Here’s when my problems arose, instead of seeing the windows logo and the operating system the screen was totally black with the prompt flashing on the upper left corner.
6. Boot from the Partition Savings CD and type ‘savepart’ at the prompt to start the utility
7. Choose "update windows2000/xp/vista registry"
8. Click on the partition that has your system ( “C” usually ) and take note of the drive letter this is your mounted device drive letter.
9. You will now see a list of directories, choose the "WINDOWS" directory
10. On next screen you choose the disk which has the partition whose registry definition you want to update
11. You choose the partition for which you want to update the definition in the registry
12. The last box is the "drive letter to affect this partition" box. You must choose from this list the drive letter you want to be associated with the partition selected with two previous windows. This is where it will show you the "partition ID drive letter" it should be the same as the "mounted device drive letter".
    [extensive documentation can be found in the Partition Saving help files]
13. Reboot the system, it should start without problems and load windows, but your partition will have the same size as the original drive.
14. Install the partition manager tool and resize your partition to take advantage of your new HD.

Enjoy your migrated system :D

Related Content

• Windows SharePoint Services - first setup (26/08/2015)
• Redmine: a trick to import data from Mantis (26/08/2015)
• Build: Windows 8 (26/08/2015)
• Install SQL Server (Express) with your Application (26/08/2015)
• Winforms: improving rendering performances with BackgroundImage and BackgroundImageLayout (26/08/2015)
• More related document (8)

In the past few days I was moved to analyze some legacy code from a huge web application written by a company I work with. I have to write some new modules to integrate in this application; but while I was reviewing the code to ‘learn’ the style and code format used (to try to build code similar to the one already written for uniformity and ease of maintenance for the other guys I work with), I faced code like this:

...

These days I’m working on a custom application updater for our products and I had the need to Close the main Application process from the Updater process. My first implementation involved getting the main application process ID and then use something like:

...

processToWait = Process.GetProcessById(pid)

mProcessToWait.CloseMainWindow()

mProcessToWait.WaitForExit()

mProcessToWait.Close()

...

...

Const WM_SYSCOMMAND As Int32 = &H112

Const SC_CLOSE As Int32 = &HF060I

Declare Function PostMessage Lib "user32.dll" Alias "PostMessageA" ( _

  ByVal hwnd As Int32, _

  ByVal wMsg As Int32, _

  ByVal wParam As Int32, _

  ByVal lParam As Int32) As Int32

...

Dim handle As IntPtr = mProcessToWait.MainWindowHandle

PostMessage(handle.ToInt32, WM_SYSCOMMAND, SC_CLOSE, 0)

mProcessToWait.WaitForExit()

mProcessToWait.Close()

Recently, together with Diego Guidi, Alfredo Morresi and Gian Maria Ricci, I was the speaker in the 11th workshop presented by our .net user group DotNetMarche.

We talked about solution refactoring presenting some guidelines and why/how you should do refactoring (Alfredo Morresi); then we had a session in which we presented some advances features of Resharper, one of the tool we use to help us during the refactoring activities (Diego Guidi).

The 3rd session (held by the proud owner of this blog :)) was about refactoring ASP.NET pages and controls, showing how you can refactor a completely non structured and fully hardcoded solution to reach an MVC approach, while improving the general performances of the pages/controls at the same time.

The last session (Gian Maria Ricci) was devoted to ASP.NET pages refactoring, showing you how the refactoring activity of a page or control in different components can facilitate the testing of each piece of the application.

If you are interested, the material of the workshop is available following this link: http://dotnetmarche.org/files/folders/11_-_refactoring_2themax_09102009/default.aspx

I’m not a Castle Windsor expert and I started using it heavily some months ago. These days I’m profiling some of the applications I wrote in the past to try to optimize the memory usage and reduce the footprint they allocate.

Using some profiling tools I came across one of the most frequent (and biggest) mistakes you can do while using Castle Windsor with Transient objects: I always forget to call the Release() function from the container from which I requested the object.

This simply happened because Castle do not handle transient DISPOSABLE objects the way I was thinking. In my mind a ‘Transient’ object is (was) something I require from the container and then I have FULL CONTROL over its life, the container (or the factory) should completely forget of the object itself.

Well...it isn’t like that, the default behavior that Castle implements is to keep track of any DISPOSABLE object he creates to deallocate them in the right way when the container itself is disposed.

There are a number of good reasons for this to happen, and it actually is a quite long discussion; you can find some info in these posts:

http://elegantcode.com/2008/12/14/the-component-burden/

http://hammett.castleproject.org/?p=252

some other posts from my friend Alkampfer gives you some more info on the same mistake I made:

http://www.nablasoft.com/Alkampfer/?p=104

http://www.nablasoft.com/Alkampfer/?p=105

http://www.nablasoft.com/alkampfer/index.php/2008/02/29/again-on-castle-transient-and-the-custom-lifecycle/

If, like me, you used some static IoC container that lived along the whole life of the application you can see the huge impact this behavior has on the memory allocated by the application: since the container keeps a reference to any disposable object (even the transient ones) you allocated, they will never be released during a GC action.

So...how to modify the default Castle behavior to match my view? The goal is simple: we want to keep the actual object tracking for all the objects lifestyle types (singleton, pooled, etc...), but we do not want to track transient object; in this way the CLR is able to reclaim the memory they use during a GC call.

It all seemed hard to obtain until I found out that Castle have configurable Release Policies that actually handle the object tracking, here you can find some ‘small’ documentation on the default policies that come with castle: http://www.castleproject.org/container/documentation/trunk/advanced/releasepolicy.html. LifecycledComponentsReleasePolicy is actually the default one.

At first my solution was to implement a new policy that modified the tracking behavior for transient objects:

/// <summary>