Christian Weyer's Blog

Writing T4 templates? Ease your pain with Tangible's T4 Editor

The more I play around with T4 templates in Visual Studio, the more I like them ('like' as an: they help me to solve problems, but I do not love them).
But yes, they are kind of awkward, like classic ASP programming the other day... and Microsoft doesn't help us a lot in not providing any explicit VS development experience for T4. There is no syntax coloring/highlighting, no intellisense - nothing. Just a plain text view - this makes Visual Studio equal to... well, Notepad :)

This is the reason why there are some commercially available T4 editors. The one I am using since a few months is tangible's T4 Editor.

These guys over at tangible are quite bright and - even more important - quite community-oriented guys. They have a super-fast response time when you have questions, problems, bug reports.
This is basically why I chose them. I like the editor and it makes my T4 life much easier, and they help me immediately when something doesn't work.

OK, he is British...: Richard Blewett joins thinktecture

Agreed: there has never been a really good relationship - let's not even start talking about friendship - between Germans and Brits.
Let's forget about this for a while... working together with an industry luminary like Richard Blewett is more than I could ever wish.

Luckily enough, Richard joined thinktecture this week as a high-class consultant - welcome!
Working with Rich (subscribe to his blog here) is surely going to be a lot of fun.

Smells like a domain-specific language for using WCF

No, not these kinds of domain-specific languages (DSL)...
I must admit, the following code has a not too small degree of sexiness. The DSL-iness is not just for WCF but for a number of mainly dependency-injection-related scenarios, but obviously I tend to care more about WCF :)

Service side:

var windsorContainer = new WindsorContainer()
  .AddFacility<WcfFacility>()
  .Register(
    Component.For<LoggingInterceptor>(),
    Component.For<IMyContract>().ImplementedBy<MyService>()
      .ActAs(new DefaultServiceModel().AddEndpoints(
        WcfEndpoint
          .BoundTo(new NetTcpBinding())
          .At("net.tcp://localhost/MyService/internal")
          )
      )
  );


Consumer side:

var windsorContainer = new WindsorContainer()
  .AddFacility<WcfFacility>()
  .Register(WcfClient.ForChannels(
    new DefaultClientModel()
    {
      Endpoint = WcfEndpoint.ForContract<IMyContract>()
        .BoundTo(new NetTcpBinding())
        .At("net.tcp://localhost/MyService/internal")
    })
   )
  );
                    
I am currently investigating a bit into Windsor Castle and its WCF facility. What I see until now I like, but I am just at the beginning.
There is a lot more in Windsor's WCF support which is worth digging into - all in all these features are aimed to make using WCF a bit more natural and a  bit more straight-forward.

Some feature points from the latest release:

*Client Side:

• Automatic generation of WCF client channels when a component has been configured for WCF Client capabilities.
• Any Endpoint or Operation behaviors registered in the kernel will be attached to the channels.
• Automatic cleanup of channel proxy when component is released (channel.Close() vs channel.Abort), i.e. no need to cast proxy to IChannel and call Dispose.
• Automatic detection of unhanded channel faults and re-acquisition of new channel proxy. You can continue to use client proxy even after an exception occurs (by default WCF makes all faulted channels unavailable).
• Ability to use the client channel configuration from app.config/web.config      
• Custom registration provider to simplify batch registration of channels
• Client extensibility interface IClientChannelBuilder. Supports plugging in other ways to create channels (e.g. REST-ful services)

 
*Service Side:

• Automatic management of ServiceHost when a component is configured for WCF Service capabilities.
• Any Service, Endpoint or Operation behaviors registered in the kernel will be attached to the channels.
• Ability to use the service channel configuration from app.config/web.config
• Service extensibility interface IServiceHostBuilder. Support for plugging in other ways to create ServiceHosts.

 More to investigate...

The future of WSCF (and the forums)

Some heads up wrt to WSCF - this is what I just posted over at the thinktecture forums (which have been quiet from our side for a loooong time, sorry).

Hello everybody,

first of all I really need to apologize the long silence in these forums here - sorry!

To make a (quite) long story short:
We will open source WSCF.blue (the version we are currently building for
WCF) by the beginning of 2008.

WSCF has always been a toy project for us - and as we are very busy in 'real' projects we could not work much on it, sorry again.

The questions still open in this forum will likely not be addressed and answered as we are trying to figure out how to host the source code for WSCF (e.g. on Codeplex).

Please watch my blog at http://blogs.thinktecture.com/cweyer/ to get notified when we are done with WSCF.blue.

Thanks again for using WSCF and providing incredibly useful feedback over the years!

Regards,
Christian Weyer

So, some more to come - but I am now mentally ready to give this baby away...

Microsoft's Oslo: What is the fuss all about? Some explanations

Read this - not very technical, but obviously shows the whole idea and vision of Oslo. Finally Microsoft wakes up in this whole area.
What always helps, at least for me, is a roadmap of what we might see when. Here we go (from the PDF to download here):



Disclaimer: the above linked document is a PDF version of an article written by 'Directions on Microsoft' - and I am allowed by courtesy of Microsoft to post the PDF here. Thanks.

Commenting problems

Sorry, we have strange problems when people want to comment on our posts. If you have submitted a comment in the last few weeks and it did not show up here, feel free to contact me.
Sorry again.

Beyond announcements, visions, and rants: A living Domain Specific Language

R.I.P.

No, I won't go anymore into discussions whether x-first or y-first or nothing-first or whatever-first-or-second-or-last is a good way to model service contracts. The only thing I have to state is that sometime people sitting in the glasshouse should not throw stones. Everybody is free to choose the style of modeling technique and methodology that fits best. One party wants and needs angle brackets, another is just happy by coding objects, and yet others are fine the the latest-and-coolest-state-of-the-art-programming-model-and-runtime-that-does-x-first-in-a-revolutionary-way.
It is OK. Only the success of either approach approves either idea. Each to their own.

But what nobody can deny is that we will see a growing number of modeling efforts revolving around domain specific languages. While the scope of DSLs is very broad - we will see some very technical DSLs as well as very end-user- or customer-oriented-domain specific languages - we are still in the kindergarten of this brave new world (yes, I know that DSLs are nothing new... but still this holds).

In the last few days and weeks thinktecture's friend Edward Bakker and myself have been working on improving our DSL for modeling service contracts. This is surely just a start - it only is responsible for dealing with the WSDL-isms of service description and still relies on XSD for the data and message contracts. And no, we do not (yet?) deal with policies.
But it is a start and Edward is most certainly the expert in DSL Tools outside of Redmond's walls.

I could just copy and paste what we were doing and thinking, but Edward did a good job in documenting the evolution of this small and neat DSL.
To be clear: this is not meant to be a product, this will not make it as is into any tool. It is just for us learning the power and flexibilty of DSLs and to get used to the (currently still quite cumbersome) DSL Tools from Microsoft.

DSLs will make their way - maybe not our TSDL (thinktecture service description language) - but at least we start a fire.