Cottleston Pie

Fernando Felman’s thoughts on software development

HOW TO: Check the Type of a COM Object (System.__ComObject) with Visual C# .NET

Posted by Fernando Felman on February 5, 2008

This one is a favourite of mine since I tried to resolve it in the past with no success.

The problem at hand is that we have a COM object o returned from Excel interop and we have to figure out what underlying interface it implements. If you try to use GetType() you’ll get a __ComObject which does not provide any helpful information as to what underlying types are implemented by the object.

The following KB article sheds some light: http://support.microsoft.com/kb/320523. The suggested way in the article is to manually cast the object to any known type using the as directive and if a valid object is returned – that type is implemented by the object. This solution will work, but it’s utterly ugly and requires vast amounts of typing in order to support all the possible types. I needed to implement something similar without using manual casting, essentially I needed a method that receives a COM object (of the type __ComObject, assuming it was created by the Excel interop) and returns the underlying interface supported by that object.

First I thought to somehow ask the object to provide me with a list of implemented interfaces. Something like the System.Type.GetInterfaces method. The problem is that the type of the object does not expose any useful information and the object itself has no typed class, so that proved to be futile.

Then I thought that instead of getting the implemented types from the object, I can query all the existing types one by one. Sure, it’s not as pretty as the previous path but that’s actually how COM works by design. Every COM class implements the IUknown interface which supports the QueryInterface method used to get a pointer to where an interface is implemented in the class. The idea is that all the information about what methods are supported by the interfaces and what interfaces are implemented by a type should be acquired in advance and coded into the caller (IDL, TLB and h files comes in mind). There was no true run-time reflection in the old COM days.

.NET supports COM by means of interoperability proxies. I won’t get into too many details, but basically you get .NET objects typed as __ComObject mapping COM instances and .NET interfaces with some unique attributes mapping COM interfaces. More to the point, you get the System.Runtime.InteropServices.Marshal class to handle all bunch of COM and interop operations such as calling the QueryInterface method on a .NET object mapped to a COM instance.

So now we know that we can query interop interfaces against the object. Sweet. But in order to do that we need the Interface ID, or iid, which is the GUID identifying an interface in COM. Oh, and we need that for each end every COM interface implemented by the Excel interop. Not sweet. OK, but we’re in .NET world now (thanks to the System.Runtime.InteropServices namespace) which has great support for runtime reflection. How difficult would it be to enumerate all the COM interfaces implemented by the Excel interop? Not too difficult really, we can use the System.Reflection.Assembly class to get a handler to the Excel interop assembly and from there it’s relatively easy going.

So let’s conclude what we need:

  1. Get all the COM interface types exposed by the Excel interop assembly.
  2. Fetch the Interface ID of each type and use it on QueryInterface to test whether an interface is implemented by the object (if a valid pointer is returned, the interface is implemented by the object).

This doesn’t sound too complicated. Obviously there are some syntax and plumbing issues to address, but the concept is rather simple. Good, let’s implement it:

GetExcelTypeForComObject method

Namespaces:
using Excel = Microsoft.Office.Interop.Excel;
using interop = System.Runtime.InteropServices;

Note that in many cases a wrapped COM object implements many interfaces, so breaking after the first implemented interface is found might not do it for you…

Posted in .Net v2, Samples, vs2003, VS2005 | 20 Comments »

LINQPad – get your hands dirty with Linq & more on Parallel Processing

Posted by Fernando Felman on September 24, 2007

There’s only one good way to learn new syntax and concepts: get your hands dirty with it. And now we can do just that in Linq using Joseph Albahari’s LINQPad. I especially like the Linq Challenge he posts on that page. Who’s on with me?

More on the Linq topic, Daan Leijen and Judd Hall published a very interesting article regarding PLinq: Running Queries On Multi-Core Processors. On the same issue you will find another great article from those guys: Optimize Managed Code For Multi-Core Machines.

Posted in C# v3, Linq | Leave a Comment »

Recursive Generics Restrictions

Posted by Fernando Felman on September 23, 2007

Here’s an interesting question for you, Generics gurus. Is the following is a valid definition for a generic class in c#?

