i am a camera

Using reflection, you've carefully crafted code to extract data from an old COM object. It works great, and you feel a sense of accomplishment. But now someone is in your office saying something about your ASP.NET app that it's not working. My Code?

Of course you took the time when creating the reflection call to log any problems in the called module, so you look into the application trace log and you see this quite annoying error:

Here's a useful bit of transforming code that I keep looking up in several of my projects. Many thanks to Milan Negovan for the vast improvement over my initial code.

using System.Data;
using System.Xml;

DataSet ds = MethodReturnsDataSet();

XmlDocument xdoc = new XmlDocument();
xdoc.LoadXml(ds.GetXml());

A recent post on c# corner provides a straightforward introduction to the TimeSpan object and shows a couple innocuous examples. Further down, Ms. Choksi disclaims any further nuances such as time zone differences or daylight saving.

The problem is her code is more harmful than helpful. The TimeSpan object is very tricky and everyone needs to take Daylight Saving Time into consideration. Ignoring the topic is setting folks up for trouble down the road.

Dealing with Remote Objects

In this final installment of C# Reflection, I provide my solutions to a couple problems I encountered after successfully retrieving the remote object I wanted.

In the first six installments, the object returned was always an intrinsic type such as string. The Invoke method always returns an object of type object and I've always shown simple casting as the final step.

Passing "out" Parameters

Out parameters are parameters that are expected (and in fact for C# required) to be populated by the called method. That is, the value for the out parameter is not meaningful when passed in and receives a value after the method is called.

bool GetCustName(int iCust, out string strName);

We must first create the object as covered in depth in Part 2:

Passing "ref" Parameters

So far we've made conventional reflection calls. Things get a bit sticky, however, when the method we want to invoke contains a ref parameter. For example, a method with the signature:

bool CheckCustName(int iCust, ref string strName);

Reference parameters are not copied into the receiving method, but referenced from the caller's memory area. Creating the object is not a problem if you've been reading this series: This part was covered in depth in Part 2:

Set Properties on Reflected Object

Suppose that the method that we will eventually call requires that two properties within the object be set beforehand. Why would anyone design a class this way? I can't explain it but there is code out in the wild (ahem) that might require this. If you're one of the other unfortunate ones, here's how to set properties on an object created through reflection.

Passing Parameters

Now with the basic form established, we can move to variations on the theme. First variation: pass parameters to the method we're calling.

Steps 1, 2 and 3 to load the DLL assembly and create a target object remain the same as the previous article:

// load the assembly
Assembly assem = Assembly.LoadFrom(@"c:\path\to\file.dll");
// create a Type object
Type typClsX = assem.GetType("Fully.Qual.ClsX",true);
// instantiate an object of that type
object oClsX = Activator.CreateInstance(typClsX);

The first example with be the simplest and most straightforward. We'll invoke a method that takes no parameters and returns a string. What is as simple as string s = obj.Method(); takes quite a few extra steps when using reflection.

1. Load an assembly from a known Data Link Libarary (DLL) in a known location
2. Create a System.Type object of the class of the object you want to instantiate
3. Create an instance of the class object
4. Create a System.Reflection.MethodInfo object that represents the method we will invoke
5. Invoke the method within the object we created
6. Cast the generic object returned to its proper type

For those who are unfamiliar with .NET reflection, it is a whole area of computing that allows runtime binding to public classes, methods, and properties within external DLLs. Some folks refer to this as late binding.

In .NET, the usual way we call a method in another project's Data Link Libarary (DLL) is by

1. Adding a reference to the component DLL in Visual Studio
2. Adding a #using declaration to the top of the C# file
3. Calling the method just as you would call a local method

I saw a coworker use this technique the other day and thought it clever. I'm sure he's not the first to use it, but it can come in handy especially in static functions without a formal logger.

This C# code will generate null files in your "temp" directory. The filenames will be sequenced based on a timestamp at the front, then the information you're tracking behind.

The Regex.Replace is necessary to weed out the characters that Windows does not allow in filenames, and the length check keeps filenames under 255 characters.

Blosxom seems to be working for me quite well now that it started accepting comments. One of the features provides convenience but also brings with it a problem. It organizes each entry by the date it is posted. Each entry is a file, so it just reads the file date. Convenient.

I don't know about you, but sometimes I need to go back and adjust text or fix a spelling error. Mostly recently, I've been adjusting the framework of my setup that affects the way each entry is structured. So when I made a change, the system would rearrange the order of the entries. Problem.