Last week I was interviewed by the Swedish Microsoft Partner program about my thoughts regarding the MCP program, why we focus on certification and what the value of it is. The article can be found here: http://www.microsoft.com/sverige/partner/callista_mcp.aspx (in Swedish).

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.