public class Generic<T> where T : Generic<T>

On first glance it seems that the recursive restriction on type T cannot be possible. For example, if we would like to pass “string” as the type T we would have to wrap it with Generic<string> which in turn needs to be wrapped with Generic<Generic<string>> which in turns needs to be wrapped with Generic<Generic<Generic<string>>> and so on and so forth. But a closer examination reveals that this is actually a valid declaration.

The restrictions on the type T are used to ensure that the type we pass can be treated as the restricted type. In other words, whatever type T we chose to pass, the compiler should be able to cast it to the form Generic<T>. In our case, any class that derives from Generic<T> responds to the restriction and can be used. To conclude, the restrictions on the class Generic<T> defined above ensures that the passed type T is derived from itself (from Generic<T>). For example, the following is a valid class to pass as T:

public class ValidClass : Generic<ValidClass>

 

When can this be used? The recursive restriction shown here can be useful for factories, in which you want to define some basic logic and return a well known type. Consider the following example:

Generic Factory with Recursive Restriction

Using the recursive restriction of Generics we can enforce type affinity to the Employee factory.

Posted in Generics | 3 Comments »

Multiple Generics restrictions in VB.NET

Posted by Fernando Felman on July 17, 2007

Did you know that VB.NET accept curly brackets ({ })? Neither did I, but it does for the special case of multiple restrictions describing a Generics type.

I needed to code a web service factory, and I used Generics to do so. In C#, the code would look like this:

Generics web service factory in C#

The Generic type T has multiple restrictions: it derives from the base web service proxy and it implements a default constructor. Easy. But the project using this will be a VB.NET, and I’d prefer to have this factory in the same language. So, after some digging, here’s the same factory implemented in VB.NET:

Generics web service factory in VB.NET

Seams to me that the multiple restrictions notation in VB is very much like an in-line array initiation in C#. I think some C# developer suggested this syntax – it’s just so not VB like…

Posted in .Net v2, Generics | 1 Comment »

Using CCF to integrate LOB applications

Posted by Fernando Felman on May 23, 2007

Here’s some news for the architects out there: check out CCF. CCF, which stands for Customer Care Framework, is an integration framework from Microsoft targeted for customer care environments (“call centers”). I was introduced to this framework on my last project in which I assisted in the architecture of an integration project for a customer care department.

The interesting thing about CCF is that the integration of LOB applications is done in the front-end layer, not in the middle tier. This is a great money saver for the business since it maintains the existing business logic and does not require re-development (as is the case in most SOA projects).

In a nutshell, CCF gives you the following:

  1. Non-disruptive integration layer: the integration of existing systems is done on the call agent’s desktop by hosting the applications. The hosted application is not modified (its source code shouldn’t be touched) so the business logic and the data validation of the application is honored. CCF can automate the UI of the hosted applications based on the customer’s context (the customer being handled by the call agent).
  2. Configurable business scenarios: CCF supports “workflows” to assist the call agents in using various integrated systems to perform a single business operation. For example, the scenario “create customer” might include updating the accounting systems and the product systems. Using CCF workflow the admin can deploy a “Create Customer” business scenario that redirects the call agent to the relevant systems (and if automation is implemented, CCF can further assist by automating the manipulation of fields in those relevant systems).
    Note: the term “workflow” is not the best ever, a guided wizard would be more accurate (and that’s why I’ll never be a salesman).
  3. Customer-context driven development: one of the key aspects in CCF is the Context which contains the fields associated with a customer. CCF can then use the context in order to automate hosted systems (so the CRM will automatically perform a customer search when the context is loaded to the CCF) and it can also forward the context to other agents (so if you’re redirecting between call agents, your session is always maintained).

It is important to notice that CCF is not a solution, but rather it is a framework. You won’t be able to “install and go”, you’ll have to learn the tools and concepts and develop your solution accordingly. Once learned, CCF can really add value to customer care related integration projects.

Posted in .Net v2, Architecture | Leave a Comment »

Redirecting the appSettings content to a user-specific file

Posted by Fernando Felman on April 26, 2007

