Our coding guru André created a fantastic video explaining mobile tagging:

He also published an article (in German) about that topic on CreateOrDie.de.

The Internet Explorer 8 will provide a cool new features called Web Slices. Users can subscribe to parts of a web pages (a so called Web Slice), e.g. a news section, with just a single click. The Web Slice is added to the Internet Explorer toolbar and notifies the user of new content. The user can watch or read the new content without opening the web page. Integrating Web Slices is just a matter of adding a class tag to a div HTML element. However, with DotNetNuke it’s even more simpler. Today, André updated our CMS to DotNetNuke 5.0. This release added support for Web Slices so I activated this feature on our news page. Give it a try (using IE8) and have a good time!

André is not only an expert on OpenSocial, but also on Silverlight (yeah, that’s the reason why he is working at SnipClip ;)). And so he publishes also articles about Silverlight, as a road trip around the world:

• Der Start in Las Vegas
• Weiter geht’s in Redmond
• Nächster Halt: Palo Alto
• Welcome to Amsterdam

Read them and have a good time!

Martin

Our coding guru André published several articles about OpenSocial on Create Or Die during the last months. Here is a list of the articles:

• Eine Einführung
• Google Gadget API
• Google Gadgets detailliert
• Social Gadgets
• Persistenz und Kommunikation

Have fun reading it and have a good time!

Martin

Recently, I had to deal with a challenging Silverlight 2.0 problem, namely trying to make a synchronous web service call from the UI thread. I made some interesting discoveries which I’d like to share.

The best solution I found to this problem was a knowlegde base article from Daniel Vaughan: http://www.codeproject.com/KB/silverlight/SynchronousSilverlight.aspx

Daniel writes:

… you may have heard that synchronous web service calls are not possible in Silverlight 2 … Well, in fact, they are. In this article I’ll show you how to perform synchronous web service calls, and introduce you to some types that make performing synchronous calls with generated channel proxies a breeze.
…
Some readers may initially protest that synchronous web service calls have no place in a principally GUI application, because it risks blocking the UI thread, leading to an unresponsive UI etc. And while I agree that it’s critical not to block the UI thread as to maintain an application’s responsiveness, I do believe there is a legitimate case for synchronous web service calls on non-UI threads.

In our case the solution was even much more simple.

To be able to explain it, I first have to describe our problem. We wanted to use the following procedure:

• loading of additional assemblies during our application startup
• which are dependent from both a configuration placed within a config file and some content read out from a database
• where the database content is retrieved as an Xml stream by calling a web service
• and the stream is read out with a .NET XmlReader for performance reasons

Unfortunately we had to switch between parsing the Xml and loading the assemblies. Because of using the XmlReader, this could only be done, if the assemblies were loaded synchronously. Our solution was, to load the Xml stream into a XDocument object and parse it with LINQ each time we needed some information to load an assembly, instead of parsing it on the fly with the XmlReader.

This solution had also a drawback, since using an XmlReader instead of an XDocument and LINQ is more performant. However, in our case we could make some changes to the config file, so we were able to load several assemblies concurrently, which saved us more time than we lost using the XDocument object and LINQ.

As soon as the opportunity arises, I will also give Daniel’s solution a shot an blog about my experiences.

Until then, hang in there!

This is for our German readers: Die Technologien XML und .NET sind ein integraler Bestandteil unserer Plattform SnipClip. Das Wissen über die richtige Verwendung von XML im Kontext von .NET möchten wir weitergeben, zum Beispiel auf der BASTA im Februar in Darmstadt im Rahmen des folgenden Workshops:

XML in der Praxis und in .NET

XML hört sich in der Theorie einfach an, verhält sich aber in der Praxis schwierig. Eine Ursache ist die Komplexität der zahlreichen XML-Spezifikationen und Schnittstellen, die das .NET-Framework unterstützt. Ein weiterer Grund ist jedoch die unangemessene Handhabung der XML-Werkzeuge. Der Workshop zeigt Strategien zur Komplexitäts- und damit Problemvermeidung auf und demonstriert die richtige Anwendung von XML. Im Vordergrund stehen die Grundlagen der einzelnen APIs (u.a. System.Xml, LINQ for XML, XSLT, XPath, SQL Server und System.IO.Packaging bzw. Office Open XML) sowie die typischen Fallstricke bei ihrer Verwendung.

