there has been quite an uproar with code generations lately.

Two interesting announcements caught my attention. First, an announcement was made that the current asp.mvc uses the Visual Studio built-in T4 code generation to drive the scaffolding of the UI. That enables the modification of those templates to meet your unique requirements which is something I always wanted for the Proxy Generation of WCF.

Secondly, the Sculpture project reached version 1.0. This is a very interesting open source project for Model-Driven Development in .NET. In its core, it enables the usage of Molds to support different technologies throughout the range of layers. Here’s a list of Molds available to use in the latest version.

• Database: SQL Server only
• Data Access Layer: NHibernate, SubSonic, CSLA and the Data Application Block
• Service Layer: WCF, Web Services and "just" libraries
• User Interface, a huge range of molds including Web (ASP and ASP MVC), Windows (Windows forms and WPF) and Silverlight

This is an open source project, and with the notion of molds, I think that there’s huge potential for modifications and improvements, such as adding support for more databases. Definitely worth a closer look, and to start, I’d recommend watching the introduction video.

Code generation is not evil, but it has a risk of going extremely wrong. However, with added support from the development tool (e.g. partial classes) and much better tools out there, I think we ought to take a closer look into what code generations gives us. At the end of the day, if it reduces effort & time, I’ll take it!

Now we only have to see and wait what will Oslo bring to the DDD table with its own capabilities of code generations and extensions… Existing times!

If you haven’t already, go read this article by Andreas Grabner explaining some technical details around the usage of the SharePoint Object Model and their impact on performance. I don’t expect nothing will be of great surprise for experienced MOSS developers, but the clarity in which the information is presented makes it a good source of information for any level professional.

This is also a good opportunity to recommend the hosting site, InfoQ, which has a very good combination of articles, videos and other assets. The site focuses on everything software development: project management, architecture and development. I especially like the e-books and the videos from the QCon sessions (oh, I do hope to be able to attend next year!).

Take a look at this early insight on what’s coming in C# 4.

I really like all of it, but that’s easy for me as I’m happy to see any extension added to the language. Well, as long as it keep the same "feel" of what we’re used to see in C# that it.

So, what we could be seeing from the C# team? A lot!

• Dynamic Language Runtime (DLR) to enable dynamic lookup (runtime invocation discovery & binding). This feature will enable duck-typing, integration with dynamic languages and a much better COM integration experience. It’s planned to be delivered with an API to support custom bindings which can greatly improve injection scenarios such as IoC and Mockups.
• Variance and Generalized Constraints support for Generics to enable better inheritance options for generics. The nice thing here is the syntax that is dead simple and self-explanatory.
• Optional and named arguments. Nice syntax candy.
• Better COM integration. Many COM-based syntax candies can be delivered based on these new stuff. COM instances can be mapped to dynamic objects, thus enabling support to default methods and properties, and with optional arguments we can have real simple COM integration code. and here’s a good news to all of you Office automation developers – ref will not be required anymore!

While on this topic, it’s also worth noticing another announcement from InfoQ around C# to support code contracts to enable declarative constraints for types. Think of the Validation Application Block from the source code itself.

A fellow colleague mentioned this ultra-cool data centre run by one of the largest ISP in Sweden. How cool is it, you ask? It’s this cool:

Yeah, very cool. But what’s even cooler is that people are finally changing the rather silly perception they have about IT professionals. I mean, will you be surprised to see decorations and non-practical wow-factors added to a museum or a musical hall? No, you’d actually expect it to be so. And why’s that? I think it’s because we have this perception about artists that they’ll appreciate or at least be more tuned to this kind of stuff. IT professionals are usually perceived as pragmatic, "no nonsense" people so why bother adding decorations and other non-practical stuff?

Well, I for one, am very happy this is changing!

A fellow blogger mentioned the typealyzer service which auto-analyses personality of authors based on their blog. I ran it over several of my blog-rolls with quite amusing results. Anyhow, here’s what it found for my own:

INTJ – The Scientists

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it – often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be pshysically hesitant to try new things.
The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communcating their visions to other people and need to learn patience and use conrete examples. Since they are extremly good at concentrating they often have no trouble working alone.

How about yours?

Visual Studio General Manager, Jason Zander’s, revealed some very interesting announcements around the expected capabilities of Visual Studio 2010 and MOSS at TechEd EMEA 2008. I think this is very much in alignment to an implicit approach Microsoft is shifting to: enabling software development at an architecture and enterprise level, both in more general “tradition” areas but also specifically in SharePoint.

Microsoft launched the Patterns & Practices group for quite a while ago and this group is doing an excellent job enabling architects to develop repeatable-successful solutions using the Microsoft.NET Framework. The group provides reusable artifacts such as the application blocks and design patterns to leverage collective knowledge in order to enable predictable outcomes. In my opinion, this is essential when dealing with enterprise-level applications.

Relying on this managed knowledge means that architects can adhere to successful patterns when handling the overarching concerns of the solutions: we get answers on how to plan for a solution, what products to use, how to provide a build-cycle and what not. And, and this is most important, we are used to this richness of information. We depend on it.

However, when we leave the world of “traditional” technology, RIA, Web Site, Rich Client, Service, etc and we enter the world of Knowledge Management through SharePoint, we suddenly lose out trusty partner. We no longer use application blocks for developing web parts, we do not know how to make our solution testable, and we have to create our own methodology. In essence, we no longer leverage the collective knowledge. Now, you might argue that we have many reusable web parts and heaps of self-proclaimed “best practices” books but almost all of them deal with the technicality of SharePoint solutions, not the bigger picture of solution architecture.

Or at least that was the case in the past. Not so long ago the P&P group released the SharePoint Guidance presumably to bridge that gap, and that’s a good starting. Though I see there are many gaps and holes, especially when you try to bind it with the current Architecture Guide, I think this demonstrates a shift in the approach Microsoft is taking for SharePoint, an approach whose goal is to enable software development at an architecture and enterprise level, especially for SharePoint.

So, going back to the announcements Jason did – I think that these new capabilities in Visual Studio 10 is just another such effort from Microsoft to enable a full software development lifecycle and the VS tool aims to cover the development aspects of it e.g. these capabilities enable multi-members teams working on the same SharePoint solution.

This is a real candy: Typemock released a mockup solution for SharePoint enabling unit test while removing the SharePoint dependency. Go check it out!

Or using their own word….

Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here. The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

I know from my experience unit testing in SharePoint-based solution is a pain so I’ll be difinitely checking it out.

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.

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.

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…