It happens a lot in the development process: the settings in the configuration files differ in the development, staging and production environments and each time you switch environment you’ve to update the app.config. Since you can only save one such app.config, the file version in the VSS quickly gets filled with inconsistent values. Apparently, there is a nice solution to that issue: use the user.config to save user-specific settings.

I found it by sheer luck while reading a very interesting article (Web Projects and Source Control Integration in Visual Studio .NET) in which the appendix A: “Setting Up Dynamic URL Web References”explains how to redirect the appSetting to a user specific file to create dynamic web references. I then did some search on that feature and came across this Q&A posted by Raghavendra Prabhu: http://blogs.msdn.com/rprabhu/articles/433979.aspx.

To redirect the appSettings node from the app.config to the user.config, you’ve to add the following setting to the app.config:
<appSettings file="user.config">

And here’s the funny thing, I knew about the user.config and how the Profiles mechanism in ASP.NET 2 uses it to store user specific settings, but I never did the connection of how it can be used in the development process. Silly really, it’s quite obvious once you think about it. Thanks Microsoft for opening my eyes! 🙂

Posted in .Net v2, VS2005 | Tagged: | Leave a Comment »

Introducing: Silverlight

Posted by Fernando Felman on April 16, 2007

Windows Presentation Foundation Everywhere (WPF/E) is now called Silverlight.

The greatest thing I like about this technology is it’s integration with web browser: it integrates fully with the page using Java-Script from one end and into the .Net world in the other end. I just hope it will be at least as popular as Flash: I sure prefer integrating into Silverlight…

Posted in .Net v3 | Leave a Comment »

Using XPath with Namespaces

Posted by Fernando Felman on April 9, 2007

This is something I’ve been asked about quite a lot: how to perform XPath queries with namespaces. I will demonstrate how to do that using a sample InfoPath form XML file. InfoPath generates the schema for the XML form at design time and the URI for the schema contains the Date & Time the schema was created, so it’s a dynamically generated URI.

Here’s a sample of an InfoPath file. Notice the URI of the ‘my’ prefix and how it contains the Date & Time of when the structure was created
InfoPath Sample Form

We’ll fetch the generated namespace URI at runtime and use that namespace to perform an XPath query.
The generated namespace in InfoPath will always have the ‘my’ prefix and will always be declared in the root node. With that piece of knowledge in mind Knowing that it’s easy to fetch the generated URI using the GetNamespaceOfPrefix method:
Fetch URI from Xml Node

We can now load the generated namespace URI into an XmlNamepsaceManager class. With the namespace loaded we can perform an XPath namespace-aware query to fetch the ‘destination’ node. Notice that I chose to use the ‘infoPath’ prefix instead of the ‘my’ prefix to emphasize the fact that the prefix used in the XML file (i.e. ‘my’) has no meaning in the XPath query:
XPath query with namesapce

To conclude: in order to use XPath queries with namespaces you must first load the namespace into an XmlNamesapceManager. You can then use the prefix of the namespace to perform an XPath query using the namespace manager. You can also fetch namespaces from a node using either its URI or its prefix.

Posted in .Net v2, Samples, XML | 2 Comments »

Implementing multi-threading in WinForms using the BackgroundWorker class

Posted by Fernando Felman on April 4, 2007

I’ve been asked how to implement multi-threading in .Net 2 quite a few times. The last time was specifically for multi-threading in WinForms and that is the focus of this post. Note that the techniques discussed in this post can be easily adopted to any .Net 2 application (and not just WinForms).
In a multi threaded environment you will have one thread handling the GUI controls and one or more worker threads performing time-consuming operations. The requirements of a multi-threaded solution (regarding the worker thread/s) will be:

  1. The ability to start a worker thread (a logical operation) in an asynchronous manner
  2. The ability to get status notifications from the worker thread and communicate the updated status to the user
  3. The ability to terminate the worker thread by request of the user
  4. The ability to handle errors that occurred in the worker thread during its operation

