史蒂文 :: Release 2.0

As of New Year I made a number of resolutions that I will no doubt point out in the months ahead. Normally I say thema nd they make no difference - this year however, i intend to actually follow them through. 2006 will be a good year - i can feel it!

My first resolution was to get som level of fitness again - not that i'm enternally unfit - it's just that when i was younger i played football (soccer) 7 days a week. I played for 4 teams and as such had a busy schedule.

So i've been running now since 2nd January 2006, with the odd day off (not 3rd, 5th, 7th and so on - just maybe 2 days off in that time). At the start i could hardly speak when i got back and that was just to get my running gear on - now i can run at a decent pace (and even pass small children riding their bikes) without killing myself.

I do feel a difference, but one of the best parts is that it gives me time to run and think... about the code i have just written. Yes, the code runs through my head so to speak.

Anyone else got a resolution they're desparate to keep?

This running is challenging, but as my other resolution is to create some software that gets even Google's attention (yes, work in progress), it's maybe not the biggest challenge i have in 2006.
 read 0 comments | 

If you get mutiple instances of Windows Messenger signing in and out on a single machine, then run the following to remove Windows Messenger....

Option Explicit
On Error Resume Next

'Dimension variables
Dim WSHShell, MyBox, p1, q1, rcmd
Dim jobfunc

'Set the Windows Script Host Shell and assign values to variables
Set WSHShell = WScript.CreateObject("WScript.Shell")
p1 = "HKEY_LOCAL_MACHINE\Software\Microsoft\Outlook Express\Hide Messenger"
q1 = 2
rcmd = "RunDll32 advpack.dll,LaunchINFSection %windir%\inf\msmsgs.inf,BLC.Remove"

'Create or change the Hide Messenger value
WSHShell.RegWrite p1, q1

'Run the uninstall command
WshShell.Run(rcmd)
 read 0 comments | 

Due to varying stories over the use of Close() and Dispose() on the various connection objects, readers and so on i have gotten into the habit of calling both when i'm done with an object.

However, i read something during the week and as this morning i started doing some work with the SqlDataReader class, i figured i'd see what was happening and maybe see if i was missing something.I may be the only one, but yes i did find that the result depends on whether you are using a Connection object or a DataReader.

In a connection object, calling Dispose() does close the connection, but also suppresses finalization of the connection mainly because it calls an overridden Dispose() method which releases resources from the connection pool and so doesn't require that the Garbage Collector call finalizer for the object (which is expensive). Note that just calling Close() does not call dispose, but does release the connection from the pool. Hence in just calling close, the object itself will be garbage collected by .Net. There have been some cases where it has been mentioned that not calling dispose caused resource problems when a number of connections were created - connections are expensive, so disposing them is probably a better idea.

code : courtesy of Lutz Roeder's .NET Reflector -

//IL
.method public hidebysig newslot virtual final instance void Dispose() cil managed
{
// Code Size: 14 byte(s)
.maxstack 8
L_0000: ldarg.0
L_0001: ldc.i4.1
L_0002: callvirt instance void System.ComponentModel.Component::Dispose(bool)
L_0007: ldarg.0
L_0008: call void [mscorlib]System.GC::SuppressFinalize(object)
L_000d: ret
}

//C#
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}


In a DataReader, when Close() is called, the object is indeed Closed, but Dispose() is not called. So, this object will live around and wait for the garbage collector to clean it up. If it is a command then with Close() the connection used for this reader is also closed (but not disposed). If it is not a command then the connection remains open and must be closed separately - it is fairly common to see a DataReader returned in a method and the base connection remains open, and will only be closed and disposed by the garbage collector at some point. This can have an obvious impact on resources. Calling Dispose() on the DataReader (that is not using a Command Connection) will just close the datareader, but will not close or release the connection, so the connection has to be closed and disposed of separately.


//IL
.method family hidebysig newslot virtual instance void Dispose(bool disposing) cil managed
{
// Code Size: 10 byte(s)
.maxstack 1
L_0000: ldarg.1
L_0001: brfalse.s L_0009
L_0003: ldarg.0
L_0004: callvirt instance void System.Data.Common.DbDataReader::Close()
L_0009: ret
}



//C#
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
this.Close();
}
}


It is probably best to call Dispose() in this latter case, as Microsoft will potentially extend what is done by Dispose() at somepoint in the future and you could have to re-visit your code (unless it was duplicated in Close()).

In the case of the connection however there seems to be some mixed ideas (too many to point out, just Goolge to find many discussions). Some say Close() and then Dispose() - but others say that the garbage collection may impact performance and so just calling Close() and leaving .Net to manage the GC is a better option.

I'm still figuring it all out, so comments appreciated!
 read 0 comments |