Today I ran into a stupid problem while working on a WCF web service. The web service has to return a special response object which includes some further complex data objects. But after assigning these objects to the response object, my web service stopped working with an unsignificant error:

System.ServiceModel.CommunicationException: The underlying connection was closed: The connection was closed unexpectedly. [..]

So what to do now? I wasn’t able to find a helpfull hint where the error occurs or what the error releases. My client side stack trace was unusable for debugging, so I had to find a way for debugging on the server side and found a quite good solution: System.Diagnostics.XmlWriterTraceListener.

To activate the trace listener on server side just append the following lines to your web.config:

<system.diagnostics>
<sources>
<source name=”System.ServiceModel”
switchValue=”Information, ActivityTracing”
propagateActivity=”true”>
<listeners>
<add name=”traceListener”
type=”System.Diagnostics.XmlWriterTraceListener”
initializeData=”Trace.svclog” />
</listeners>
</source>
</sources>
</system.diagnostics>

If done, after a request you will find the file “Trace.svclog” server side which contains all information you need for debugging. You can open it with “Microsoft Service Trace Viewer” which simplifies the evaluation of service behaviour. So if you get an unsignificant error on client side be sure to find more information in trace log on server side!

P.S.: By the way, my error was a serialization error and now it works :)

This Tuesday, Microsoft released what we’ve all been waiting for: the final version of Silverlight 2.

Of course we were prepared and already had migrated our Silverlight application to the Release Cancidate 0. And we were lucky: there have been no changes made to the Silverlight API, that would break our code. However the installation of the Silverlight 2 RC1 SDK brought some problems and a solution along, which I would like to share:

After the first time I installed the Silverlight Tools for Visual Studio 2008 SP1 and the Blend 2 Service Pack 1, Visual Studio told me that the Silverlight debugger component had not been installed. So I uninstalled the Silverlight Tools (but not the Blend 2 Service Pack) and reinstalled it. My reward was another strange error thrown by Visual Studio: The Silverlight 2 SDK has not been installed. So I went on not only uninstalling the Silverlight Tools but also the Blend 2 Service Pack and only reinstalled the Silverlight Tools again. And this time it worked. I was able to compile and debug our Silverlight application successfully. Afterwards I installed the Blend 2 Service Pack again and still everything worked.

Sometimes, software can show strange behaviours. If my experiences helped you installing the Silverlight Tools on your machine, I would be glad, if you let me know this via a comment.

Hang in there and don’t let software get you down!

Like many other folks in these days we also had to migrate our Silverlight code from Version 2 Beta 2 to Version 2 RC0. Fortunately almost none of the API changes affected our code, except an undocumented change to the predefined user control TextBox. We used to trigger the MouseLeftButtonDown event successfully until RC0. After the RC0 update the event didn’t fire and no error was thrown.

Additionally the TextBox was somehow locked whenever its visibility attribute was set collapsed and visible again: the user could not change the text within the TextBox any longer.

Here is our workaround:

• Replace the MouseLeftButtonDown event by a GotFocus event.
• Remove the TextBox from the children collection of its parent element and add it again.

The old code:

XAML:

<TextBox
x:Name="MessageTextBox" Text="(attach a message)"
MouseLeftButtonDown="MessageTextBox_MouseLeftButtonDown"
Height="80" Width="280" FontSize="14" Cursor="IBeam"
AcceptsReturn="True" VerticalScrollBarVisibility="Auto"
Style="{StaticResource TextBoxMessage}"/>

The new code:

XAML:

<TextBox
x:Name="MessageTextBox" Text="(attach a message)"
GotFocus="MessageTextBox_GotFocus"
Height="80" Width="280" FontSize="14" Cursor="IBeam"
AcceptsReturn="True" VerticalScrollBarVisibility="Auto"
Style="{StaticResource TextBoxMessage}"/>

C#:

ConfirmationDialog.Children.Remove(MessageTextBox);
ConfirmationDialog.Children.Add(MessageTextBox);

Great news this morning (in Germany):

This evening we published the first public release candidate of Silverlight 2.
There are still a small handful of bugs fixes that we plan to make before we finally ship. We are releasing today’s build, though, so that developers can start to update their existing Silverlight Beta2 applications so that they’ll work the day the final release ships, as well as to enable developers to report any last minute showstopper issues that we haven’t found internally (please report any of these on the www.silverlight.net forums).

Via Silverlight 2 Release Candidate Now Available – ScottGu’s Blog