Visual Studio extensions for Windows SharePoint Services v1.1

Funny, just as I publish the how to install VSeWSS on a workstation, the good guys from Redmond announced the new version. Main changes that I’m keen to investigate: bug fixes and features support. You can download the new version from here which now also comes with a user guide. Just like the previous version, you should install this new extensions on a local SharePoint machine. That is, unless you feel like hacking it.

And while we’re on the subject of MOSS, check out Javed Sikander’s video on OBA Composition Reference Toolkit on Channel 9. I’d really like to see where this thing is going to be in, say, another 2-3 months. I think it really has the potential of bringing forward the biggest advantage of MOSS which, in opinion, is a rich platform for custom collaboration solutions. This toolkit is a huge step towards implementing the concepts I’m used to see from the patterns & practices group to match the SharePoint development world. Very cool.

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

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]

“Sharepoint”=”Installed”

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.

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

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:

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…

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

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.

Recursive Generics Restrictions

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:

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

Multiple Generics restrictions in VB.NET

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:

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:

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…

Using CCF to integrate LOB applications

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.

Redirecting the appSettings content to a user-specific file

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!

Introducing: Silverlight

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…

Using XPath with Namespaces

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

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:

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:

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.