Starting from .Net 2 we can use the BackgroundWorker class (from the System.ComponentModel namespace) which handles many of the tedious plumbing tasks for us. The BackgroundWorker class support asynchronous activation, status updates, worker termination and the wrapping of any error thrown by the worker thread. This class can be used in any .Net 2 environment (and not just WinForms environments).

In this post I’ll walkthrough a multi-threaded WinForms application. Please download the sample application source code from the CodePlex project Release page. We will create an application to find prime numbers: the user will insert the limit to search and the application will find all prime numbers in that limit. The user should see a status bar progressing for each number tested and a list of prime numbers that will be filled during the process. The user should also be able to cancel the operation at any time.
findprimenumbers.png

Setting up the BackgroundWorker component
OK, let’s start by creating a C# Windows Application. In designer of the form, add the BackgroundWorker component from the “Components” category:
backgroundworker-component.png

The component is added to the bottom section of the designer (where all the non-graphical components are displayed). Click it and change the following properties in the “Asynchronous” section:
WorkerReportsProgress: True – this allows us to send progress notifications
WorkerSupportsCancellation: True – this allows us to cancel the operation at will
backgroundworker-properties.png
Switch to the events view of the property editor and double-click on all the events:
backgroundworker-events.png

We now accomplished all the plumbing tasks of the multi-threaded application. We’ve an asynchronous activator that will notify progress and can be stopped. Now we’ve to add the logic of the application – that is, finding prime numbers and attaching the worker to GUI controls.

In the form there are some controls so the user can interact with the application: a number field, a start/stop button, a progress bar and a logger text box. We now have to use those controls with the worker.

Starting an Asynchronous task: using the RunWorkerAsync method and DoWork event
The background task is handled in the DoWork event. The handler for this event will be called from a new worker thread so the task you perform there will not clutch the GUI. To start doing the work just call the RunWorkerAsync. You can also pass an optional initiate state which will be wrapped up and served in the argument of the DoWork event handler:
this.wrkPrimeNumbers.RunWorkerAsync(maxNumToTest);

Calling the RunWorkAsync will create a new worker thread (so the GUI thread won’t be cluttered) which will execute the DoWork event handler: private void wrkPrimeNumbers_DoWork(object sender, DoWorkEventArgs e)
Note how the initiate state we passed to the RunWorkAsync method is served in the event’s argument:
int limit = (int)e.Argument;

It is important to notice that the argument received in this handler is used further on in the flow. I’ll touch this in the appropriate phases, but for now it’s important to remember that this argument may hold information that will be used when the task is completed. One such property is the result. I use the result property to save the number of prime numbers found in the range:
e.Result = foundPrimeNumbers;

Updating work progress: using the ReportProgress method and the ProgressChanged event
Right now the DoWork event handler is doing some time-consuming work without cluttering the GUI. Now we’ve to notify the user about the progress of the work. This is done in the ProgressUpdate evet. In order to notify about the progress you should call the ReportProgress method from the DoWork event handler:
wrkPrimeNumbers.ReportProgress(progressPercentage, currPrimeNumber);

The progress percentage is always passed and you can also pass an optional state (I use this optional state to send the prime number when one is found). This call will execute the ProgressChanged event handler:
private void wrkPrimeNumbers_ProgressChanged(object sender, ProgressChangedEventArgs e)

And here’s the great thing: the code in the event handler is executed using the GUI thread so it’s safe to update the GUI controls without changing threads (no mode InvodeRequired!). Like in the case of the DoWork, the event handler is served with the state:
this.pgbTestedNumbers.Value = e.ProgressPercentage;

Since the event handler is executed from the GUI thread, it’s safe to update the progress bar without switching thread contexts.

Note: the ReportProgress method will work only when the WorkerReportsProgress attribute of the BackgroundWorker class is set to true. We did that in the designer.

Handling completion: using the RunWorkerCompleted event
Now we’ve an asynchronous task working in the background and notifying the user of its progress. When the task is done it will raise the RunWorkerCompleted event. And again, the great thing about this event is that it’s called using the GUI thread, so it’s safe to update the GUI controls:
private void wrkPrimeNumbers_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)

