This year we attended the European TechEd in Barcelona, Spain. Tons of fun stuff and many Swedish colleagues.

Our impressions from TechEd can be viewed on the Swedish Microsoft MSDN web, found at http://www.microsoft.com/sverige/msdn/teched_2006.aspx (in Swedish).

I gave a talk on WCF Updates at the IBC Euroforum conference yesterday. There seemed to be a good interest in WCF, which of course was encouraging.

The presentation can be downloaded here: Windows Communication Foundation.ppt (567 KB)

Enjoy!

The official white-paper on the subject can be found here: http://go.microsoft.com/fwlink/?LinkId=55933.

This white paper provides an overview of Visual Studio 2005 Team System licensing, focusing on typical configuration and deployment issues. This document will provide a general understanding of the core features, typical deployment scenarios and required licensing for the Visual Studio 2005 Team System product line.

Chris Menegay has some additional information here http://teamsystemrocks.com/blogs/chris_menegays_weblog/archive/2006/02/07/657.aspx.

The TFS release candidate was released a coupe of days ago on MSDN downloads (http://msdn.microsoft.com/subscriptions/).

After waiting half a day for the files to come down the installation was pretty much a breeze. Of course after having installed the previous betas the expectations on the setup wasn't too high... My first attempt was at a single-server installation running as its own domain controller. I started of by uninstalling the old TFS according to the docs. After that I started the TFS setup. This turned out to be a bad solution since the RC won't install on a machine acting as DC. I tried to demote the machine but that broke most other components so I had to reinstall the server, this time as a stand-alone server. After that the install procedure worked pretty well. SQL Server installed fine. I had to stop the SQL Brower service while installing the KB912838 since some files apparently were in use but that was all. An hour later or so I had created a new Team Project!

So far this TFS version seem to be in good shape. Performance is a major difference but there are many changes since beta 3.

The latest version of the setup guide can be found here: http://go.microsoft.com/fwlink/?linkid=40042. Do follow it in detail in to get a smooth install of TFS. So for once its a really good idea to RTFM up front...

There is also a utility to upgrade from TFS beta 3 refresh to TFS RC at http://go.microsoft.com/fwlink/?LinkID=60341.

The PDC'05 is over! It was as usual a very intense and overwhelming event. Many concepts that were already presented at the previous PDC ('03) were re-iterated but there where also new goodies, like for instance the LINQ framework.

While attending the 2005 Microsoft Professional Developer's Conference in sunny Los Angeles we also wrote a day-per-day report for the Microsoft MSDN web in Sweden. The reports can be read here: http://www.microsoft.com/sverige/msdn/features/2005/pdc_2005_start.aspx (in Swedish).

After reading the Pallmann Indigo book I was a bit confused about how to use proxy objects, where the book stated the importance of calling .Close before disposing a proxy object. The standard principle for implementing the .Dispose pattern is to let the .Dispose method close all resources the object has open. If the class implements a behavior where it is possible to close and reopen it (like for instance a database connection) then .Dispose should do a graceful shutdown. Apparently in Indigo WCF this is not the case. Calling .Dispose without first closing the proxy will not perform a graceful shutdown (where buffers are flushed etc). It is therefore necessary to make the extra call to .Close before disposing the object.

The correct code to create, use and dispose a WCF object looks like this:

using (MyServiceProxy proxy = new MyServiceFrontProxy())
{
   result = proxy.DoStuff();
   proxy.Close();
}

Kenny Wolf has a good explanation of the details in the communication object life cycle.

It should be noted that this is the situation as of WinFX beta 1 and the behavior has been discussed to be revised for beta 2. Let's hope they decide that calling .Dispose is enough!

Yesterday I did a presentation on WCF (Indigo) for the Swedish .NET User Group, SWENUG, in Gothenburg. As promised, here are the presentation and sample application I used:

PowerPoint presentation (1,56 MB)
OrderSample.zip (38,92 KB)

This is the first part in a series of small exercises where I try out the diagnostics features in WCF (Indigo). The articles will cover the Logging, Tracing, Performance Counters and WMI features in WCF.

First out is logging. Logging is controlled by using the configuration file for the application. By default all logging is turned off but it can be enabled individually for transport level-, service level- and malformed messages.

The following is an example that enables all message logging:

<diagnostics>

      <messageLogging

            filterTransportMessages="false"

            logEntireMessage="true"

            logMessagesAtTransportLevel="true"

            logMessagesAtServiceLevel="true"

            logMalformedMessages="true"

            maxMessagesToLog="100"

            maxNumberOfFilters="20"

            maxSizeOfMessageToLog="1000000"

      />

</diagnostics>

The highlighted attributes are the key attributes to enable the logging feature. logEntireMessage is set to true in order to have the whole message logged. The default is to only log the message header. The next three entries enable logging at the various levels. Depending on the binding used (and its configuration) there may be quite a few messages logged for each invoked operation. Since WCE logs all messages processed that may include messages things such as policy and security negotiation. It would be interesting to see complete flows of what is happening during the client-server interactions, but that is a different story...

The log files written are named like this:

   PID(AppDomainName)_Ticks_MsgIndex.xml

By default log files are written using a default trace listener, which will write the files at the following location:

   %windir%\system32\Logfiles\Messages

If another location should be used then a trace listener must be added in the "system.diagnostics" section in the configuration file for the source name “IndigoMessageLogTraceSource”.

The configuration below will write log files to a specified point using the provided MessageWriterTraceListener class:

<system.diagnostics>

   <sources>

      <source name="IndigoMessageLogTraceSource"

                   switchValue="Verbose">

         <listeners>

            <add name="multifile" type="System.ServiceModel.Diagnostics.MessageWriterTraceListener, System.ServiceModel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

                     initializeData="c:\logs\messages" 

                     maxDiskSpace="1000" />

         </listeners>

      </source>

   </sources>

</system.diagnostics>

The highlighted attribute sets the directory used for the message logging, in this case c:\logs\messages.

Unfortunately it seems like it is only possible to set the diagnostics configuration before the service is started. If the configuration is changed while the application is running it has no impact. This is of course a limitation that is going to be hard to deal with in a production environment. Hopefully there will be some more work done in this area before the v.1 release of WCF comes out the door.

I've finally finished reading the Indigo book by David Pallmann. In summary a good introduction piece and the book really helps to fill some of the gaps I got from just reading the SDK and playing with the samples. The book could have more in-depth details instead of the sometimes lengthy listings of properties.

I liked the way the author mixed text with examples. The walk-through exercise in each chapter felt effective as well, but may not be that useful to someone that has more than a basic understanding of Indigo (and has worked with the SDK samples). Perhaps it is possible to make the samples a bit less verbose (refactoring, please).

Chapters 1-2 are good intros. Not much more than the SDK docs but a good start.

Chapters 3-7 and 9 are really good and in themselves worth buying the book for. Goes through the programming model, contract, client and server programming etc.

Chapter 8 on security: I was expecting more of this chapter. It goes trough the basics well enough but I had hoped for more examples on how to implement security solutions (certificate management, role based security etc).

Chapter 10 on hosting was a bit thin, but I realize that there isn’t that much more to say about hosting. Since you’ve dealt with configuration earlier what is left is only the different hosting mechanisms. With IIS7 I guess there will be more options. Maybe a couple of more lines on how “RunOnUIThread=true” affects Windows clients could be useful so that the reader understands why this is important.

The final chapters on management, deployment and troubleshooting are also good but definatly on the short side. Could perhaps be joined to one chapter? 

In the end there are a couple of case-studies, which is nice as a complement to the shorter samples in the SDK.

Why were the appendices not included in the book? They must are short enough to be in the book, aren’t they?

For IIS hosting, the .svc files doesn’t have to include the Language tag. It may seem a bit confusing since the services are implemented in separate assemblies.

The proxy close/dispose recommendations in the book are a bit vague and sometimes the examples are a bit misleading. I think the book could benefit from a clear discussion (in a sidebar or so) about the using/close/dispose principle for the Indigo proxies. But I also understand that this is a feature that is being reviewed for beta 2 so maybe the outcome of that will be totally different.

The samples and exercises works well as a complement to the chapter text. They could perhaps be re-factored to be a bit more concise (some examples are very verbose which almost makes it difficult to keep the thread) and the structure is very similar between chapters. For good and bad...

The book unfortunately has a number of annoying errors. Most of them are small but it kept me having to switch between the book, the SDK and the infamous Reflector to be sure I understood each concept correctly. I need to be sure that the content in a book is accurate and usually MS Press books have very few errors in them. But of course this is a beta book that needed to come out early.

To sum up - a good first book on Indigo and definately worth reading. Go get it! http://www.microsoft.com/MSPress/books/7703.asp