Living .NET... : .NET 2.0

Implementing Timeout & Retry

Manoj G — Wed, 01 Nov 2006 11:58:00 GMT

I have come across several situations where I need some sort of Timeout functionality for a particular operation. At the same time, I also needed a provision for retrying the operation a few times before calling quits. I thought about a solution using...(read more)

Predicates in Action

Manoj G — Tue, 29 Aug 2006 07:12:00 GMT

Get to know about one of the cool new things in .NET 2.0 - Predicates!...(read more)

Tip: Debugging Windows Services

Manoj G — Mon, 03 Apr 2006 18:25:00 GMT

The other day, I was watching the PDC presentations on WCF and one of them was on hosting WCF services by Steve Maine. Part of the presentation was about hosting Indigo on Windows services (or NT Services). One of the demos had a small and very interesting tip on debugging service startup, which I shall try to elaborate here.

I always wondered how the service startup code could be debugged. There are two problems which you would face invariably. First of all, there is no process to which you can attach a debugger to start with. I have done stupid things in the past to step into startup code - by adding a Thread.Sleep in the OnStart method, assuming that this would give me enough time to attach the debugger to the newly started process. This isn’t very smart as you would hit the second problem – the Service Controller Manager (SCM) would time the service out way too soon. Not to worry much - there is any elegant solution to both these problems.

You need not add a Thread.Sleep anymore – just add a Debugger.Break in your code. This isn’t new, but I simply hadn’t found a use for this before. This method is actually pretty useful if you want to conditionally attach the debugger in situations like this.

The solution to the problem of the SCM timing out is a method in the ServiceBase class (System.ServiceProcess) that has been added in .NET 2.0. This method is the RequestAdditionalTime, which takes a single parameter – the amount of time in milliseconds that the SCM has to wait additionally before pulling the plug on the service. Note that this method can only be called inside of OnStart, OnPause, OnContinue and OnStop (basically all the commands you can forward to the SCM).

Neat!

Useful additions in .NET 2.0 - Part 3: EventHandler

Manoj G — Sun, 01 Jan 2006 19:28:00 GMT

If your .NET class needs to generate events, at a minimum, you typically do the following:

1) Create a new class which derived from EventArgs – the instance of this class would be used to communicate certain information to the event handler about the event itself. For example, CacheExpiryEventArgs.

2) A new delegate type whose instance points to a method, the signature of which looks something like:

public delegate void CacheExpiryEventHandler(object sender, CacheExpiryEventArgs e);

3) You declare an event which is associated with the delegate you created in (2). For example,

public event CacheExpiryEventHandler CacheExpired

Now, for every event in your application, you invariably create as many delegate types. If you notice, each of those delegates differs only by the second argument of the event handler – the class representing the event arguments. Now, wouldn’t it be great if you had a generic delegate parameterized by the respective EventArgs argument. With generics in .NET 2.0, this is exactly what you get, in the form of EventHandler<TEventArgs>. With this in place, our example now would look like:

public event EventHandler<CacheExpiryEventArgs> CacheExpired;

This is definitely convenient, as it would reduce the number of delegates that are created in any application. Generics is a great addition in .NET 2.0, which not only gives you performance and strong-typing, but also certain productivity benefits like in this case, and for that matter Nullable<T>, List<T> and may such instances.

Useful additions to .NET 2.0 - Part 2: Nullable Types

Manoj G — Sun, 20 Nov 2005 07:14:00 GMT

Nullable types, put in simple terms can be thought of as a way of having nullable value types. Quite obviously, one of the largest applicability of this concept is that of database programming, where you can associate a null value with any datatype. Not too long ago, while coding the data access layer, I did quite a lot of magic value checks on values to see whether I had to associate a null value (DBNull.Value) to the corresponding database parameter. This included Guid.Empty, Int32.MinValue, DateTime.MinValue and so on. So, I had to create one helper method for all the types that needed such checks. The example for int is shown below:

static object GetDbIntValue(int val)
{
    if (val == int.MinValue)
    {
        return DBNull.Value;
    }
    else
    {
        return val;
    }
}