It’s important to understand that this event will always be called when the task is done. The argument of this event contains data regarding the 3 different ways the task has finished:

  • Result: used when the task completed normally. This property contains the result of the of the task. Notice that if the task did not completed normally, accessing this property will throw an exception.
  • Cancelled: used to determine whether the user cancelled the task
  • Error: used when the task failed due to an error. This property contains the exception that caused the task to fail.

The Result and Cancelled properties are set manually in the DoWork event handler and the Error is set by the component when an exception is thrown. This means that you shouldn’t surround the DoWork code with try..catch if you want the error to bubble all the way to the RunWorkerCompleted handler.

Checking working status: using the IsBusy property
Let’s now add the cancelling feature: we want to give the user the ability to cancel the task if it takes too much time. But before we do that, we have to know if we’re busy handling a task or if we’re idle. This should help us decide whether to start a new asynchronous task or to cancel the current one.

This is easily done without the need to query the threading system, all you need to do is check the IsBusy property of the BackgroundWorker class. Too easy, eh? 🙂

I used that property in the Click handler of the start / stop button to decide what action to do:

if (!wrkPrimeNumbers.IsBusy)
// start a new task
else
// stop the current task

Cancelling on-going work: using the CancelAsync method and CancellationPending property
Cancelling an event is done by calling the CancelAsync method. This method can be called from any thread, so it’s OK to call it from the Click handler of the start / stop button. The method will set a property in the worker object so the DoWork event handler will have the ability to act on that.

The CancelAsync method will set the CancellationPending property of the BackgroundWorker class. This property should be periodically checked by the DoWork event handler, and when it’s set to true the handler should cancel its work by: setting the Cancel property of the argument to true and exiting the function. Here’s how I did that in my sample:

if (wrkPrimeNumbers.CancellationPending)
{
// user canceled
e.Cancel = true;
break;
}

As we mentioned previously, the cancel property of the DoWork argument is forwarded to the Cancelled property of the RunWorkerCompleted event handler.

Note: the CancelletionPending property will only be updated when the WorkerSupportsCancellation attribute of the BackgroundWorker class is set to true. We did that in the designer.

So that’s it! We completed our application and we did that without once querying the System.Threading namespace. The BackgroundWorker component wrapped everything for us in a nice Method / Event / Property flow. How great is that?

Epilogue: using the BackgroundWorker class with .Net 1.1
If you’re using .Net 1.1 you’re probably reading this post with both anger and despair.There’s no BackgroundWorker class and you’ve to handle all the plumbing by yourself. But wait, how great would it be to use a .Net 1.1 class with the same features?
Well, in that case, you’d better notice that Juval Löwy published a great step-by-step implementation of the BackgroundWorker class for .Net 1.1: http://www.devx.com/codemag/Article/20639/0/page/1.

Have fun!

Read the rest of this entry »

Posted in .Net v2, Samples, VS2005 | 10 Comments »

Encryption / license issues when upgrading from .Net 1.1 to .Net 2

Posted by Fernando Felman on April 1, 2007

I’ve been called to help in the migration of a .Net 1.1 product to .Net 2. Most of the functionality worked just fine after upgrading but we had an issue with the licensing module: some of licenses we issued failed to validate after the upgrade, throwing a CryptographicException: “Length of the data to decrypt is invalid”. The issue we were having had to do with the changes that the .Net 2 introduced to the GetBytes() method in order to be compliance with the Unicode standard (read full details here):

Encoding.GetBytes() may not emit unpaired high or low surrogate characters for certain encodings (e.g. UTF-8 Encoding and UnicodeEncoding).

The solution was quite simple once the problem was identified: instead of using Unicode.GetBytes to transform the cipher bytes to string we use Convert.ToBase64String (and its symmetric opposite Convert.FromBase64String). The original problem was identified by reading shawnfa’s post from the .Net Security team blog. More details of this problem and how to solve it using the Base64 conversion can be found in the CodeClimber blog.

Tips: If you plan to upgrade a .Net 1.1 application to.Net 2, take a good look into this article. If your application is a web application, also consider reading the articles in this page.

Posted in .Net v2 | Leave a Comment »