Cottleston Pie

Fernando Felman’s thoughts on software development

  • Categories Navigation

  • Topics

  • Archives

  • Advertisements

Archive for the ‘.Net v2’ Category

How to install the SharePoint 2007 VS 2005 Extensions on a Workstation

Posted by Fernando Felman on February 11, 2008

SharePoint 2007, or MOSS, is a server product and as such it can only be installed on the Windows Server family platform. I can understand that, it makes sense. What I can’t understand and doesn’t make any sense at all is that I’m not allowed to install the development tools on my new shiny Vista.

The recommendation for MOSS development was always to get a VM to run W2k3 with MOSS and Visual Studio. That’s all fine when you’ve to develop and do cycles of compile-deploy-debug, but what if you want to load an existing web part project with the visual studio installed on your workstation?

If you try to install the Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 Tools (VSeWSS) on a workstation you’d probably fail and get the following error: “This product can only be installed if Windows SharePoint Services 3.0 has been installed first”. So the only thing we’ve to do is to hack the installer into thinking MOSS is installed. How difficult can it be, right?

Before continuing into opening the Regedit tool, be aware that mocking around with the Windows registry is not supported, not recommended and generally considered bad manners.

Now open the regedit and create the following keys and the string value:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0]


That’s it! You have fooled the installer into running on a workstation. Easy. I also recommend adding the core SharePoint assemblies into the CAG using gacutil. Those assemblies can be found by default in any ShaerPoint machine under the folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.

If you’re feeling adventurous enough and want to get the full remote debugging experience, try out this excellent Martin Vollmer’s post.


Posted in .Net v2, Moss, VS2005 | 33 Comments »

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: 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

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 »

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:

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 »

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.

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:

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
Switch to the events view of the property editor and double-click on all the events:

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:

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
// 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;

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:

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 »

MSN Messenger History Merger

Posted by Fernando Felman on March 21, 2007

As a consultant I’ve been sent to customers’ sites quite a lot. Many times I’m provided with a dedicated desktop for my work and I’m not allowed to plug my own laptop. This is usually no biggie as I’ve a USB flash drive that allows me to keep in sync all my settings, preferences, etc.

Saying that, there is one thing which I cannot keep in sync: the history files of the MSN Messenger. MSN Messenger saves conversations history in XML files – one file per recipient. Those files get updated every time a conversation is compete, e.g. every time the Messenger window is closed. This implementation means that each desktop saves its own history files and merging those history files is not an easy task. I tried to find a merging utility in the internet with no success so I’m left without options: I must implement the merging utility myself.

So, this is a long introduction to my latest open source project: the MSN History Merger. This utility will merge MSN Messenger history files from different instances into one complete history folder. The executable file can be downloaded from the Release page (no installation is required).

I do hope you’ll find it useful. If you do, please leave me a comment. Suggestions are also welcomed so feel free to use the discussion lists and the issues tracker to log suggestions and issues.

Posted in .Net v2 | 40 Comments »

Projex, exercising with WinForms

Posted by Fernando Felman on March 9, 2007

I did quite a bit of SharePoint related projects and I learned that one of the most important things you’ve to know when you’re coding a SharePoint Web Part is the Web Control Lifecycle: what events are being called by the infrastructure, when are they called and on which conditions. To that model you’ve to aggregate the SharePoint-specific lifecycle, such as when the Web Part Communication events are being fired and how does that relate to the regular Web Control lifecycle.

So I can say I know about Web Controls quite a bit. But what about WinForm Controls? I wanted to upgrade my knowledge in the WinForms technology to know more about creating Windows Controls, considerations and restrictions I should be aware of, etc. I wanted to investigate the following key aspects in a Widows Control: how does data binding works (and not just how to use it), what are the best practices for coding controls and what internal methods should I be familiar with.

There’s only one good way to learn all of that: experiencing… So I give you my open source, free to use Projex application. This application allows you to create drawings based on a shape I call the Webex, a spider-web shape combined of two points and a mutual anchor point.
Here is how a single Webex looks like:
Simple Webex

And here are some sample of what the application allows you to do (click to enlarge):
Canvax Sample 4 Canvax Sample 3 Canvax Sample 2

The code is constructed in the following way:

  • ProjectXWin: The Windows application. This application has 2 namespaces:
    • Drawing: contains the Pointex and the Webex classes. Both are mathematical representations of a drawing object and aren’t bound to any Control (so you can use them in any displaying technology, including a windows control).
      • Pointex: represents a single Point with anchoring-aware capabilities. I coded this class to encapsulate the anchoring functionality so when the user moves or resizes the drawing area (the window displaying the drawing), the Pointexes will move to their anchored locations causing the drawing to shrink or grow.
      • Webex: a single spider-web drawing represented in an abstract mathematical way. I coded this class to encapsulate the logic of calculating the lines and the resizing functionality for a single Webex.
    • Windows: contains the WinForm controls. This namespace contains many User Controls representing the various value-editors I needed (like Color selector, Pointex editor, etc.) and also have these 2 Custom Controls:
      • WebexPainter: this control display a single Webex. It was coded to facilitate the task of painting a Webex in the form and binding it to its editors.
      • Canvax: a container for multiple WebexPainters. I coded this class to allow the Webex painters to share the same drawing canvas (the same Graphics object).
  • TestProjex: the unit test project implement in MSTest . I usually use NUnit and I wanted to experience with the Microsoft unit test platform to see which is more suitable for me and my team.

Hope you’ll find this project interesting!
Enjoy, and remember that you can leave comments both on the project main page and on the relevant discussion group.

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