Now, this effort is not good in a lot of ways though it serves its purpose. This methodology would require a handshake between the Business Logic Layer (BLL) and the Data Access Layer (DAL) as to what values are acceptable and what are not. The problem is that there is no universally accepted set for the same, and hence there would be semantic coupling between the Biz and the DAL layers. The handsome alternative to this situation would be to use Nullable types. Wherever you used magic values, replace them with the corresponding instances of Nullable<T>. Most typically, these would be in the data transfer objects (DTO). In the DAL, we could now have a single helper function (in lieu of many in the earlier case), which looks something like:

static object GetDbValue<T>(Nullable<T> val) where T : struct
{
    if (val.HasValue)
    {
        return val.Value;
    }
    else
    {
        return DBNull.Value;
    }
}

An adroit developer might question whether this helper nethod is really required. Why not have the IDbDataParameter instances 'infer' the right Dbtype from correponding nullable types. For example, you might have wanted this snippet to work without a hitch:

Guid? id = Guid.NewGuid(); //Just an example
SqlCommand cmd = new SqlCommand("Select * from Sample where id = @Id");
cmd.Parameters.AddWithValue("@Id", id);

But unfortunately, at this point of time, there is no conversions built in for nullable types and you would end up getting this exception message:

No mapping exists from object type System.Nullable`1[[System.Guid, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]] to a known managed provider native type.

So, till there is support for Nullable types from System.Data (not sure why it should not be), you are better off using the simple helper listed earlier.

Before closing off, I would recommend that you read this article to understand all aspects of Nullable types.

Nullable types, unfortunately, is fully supported only in C# 2.0, and not in VB. In other words, VB does not have the additional language additions and compiler changes needed to support nullable types in a way C# does. However, nothing stops you from using Nullable<T> in VB; it is just that you would not have the shortcut notations like in C# (int? etc). You are encouraged to read this blog post by Paul Vick, who explains this in detail.

BackgroundWorker and SynchronizationContext

Manoj G — Thu, 03 Nov 2005 04:40:00 GMT

I have mentioned umpteen number of times earlier - .NET 2.0 comes with a wealth of new classes that have been added to the BCL. Today’s turn is of BackgroundWorker. If you look at the available documentation (circa Beta 2), this is what you will find:

“Executes an operation on a separate thread”. You first reaction would be “Heck, what’s so “new” about that?” Okay, so let’s spelunk into its properties and methods and try to find out.

Methods
RunWorkerAsync	Starts the designated method on a separate threadpool thread.
CancelAsync	Requests the cancellation of the pending background operation
Events
ProgressedChanged	This is called when the ReportProgress method is called
RunWorkerCompleted	Occurs when the background operation is completed
DoWork	Occurs when the RunAsync method is called.

Again, after looking at these, you thoughts wouldn’t change – “Still, what’s so great about the same? I had created similar helpers in .NET 1.1.”. Fine, let me tell what’s new. The very interesting aspect about the BackgroundWorker is the fact that RunWorkerCompleted and ProgressChanged event handlers would execute on the thread that created the BackgroundWorker object – most typically on a Windows form main thread (the thread on which the UI controls are created). Therefore, you now do not fall into a trap that you used to fall into earlier – updating a winform control on the wrong thread and facing unpredictable results. (Note that the DoWork method runs on a separate threadpool thread – do not update UI controls on that method)

So, you would now say: “Cool, the BackgroundWorker probably has a reference to the ISynchronizeInvoke object, and it would call Invoke on it to dispatch the method on the right thread. (System.Windows.Forms.Contrtol class implements the ISynchronizeInvoke interface) ”.

If you look closely, the BackgroundWorker is actually agnostic of the environment it runs in. It could not even be a winform application, or even if it was, it does not really rely on ISynchronizeInvoke directly. So, how does this magic happen?

With the help of the valuable services of Reflector, I came to know about a new class (a set of them actually) introduced in .NET 2.0, which

are responsible for this magic – SynchronizationContext. Here’s what the documentation says:

“Provides the basic functionality for propagating a synchronization context in various synchronization models. The purpose of the synchronization model implemented by this class is to allow the internal asynchronous/synchronization operations of the common language runtime (CLR) to behave properly with different synchronization models. This model also simplifies some of the requirements that managed applications have had to follow in order to work correctly under different synchronization environments”

Can’t gather much from this explanation isn’t it? What is does mean perhaps is no more Control.Invoke. But it appears as if it is analogous to the thread’s Context object we had earlier, and a bit more specialized. By now, it would have rung another bell with you. As of .NET 2.0, in the case of Thread.Start method, the security context of the creating thread would be passed to the newly created thread. Guess what is behind this?

I tried a hand at this new class, simple stuff actually. I created a thread from the button click handler on a winform app and updated a control from the thread method (through anymymous method in this case). This is the snippet I tried:

private void button1_Click(object sender, EventArgs e)
{
    ctx = SynchronizationContext.Current;
    // thanks to anonymous methods, everything here is inline
    // thanks to me, this is confusing
    ThreadPool.QueueUserWorkItem(
        delegate(object state)
        {
            // would be true
            Debug.WriteLine(Thread.CurrentThread.IsThreadPoolThread.ToString());
            ctx.Send(delegate(object someState)
            {
                // would be false
                label1.Text = Thread.CurrentThread.IsThreadPoolThread.ToString();
            },null);
        }
    );
}

Send is the method of the SynchronizationContext class to dispatch the method on the right thread synchronously. To do the same asynchronously, we call Post.

Another interesting thing to note is - in .NET 2.0, if you update a control on the wrong thread, you get an InvalidOperationException. As of 1.1, there was no exception, but the result was unpredicatable.

As you might have already guessed, there is not much documentation yet. But, unlike ContextBoundObject, ContextAttribute and other related classes, you might be seeing a lot of articles and proper documentation in the near future. At least, I shall spelunk a little more and come with an article of sorts.

Small, but useful additions in .NET 2.0 – Part 1

Manoj G — Thu, 27 Oct 2005 04:31:00 GMT

The BCL in .NET 2.0 has a plethora of small additions, which are not that visible, but are very useful. I’ll try to cover many of these in my subsequent posts.

String.IsNullOrEmpty is one such method. As the name would indicate, this method returns true if the string argument passed to this method is either null (nothing in VB) or empty.

VB 2005 has some good additions too. Among others, I like the IsNot operator. How much more did you want this operator after writing code like this:

If Not obj Is Nothing

Then

Now,

If obj IsNot Nothing …looks much better.

SetMaxThreads: A good addition to the ThreadPool class in 2.0

Manoj G — Thu, 06 Oct 2005 14:18:00 GMT

The ThreadPool class is very handy to developers. You could queue a method to run on a separate thread and forget about it, without worrying about managing the thread object or about a possible thread explosion scenario. That’s because the .NET ThreadPool keeps a tab on the number of executing threads, which I believe is a maximum of 25 per processor. This might sound just fine, but recently, I came across a situation where even 25 threads per processor looked expensive – I needed to limit the count to something like 10. Unfortunately, the ThreadPool class didn’t give me a method/property where I could set a thread count in the pool to something smaller. I wasn’t adept enough to host the CLR, where I could tweak this count. Instead, I decided to write a simplistic wrapper over the ThreadPool class, which basically did these things:

Keep a count on the number of active threads (which I wanted to limit in the first place)
Maintain a queue to store requests is threads aren’t available
A timer implementation, where a thread periodically checks whether queued jobs can now be pushed to the thread pool

Quite obviously, this is a logical replica of the ThreadPool implementation itself, which is pretty wasteful. But that was until .NET Framework 1.1. In .NET 2.0, the ThreadPool class comes with this new method called SetMaxThreads – just what I craved for. You can use this to set the maximum number threads in the thread pool. There are two values to set here – one for the worker threads (which is more relevant in my case), and one for IO Port completion (this is useful for asynchronous IO operations).

Again, it is one's responsibility not to set an arbitrary high value of worker threads; Do I need to explain why?

DataSets - A journey from a boon, to a bane and back

Manoj G — Tue, 04 Oct 2005 09:31:00 GMT

One of the biggest cribs about the DataSet in .NET 1.0 and 1.1 was its serialization performance. The DataSet, albeit providing a rich object model to work with data in a disconnected way, was a bane when it came to passing it across tiers of the application, typically in a remoting scenario. It turned out that in this scenario, the DataSet serialization glutted on bandwidth, memory and CPU cycles. Developers who were hell bent on using the DataSet eventually became the undisputed champions of object serialization, using wonky ways to serialize the dataset in an effort to make it optimal. Less nerdy developers adopted not so adventurous means like using custom collections and arrays, but sacrificing the high-fidelity object model of the DataSet in the process.

Someone said that every complex problem has a simple solution, and .NET 2.0 is turning out to be an angel to this end. As you might have already guessed, the voice from the sky is in form of a new property of the DataSet (and surprise, DataTable too) called RemotingFormat, which is an enumeration of type SerializationFormat having two members – Binary and Xml. Quite obviously, the default is Xml, to preserve backward compatibility.

Okay, I am digressing slightly here to note something interesting. The name of the property in discussion is RemotingFormat, not something like SerializationFormat or SerializedAs. I suppose, it is to enunciate two things:

DataSets (and now, even DataTable) implements IXmlSerializable, which is what the XmlSerializer looks for when serializing objects in the web service scenario. So, setting the RemotingFormat property there would be of no consequence, and it does not make sense there either.
Perhaps, DataSets are more apt for remoting scenarios, as compared to that of Web Services. This is not to say DataSets are deemed not usable in web services (as the implementation of IXmlSerializable would clarify). It is just that all the performance issues discussed earlier in this post would still apply in this case.

Finally, I would urge you to read this excellent article by Dino Esposito to get a better insight into this new feature and other improvements that have been added to the DataTable class as well.

Stopwatch your code!

Manoj G — Tue, 27 Sep 2005 13:46:00 GMT

Timing managed code is one thing I do quite often. I guess measurement of the method level execution times is a common task for any application developer for that matter. I have used various methods for measurement; the worst of them all is using DateTime. DateTime simply does not give you that high resolution timing. The alterative was to use a couple of Win32 API called QueryPerformanceCounter and QueryPerformanceFrequency. If you have used MS Enterprise Library, you would see that the Microsoft.Practices.EnterpriseLibrary.Logging.Tracing.Tracer class uses these API for timing. There is a small catch in the implementation though. Since P/Invoke is involved here, every call would result in UnManagedCode permission being demanded. The stack walk thus performed results in some loss in the resolution of the timing. Therefore, it is fair enough to mark the native method helpers with the SuppressUnmanagedCodeSecurityAttribute. This attribute ensures that the permission demand happens only at link time (JIT compile time), and not for subsequent calls. If you are well aware of the security implications of this attribute usage, you are ready to go.

Okay wait, don’t go far implementing all what I said earlier; System.Diagnostics.Stopwatch in .NET 2.0 gives you just that. Here’s a snippet:

Stopwatch watch = new Stopwatch();
watch.Start();
// Some operation
watch.Stop();
int elapsedTime = watch.ElapsedMilliseconds;

The best part of about the Stopwatch class is that it intelligently uses a resolution based on whether the underlying hardware supports a high one or not (QueryPerformanceFrequency API returns true if high resolution is supported). If not supported, the Stopwatch reverts to that provided by DateTime. You can query the IsHighResolution static property to find out whether high resolution is supported on your machine.

InternalsVisibleToAttribute - Friend Assemblies

Manoj G — Mon, 26 Sep 2005 16:24:00 GMT

You come across several situations where you need to develop a set of class libraries, say a framework of sorts, and there are several classes within certain assemblies which need to be marked as internal. You go ahead and mark them as internal, and then realize that there are other classes, within the framework, which are dependent on these marked classes, but exist in other assemblies. This is a problem, and you have no choice – you mark these classes as public and then document that the particular class should not be used directly from the code. You may think that this is a bad design, in a way, but there are no shortage of these in the .NET BCL. How often do you come across MSDN documentation which reads something like:

"This class supports the .NET Framework infrastructure and is not intended to be used directly from your code."?

Ideally, these should have been internal classes, but you simply cannot have them that way. StrongNameIdentityPermission provides an alternative, but it isn’t always practical.

In .NET Framework 2.0, there exists a decent workaround to this problem. A new attribute called InternalsVisibleToAttribute has been introduced, which when applied to an assembly indicates that all internal types in that assembly would be visible to another assembly, whose name is specified in the attribute constructor. In other words, that assembly becomes a friend assembly. The usage would be something like:

[assembly:InternalsVisibleToAttribute("MyFriendAssembly”)]
Or (for a strong-named friend)
[assembly:InternalsVisibleToAttribute("MyFriendAssembly, PublicKeyToken=45cb56a45e0a69a1")]

Don’t get carried away, refer to this MSDN section to know more about the constraints and other considerations while using this attribute.

Now, what could be the usage scenarios for this attribute? I have already explained one such scenario in the earlier sections of this post. Another case may be that of unit test assemblies. Typically, we keep unit tests in separate assemblies. Now, to be able to test all the internal classes/methods, it would be useful to gain visibility into them. So, we may declare the unit-test assembly as a friend of the actual assembly.

[Digression: Adroit users of VS 2005 may quickly pounce upon the last use. VS 2005 unit testing framework provides reflection-based helpers which help you write tests against non-public members of a class. So, it’s left to you to decide which a better choice is]

HttpListener in .NET 2.0 - Creating new possibilities

Manoj G — Sat, 09 Jul 2005 20:28:00 GMT

Microsoft's vision of the .NET Framework was a that of a platform for developing Web Services; the primary motivation behind this inception being ease and productivity for developers, and performance and scalability for the deployed applications. Developers have been leveraging the .NET Framework to develop Web Services in the form of ASMX. So much are the productivity benefits of ASMX, that developers are more or less absolved from the nitty-gritties of SOAP, WSDL and XML Schema.

In the recent times, a new revolution has been dawning in the form of Service Orientation, and Service Oriented Architecture (SOA) seems to be the talk of the town. SOA is about seeing the world as collaborating services, which are autonomous in nature, and communicate with each other through messages. The format of this exchange is governed by a contract and the compatibility by a policy.

Now, my very brief introduction to ASMX followed by a short note on SOA may seem logical to many. To many developers, SOA and Web Services (a.k.a. ASMX) are synonymous. However, a perusal of the core tenets of SOA would draw the line between the two quite clearly. You would then agree that ASMX is just a way of realizing SOA, nothing more. As much as ASMX lends itself towards SOA, it has one big constraining factor - it is currently appears tied to IIS. This, in a way, takes us away from the notion of ubiquitous "services" in an SOA scheme. In my opinion, SOA requires every conceivable type of application to be inherently capable of exchanging messages using standards like SOAP and HTTP. In other words, applications should be capable of hosting ASMX without having to rely on the services of IIS.

For an application to host ASMX, two things need to be in place: An HTTP listener which can cater to HTTP requests on ports 80 and 443, and the ability to host the ASP.NET's HTTP runtime infrastructure, which is used by ASMX. Now, of the two, the second requirement is already available in ASP.NET 1.1 in the form of classes in System.Web and System.Web.Hosting namespaces. Infact, ASMX was designed from the ground up to be decoupled from IIS. So, the only void at this point is that of an HTTP listener.

Come .NET 2.0 and this need is well addressed. Starting with Whidbey, and running up to the Indigo timeframe, any application would be capable of hosting ASMX, made easy by a few managed classes like HttpListerner. This ability opens the door for a multitude of possibilities and easier ways to realize SOA.

Hopefully, this news has got you exited and left you begging for more technical details. With this note, I would leave it over to this excellent (as always) article from Aaron Skonnard, one of my favorite authors:
Service Station: Run ASMX Without IIS

DBProviderFactory - Old wine in a new bottle, but good nonetheless

Manoj G — Mon, 02 Aug 2004 13:40:00 GMT

Quite a while back, I had posted an article in CodeProject titled "Implementing a Provider Independent Data Access Layer in .NET". This article illustrated the usage of a simple provider factory, with which data access could be made generic or provider independent. The implementation was rather straight forward. Callers of the DAL (Data Access Layer) component would work only with Interfaces present in the System.Data namespace. The actual type of provider to be used in the DAL code would be determined through a config file setting and the provider factory would be responsible for returning instances of the required type .

The advantage of this methodology is that it gives you the option of (almost) seamlessly working with multiple providers like OleDb and ODBC without having to lock onto to a specific implementation like SQLClient. With the obvious advantage and seemingly simple implementation, we all could expect a provider factory to be built into the next version of ADO.NET. Well, ADO.NET 2.0 is here and with it comes the DbProviderFactory class. The implementation is fundamentally similar to the factory we discussed in my article but, there are a few important differences:

Foremost among them is that DbProviderFactory itself is an abstract base class and every provider must provide an implementation for this. The provider to use at runtime is obtained by calling the GetFactory static method of the DbProviderFactories class by passing a string uniquely representing that provider. This string is called Provider Invariant Name and is registered by each provider in machine.config. For e.g. for ODBC provider, it is System.Data.Odbc.

The second important difference is that the new provider model is based on inheritance of a set of base classes present in the System.Data.Common namespace. So, you have SqlConnection derived from DbConnection and so on. However, various IdbInterfaces we saw in v1.0 and v1.1 would still be implemented for backward compatibility. I believe the reason behind this change is that ADO.NET classes will constantly evolve to provide more features in terms of properties, methods and events. Exposing the functionality through interfaces can be an overkill in terms of maintenance in the future, wherein you maintain backward compatibility by retaining the old interface implementation, while you add new functionality by implementing new ones (analogous to COM).

For more information on DbProviderFactory, I would really recommend a good article recently published at MSDN : Generic Coding with the ADO.NET 2.0 Base Classes and Factories. This article explains in detail, all the stuff that I mentioned briefly earlier, with a fair amount of examples too.

Ofcourse, there is a lot more to ADO.NET 2.0 than the ProviderFactory. For a fairly detailed listing refer to ADO.NET 2.0 Feature Matrix. Things that catch some interest here are Provider Statistics and improvements of SQLClient wrt SQL Server 2005.

My real peek at VB 2005!

Manoj G — Thu, 22 Jul 2004 11:16:00 GMT

My start with VS 2005 has rather been a bit sluggish. I didn’t really work much with the Community Tech Preview, but when I got the Beta 1, I decided to get my hands real dirty with it. At about the same time, I cam across a few excellent resources at MSDN (especially, A Sneak Preview of Visual Basic 2005). All the new enhancements are great and do take developer productivity to a new high. But its worth mentioning about my top picks (of today):

ClickOnce

I must say my most favorite of the all features in .NET 2.0 is ClickOnce Installation. The concept of Smart Client is indeed revolutionary, because it brings together the best of the two worlds : Easy deployment model of thin clients and Rich UI of the thick client applications. The earlier version of .NET gave a good headstart in this direction, but was littered by limitations that definitely needed to be addressed. ClickOnce does just that. These are the salient features:

Easily configure and publish applications from the VS IDE. You can even use a friendly wizard for this purpose.
Applications can now be configured for offline access. Applications are actually installed on the machine with entries made to Add/Remove Programs snap-in
Applications can now Auto-Update themselves when newer updates are available.

For more info on ClickOnce, refer to this MSDN Mag Article and this MSDN TV Presentation

Edit And Continue [EnC]

An uproar is always in the making if a great feature exists in a previous version is not available in the next. Well, that was the case with Edit and Continue, a feature loved and used by VB devs in the past. So much so, that a lot VB6 friends I know of, actually develop only in the VB6 debugger! In VB6, as you all know, applications are compiled into P-Code (Pseudo Code) and not native code in debug mode. So, under the VB debugger, the code would be interpreted (highly simplified). It may be naive thinking, but I wonder how the CLR team pulled this one off. I am sure the seemingly simple EnC would be a really hard thing to be implemented.

EnC however, does not make its way into C#. Andy Pennel's[MS] blog entry and JayBaz's [MS] entry give more insight into why this was dropped from C#. Nice posts, don’t miss the comments as well !

ASP.NET also doesn’t have EnC as such but supports “Save and Refresh” style of debugging. Have look at Brian Goldfarb's entry on why this was elided in ASP.NET .

Code Snippets (VB 2005)

This is a real cool feature provided by VB IDE. Through this feature, you can insert code snippets of very commonly used development tasks like creating a file etc into the code by using the context menu. C# does not however, have such an extensive set of snippets and I couldn’t find ways to add my own as I could do with the VB IDE.

One notable absence in VB 2005 is Refactoring. Paul Vick, in one of his posts explains. It's pretty funny, but many say that Refactoring is somewhat of a "grunge thing" that an average VB developer would not be too bothered about and hence better left out. I don’t agree with that. I feel refactoring, just like designing, is an art, and it would be great to have the support in the IDE. If you have worked with ReSharper, you would know why. I may not be too experienced to completely know VB's philosophy, but I can say that “Keep things simple” and “Make stuff easier” have been the prime doctrines of VB. Now, the thing to ponder about is - doesnt refactoring fit into one of these isms of VB ?