New Blog Location http://www.nootz.net

Well after using blogger for a while I've decided to move this blog to it's own domain.

Please update your bookmarks to the new location.

http://www.nootz.net

Visual Studio Code Snippets Editor

I recently stumbled across this little program for managing your code snippets in Visual Studio. The program is called Snippy the Visual Studio Code Snippet Editor. It made creating common code snippets for my company a breeze. Check it out at Snippy.

Sql Server 2005 Notification Services and Remoted Service calls

I've recently have been working on a custom delivery protocol for notification services. I needed a way for sql server 2005 to call a remoted service when a trigger fired, to try and avoid polling the database for changes or using a SQLDependency that would need to be wired back up after each firing.

The delivery protocol takes 2 parameters from the instance config file: Service Contract Type (IServiceContract) and MethodName (The method to call).

On intialization I load the contract assembly in and reflect on the type to get the MethodInfo for later usage. It currently does not support overloaded methods and will only grab the first method match.

if (channelArgs.Count == 2)
{
string service = channelArgs["ServiceType"];
methodName = channelArgs["MethodName"];
Type t = TypeLoader.LoadType(service);

//I'm using windows security on my remoted object hosted in IIS, so setting the current principal is necessary.
Thread.CurrentPrincipal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
MethodInfo[] myMethodInfos = t.GetMethods();
foreach (MethodInfo Mi in myMethodInfos)
{
if (Mi.Name == methodName)
{
myMethodInfo = Mi;
//Store the parameters for later usage.
info = myMethodInfo.GetParameters();
break;
}
}
}
else
{
throw new ArgumentException(
"Inadequate number of arguments supplied.");
}

When a delivery notification comes in, I take the list of ProtocolFields and match them to the method parameters and invoke the method.

bool successfulDelivery = false;
Exception failureException = null;

try
{
foreach (NotificationHeaders header in headersList)
{
object[] param = null;
// Set the method parameters.
if (null != header.ProtocolFields)
{
param = new object[header.ProtocolFields.Count];
int idx = 0;
foreach (string protocolField in header.ProtocolFields.Values)
{
Type tp = info[idx].ParameterType;
object o = Convert.ChangeType(protocolField, tp);
param[idx] = o;
idx++;
}
}

object obj = ServiceFactory.CreateInstance(t, service);
myMethodInfo.Invoke(obj, param);
}
}
catch (Exception ex)
{
failureException = ex;
// Handle any exceptions here; for instance,
// write exception information to the event log.
}
finally
{
SendStatus(headersList, successfulDelivery,
body, failureException);
}

You will need to make sure RemotingServices.Configure has been called before the method is invoked. Also the ServiceFactory is a helper to extract the particulars of creating the object away from any client code to allow for future support of Windows Communication Foundation (WCF) or any other communication protocol. SendStatus returns the message status to Notification Services.

There is certainly some cleanup that needs to occur but the jist is there. This allows Sql Server 2005 to call back to any service when an event occurs in the database. Next I'll post the application config files to setup the service.

DesignMode and Checking Design Mode on a WinForm

DesignMode checking can be troublesome with form inheritance. An example would be a base form has an OnLoad that does something

private void OnLoad(object sender, EventArgs e)
{
if (!DesignMode)
{
//Do something here.
}
}

Where the trouble starts is when the derived form is loaded in the visual studio designer. DesignMode solving to true in the base form is not always guaranteed, therefore an acceptable solution would be the following:

///
/// Indicates if the current view is being utilized in the VS.NET IDE or not.
///
public new bool DesignMode
{
get
{
return (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv");
}
}

Framework Design Guidelines

First things first, I'm a strong advocate that every .Net developer should read the book Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. (ISBN: 0321246756) I've read it 3 times from front to back and refer to it on almost a daily basis. As this reviewer puts it, "Nothing less than wisdom distilled".

Nothing less than wisdom distilled, November 7, 2005

Reviewer:

John Gossman (Seattle, wa USA) - See all my reviews

At Microsoft I work on a development team that has been using the guidelines from this book for nearly 4 years. I am not always a fan of coding standards, thinking they are a necessary evil, often simply arbitrary choices made for consistency.

The Framework Design Guidelines are different. These ensure deep consistency across not just source code, but more importantly the public classes themselves. They include critical, not to be ignored rules on security, cross-language access and localization, as well as the usual good practice type guidelines. But even these "good" practices are always backed with well reasoned argument and examples. As an added bonus FxCop provides a static analysis tool that enforces the guidelines.

Finally, the Framework Design Guidelines provide deep insight into how the .NET Frameworks are designed and used. With the guidelines in mind it is far easier to remember or even guess what classes are provided and how they should be used. This just makes the libraries that much more productive.

The insights enclosed show the trials and tribulations Microsoft had developing the .NET Framework and will surely help you prevent the same problems in your software designs.

First Impressions

Well I said to myself for years that I would never get involved in "Blogging" but here I am coming into the 21st century. I've created this blog to post some of the tips and tricks I've found over the years to .Net and any interesting articles I find. I'm hoping to help others avoid some of the pitfalls I've had trying new technologies. So check back often and maybe we'll just learn something.