Silverlight Hack

Silverlight & related .NET technologies

About Me

Welcome to  This is a site where you can find many articles on Silverlight, Windows Phone 7 and .NET related technologies.  

My name is Bart Czernicki.  I have been working with computers since 1988 and have over 12 professional years in the IT field focusing on architecture, technology strategy and product management.  I currently work as a Sr. Software Architect at a large software development company.

Below is the cover of my new book that shows how Silverlight's unique RIA features can be applied to create next-generation business intelligence (BI 2.0) applications.

Silverlight 4 Business Intelligence Soft 


View Bart Czernickis profile on LinkedIn

NONE of the comments or opinions expressed here should be considered ofmy past or current employer(s).  The code provided is as-is without anyguarantees or warranties.

Silverlight 3 - What we Know So Far & What We Can Predict (Part 2 of 3)

Silverlight 3 Development Stack - Part 2
  • Part 1 - Silverlight 3 Announced Enhacements
  • Part 2 - Silverlight 3 Development Stack
  • Part 3 - Silverlight 3 Integration with the Microsoft OS and Platform Stack
  • Part 4 - Silverlight 3 vs Flash and the iPhone
  • Series Update: In Part 2 of the series, I decided to look at the Silverlight 3 Development stack and Part 3 will look at the Silverlight 3 platform/OS stack (I added another part in the series.)

    In Part 1 of this short series, I looked at what we know so far about Silverlight 3 from what has been announced by Microsoft.  In Part 2 of this series, I take some educated guesses as to what and how Silverlight 3 will be released in relation to the development environment.  Note this article doesn't contain some random guesses.  It is a higher level (architectural) overview of how Silverlight 3 could interact with the upcoming Microsoft development/technology stack.  This article title also might be a little misleading when compared to Part 1 of the series as it tries to predict the development changes in Silverlight 3.

    Silverlight 3 will obviously evolve as an individual technology and this next version will include a lot of changes that have not yet been made public.  However, one of the huge differences between Silverlight and other RIAs is that Silverlight can benefit because of its ties to Microsoft's development, product and OS stack.  This article looks at the Silverlight 3 development stack and its impact for the Silverlight developer.

    Probable New Microsoft Development Stack from Silverlight 2 -> Silverlight 3

    As you can see from the chart, MY GUESS (This is not confirmed yet) is that the entire Silverlight 2 -> 3 stack will evolve accordingly with all the Microsoft development technologies.  I cannot stress how important that graph is above.  Silverlight 3 will not only get its own features, but as a first class Microsoft technology, it will benefit from the core technologies that make Silverlight what it is.

    No other RIA even comes close to providing these value add benefits that the Microsoft Development Stack does.


    Predictions of each stack item and educated guesses on improvements for Silverlight (These are my educated guesses):

    • .NET 4.0
      • Prediction: Silverlight 3 will run on .NET 4.0 (The rest of these obviously snowball on each other. .NET -> Languages -> Visual Studio -> Tools).
      • Prediction: Silverlight 3 automatically will get an update (even though it's a subset of the full .NET framework) with all of the new changes happening to the BCL.
        • The Parallel library is now part of .NET 4.0....PLEASE let that be a part of Silverlight 3 :)  In 2009 when most workstations will be quad or six cores standard, what a huge advantage Silverlight would have if you could do abstracted parallel computing easily !??!
      • Prediction: The changes to WCF, WF, ASP.NET 4.0 should be able to be consumed by Silverlight either directly or through WCF services (more on WCF later).


    F# is now part of VS 2010 (Silverlight 3 as well?).

    • Languages
      • Prediction: C# 4.0 and VB.NET are evolving as languages and there are many new exiting changes happening with their syntax.  Silverlight 3 should retain all those benefits as well.
        • In Silverlight 2 we got all the .NET 3.5 goodness: LINQ, LINQ to XML, lambda expressions, extension methods, automatic properties, implicit typed variables, etc.  Going by that past trend, there is no reason why the new C# 4.0 features wouldn't naturally flow into Silverlight 3.
      • What we know: F# is now part of .NET 4.0 (promoted from just a "lab" language and will ship as part of VS 2010).
      • Prediction: F# for Silverlight will be HUGE.  F#'s ability to create recursive/functional statistics will be an indispensable resource for the BLL on the Silverlight 3 client.  With F# (math/functional background), we will have the ability to create very nice "lite" statistical/math/physics/game AI ON THE CLIENT rather than having to resort to services sending us the result.
        • There are several "hacks" already to get Silverlight 2 working with the F# add-on, so I don't think this is pretty easily going to happen.  Bill Reiss has a good article about how you can do this already.
        • For example, for Business Intelligence applications, creating more complex statistical algorithms will become much easier with F#.  Imagine being able to offload this processing in parallel on the client and not having to rely on high latency services.  Now we are talking real-time BI and delivering the insight visually with Silverlight animations, charts, graphs, etc.
      • Prediction: F# is going to be the Python/Dynamic Languages language of choice for non-MS developers moving to Silverlight 3 (he same way C# was that first class language for Java/C++ developers).
      • Prediction: F# is all about creating immutable types for concurrent programming.  It is a nice paradigm shift that will make creating complex business processes ready for parallel processing easier than using non-functional languages.  Especially for Business Intelligence applications, F# can be a game changer in how quickly you can design financial/statistcal algorithms and apply them to data sets on the client (in parallel).
        • If you are reading and nay-saying this, then you have no concept of statistcal based programming and how hard that is do in C#.  Isn't Silverlight too slow to do this?  Your Excel runs on the client and, with the same processes, is able to do very powerful Excel spreadsheets, right?  How do you think Microsoft will implement some of the statistical functions on their Office Web - Excel?  Hint Hint ;) There is absolutely no reason why Silverlight 3 won't be able to come close to Excel's performance.
    • Visual Studio 2010 & Silverlight 3
      • Prediction (obvious): Silverlight 3 will be part of VS 2010.
        • VS 2008 was released before Silverlight 2, so the Silverlight 2 SDK/Tools is an add-on for VS 2008.  Hopefully, VS 2010 changes this and makes Silverlight projects/templates a first class citizen in VS 2010 (no add-on required).
      • Prediction (very obvious): VS 2010 will obviously evolve as a developer tool.  Silverlight 3 benefits intrinsically through this evolution.
      • Prediction: VS 2010 & Silverlight have much closer ties with SDLCprocesses.  The enhancements to Team Server, Unit Testing, Agile Processes, QA functional testing all should flow into the tool and Silverlight 3 should benefit from all of these changes.
        • Silverlight 2 of course has some of these frameworks.  Unfortunately, they don't have native support in the VS Tools.  I am hoping this changes in VS 2010.
        • Continuing the ball rolling....obviusly, it would make sense that the Silverlight 3 SDk/Tools are going to be made available for VS 2010.
    • Expression Blend 3 (Design 3?)
      • Prediction:  Blend 3 becomes a FIRST class design client for Silverlight 3.  I mentioned this already in Part 1 of the series as an announced item.  However, one thing I do want to stress is that my source of the information mentioned Microsoft's big investment in Blend.  This should bode well for a monster release in Blend 3, making it a first class tool for Silverlight 3 designers and developers.
      • Prediction:  Blend 3 integrates WPF, Silverlight and Surface XAML better including other tools like Illustrator.  If Silverlight 3 includes new controls, XAML enhancements, better integration with WPF, it is pretty safe to assume that Blend 3 will work with VS 2010 projects natively.  I am not sure that Microsoft would create features for Silverlight 2 backwards compatibility (other than importing/exporting Silverlight 2 assets).
    • Silverlight for Mobile Devices
      • Prediction:  Silverlight for Mobile Devices will be launched as part of Silverlight 3.  In Part 1 of the series, I linked to a video from the PDC about Silverlight for mobile devices entitled: Microsoft Silverlight 2 for Mobile devices.  In this video, you will note something interesting that it was being stated as Silverlight 2 would be the version for mobile devices. 
        • In my opinion, this will change in favor of Silverlight 3.  As most of you know, the PDC took place at the end of October 2008 (right around the release of Silverlight 2 RTW).  I don't think Microsoft wanted to "muddy the waters" with introducing Silverlight 3 as they were heavily pitching Silverlight 2 as the next big thing.
        • We will probably have some emulator support for Silverlight 3 and VS 2010 and it will have its own set of guidelines.
      • Prediction:  Silverlight for Mobile Devices will be launched on Windows Mobile (duh), Symbian AND Blackberry OS.
        • About the Blackberry OS:  RIM is feeling the pressure from Apple's iPhone (I own one).  Apple is stupidly locking down development (They just recently lifted the NDA) and won't let Flash on there (afraid of Flash becoming an EASIER programming platform??).  RIM already includes Office Lite support (Excel, Word, Outlook, etc.) on their phones so they have a good relationship with MS.  Silverlight on RIM based phones would be huge and further cement my belief that Silverlight is going to the leading business RIA. 
          • Prediction:  Silverlight as a mobile programming runtime not just web glitz.  If RIM opens up to a Silverlight runtime on their phone, they'll catch up to Apple real quick.  That's what bothers me about some of these executives that make these grandiose promises with no clue as how the real world operates.  Do I want to learn ANOTHER platform to program for the Blackberry?  Why does RIM want to get into the app development business?  Open your platform up to Silverlight.  Let fit clients on there.  The amount of applications will EXPLODE as you are now making your platform available to millions of .NET developers.
    Relevant Dates - March 2009 & Q3 2009
    • March 2009 - Silverlight 3 CTP
      • Visual Studio 2010 CTP has been released over a month ago; however, IT DOES NOT include any of the predictions I mentioned above. Note, it's also about to expire on 1/1/2009 and I don't think that Microsoft is about to update the VPC.
      • The next Visual Studio 2010 CTP has been slated for March 2009.
      • For those that have been following Silverlight development, March is the time Silverlight developers get "their" conference.
        • Mixx 2007 - Silverlight 1.0 Beta and Silverlight 1.1 Alpha (Silverlight 2) were announced
        • Mixx 2008 - Silverlight 2.0 Beta 1 announced
        • Mixx 2009 - Silverlight 3.0 Beta 1, Silverlight for Mobile Devices announced (?)
    • Fall 2009 - Silverlight 3 RTW
      • It makes sense for Silverlight 3 RTW to be released in Q3 2009.  This would follow a similar timeframe [Silverlight 2 Beta 1 (March) -> Silverlight 2 RTW (October)] of Silverlight 2.
        • Some might argue that Silverlight 2 (Alpha 1.1) was released in March 2007.  That is true; however, Microsoft had a lot more to do to staff up these projects and essentially start from scratch.  I think that time was spent more on design/architecture rather than development and Silverlight 3 should have a much smaller release cycle.

    March 2009: Around the Mixx 2009 conference, we should have a new Visual Studio 2010 CTP with Silverlight 3 compatibility and a go-live license (at least I hope).  Q3 2009 should see the release of Silverlight 3.  This would follow the same development timeframe Silverlight 2 took.


    Hopefully in this article you learned about some of the possible changes that are coming to Silverlight 3 development.  This no doubt will evolve Silverlight into a more mature platform that can take more advantage of advanced .NET framework features, enjoy further integration with ASP.NET/WCF/WF, leverage language enhacements (and new languages F#) and use the new Expression suite design tools.

    kick it on
    Posted: Dec 12 2008, 15:09 by Bart Czernicki | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Filed under: Silverlight | Silverlight 3
    Social Bookmarks: E-mail | Kick it! | DZone it! |

    Silverlight 3 - What we Know So Far & What We Can Predict (Part 1 of 2)

    Silverlight 2 has been released a couple of months ago and just like any MS product, Microsoft has already been working on the next release :)  Silverlight 3 is going to build on top of the Silverlight 2 runtime and add a lot of exciting enhancements.  However, it also needs to improve on a lot of the existing shortfalls when compared to the current leading RIA technology (Flash/Flex).  So what do we know is coming in Silverlight 3?

    Announced Enhancements

    • Silverlight for Mobile Devices
    • Enhanced Business Application Development
      • New dataSource control, new data controls (paging, data form, etc.), validation, back button support in browser, security/login, etc.
    • H.264 Support
    • 3D Support & Hardware Acceleration
    • Visual Studio Design Time Enhacements
    • Expression Blend 3.x for SL 3 & Enhacements
    • Fit Client
    • More Controls
    Announced Enhancements

    Silverlight for Mobile Devices

    • What is it? Silverlight on the Mobile devices!  What is really cool is that there will be no required changes to your existing SL code for it to work on the mobile device...really nice!  So it has a one up on Flash where there is no "lite" version.
    • Source of info: PDC 2008 - Microsoft Silverlight 2 for Mobile Devices 
    • Questions: 
      • What devices will be supported?  Obviously, Windows Mobile will be supported.  Symbian and Blackberry are probably other OS candidates that will include Silverlight mobile support.  iPhone....if it's not getting Flash, no way is it going to get Silverlight :) 
      • Even though it is stated as Silverlight 2, I doubt that will remain.  I think the version for mobile will match Silverlight 3 (This actually gives developers motivation to go to SL3) and this allows Microsoft to create tooling support/emulators.  This would be harder for the existing Blend/Design/VS/Silerlight 2 Tools.  What's more likely is this being added for Silverlight 3.
      • There are some minor things like video brush that will not be available in Silverlight Mobile. However, the question is, what else "minor" will be missing?

    Silverlight on a mobile device!

    Enhanced Business Application Development

    New data paging, data form, validation...

    Forms Authentication with ASP.NET

    • What is it? Silverlight 3 will include a business framework for creating rich LOB applications.  This will make creating/maintaining LOB really easy (less plumbing and focusing on design) 
    • The framework includes:
      • Data Source support for busines objects (ASP.NET)
        • Paging for the data source
        • Data Source events (on load data, etc.)
        • Data form control
      • Back button support for the browser
      • Validation of business objects
        • Custom validation on DAL automatically transferred to the UI stack (client side)
        • Attribute based validation
      • Security
        • Forms authentication
        • New authentication control
      • Watch the video below for more demos.
    • Source of info: PDC 2008 - Microsoft Silverlight Futures 

    H.264 Support

    3D Support and Hardware Acceleration

    • What is it?  Everyone assumes this: Well, I don't do 3D so I will not use this.  Wrong.  If you have written any controls that are spacial (i.e., Carousel), you will love the 3D support (Controls like the carousel will be a snap to write).   Hardware acceleration will also be huge as you can offload a lot the graphics rendering to the GPU (which will improve performance of the CPU as it doesn't have to spend cycles rendering stuff; rather, it can focus on computations/processes).  Check this video out:  What Flash 10 can do with 3D acceleration...very cool.
    • Source of info: Scott Guthrie's Blog
    • Outstanding Questions:  What kind of 3D API will this include? How extendible will the API be?  Lots of exiting info will be coming here.

    Visual Studio Design Time Enhacements

    • What is it?  Visual Studio will actually aid in the design part of building Silverlight 2 applications.  Visual Studio 2008 (granted, it was added before SL2 came out) has terrible design support and even the most basic changes require the designer/developer jumping to Blend 2 SP1. 
    • Source of info: Scott Guthrie's Blog
    • Outstanding Questions: Which version of Visual Studio will it support?  I have a suspicion it will most likely be Visual Studio 2010 and 2008 will not be changed for SL 3 (More on that on the bottom.)

    Expression Blend 3.x for SL 3 & Enhacements

    • What is it?  Expression Blend 2 was updated with SP1 for SL2 support.  There is NO doubt Microsoft will release an updated version for Silverlight 3.  The video below mentions this will be a BIG release.
      • Release date of next year (video below)
      • Official intellisence support (video below)
      • Source control support (video below)
      • Design time data support (video below)
      • Possible Illustrator EPS viewing support (video below)
    • Outstanding Questions: 
      • Is it going to be Blend 2.x or Blend 3.x and how much is the upgrade going to be?  Dropping a decent amount of money for Expresssion Studio 2 and VS 2008 Pro is a lot to ask for a re-investment per year.  Best case, Blend for SL3 is released as a SP1 or a free value-add for Expression 2 customers (This is probably unlikely since the video mentions that this will be a big release, NOT an SP).  The likely case is that there will be a discount moving from Epression 2 -> 3 and that Blend will be a standalone 3.x release.
      • The obvious big question is, what are the BIG release items that will be out with this release?

    Fit Client

    • What is it?  Abobe Flash/Flex has a product called AIR. which allows you to run your Flash/Flex applications on the client workstation outside the browser.  Silverlight 2 can support this with some hacks.  Hopefully, Silverlight 3 supports this 100% like AIR.
    • Source of info: InsideRIA
    • Outstanding Questions:
      • What framework of .NET?  Will it be only Windows?  Will it work on Mobile devices? 

    This article was authored 12/11/2008, as updates roll in before Silverlight 3 is launched I will update this page with further information.  In part 2 of the series, I will look at some educated predictions for Silverlight 3 in addition to what has been announced.

    kick it on
    Posted: Dec 11 2008, 14:21 by Bart Czernicki | Comments (10) RSS comment feed |
    • Currently 5/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Filed under: Silverlight | Silverlight 3
    Social Bookmarks: E-mail | Kick it! | DZone it! |

    WCF 101 - Understanding Transfer Security Visually


    WCF includes a variety of security settings and design options.  One of the security options the service architect has to worry about is transfer security.  Transfer security deals with ensuring safe and secure communication between a client and service host. 

    Transfer security is very important for several reasons.  Even the best authorization and authentication service design means nothing if the messages are not secure.  Unsecure messages can lead to a variety of problems like:

    • exposing the message contents to the outside world including hackers
    • exposing other security mechanisms on how to compromise your service (authentication or authorization)
    • spoofed messages (By mimicking certain message patterns, hackers can create fake messages that can cause your service to end up corrupted.)
    • DOS attacks
    WCF Transfer Security Implementation

    WCF provides a variety of ways to secure the communication channel between the service and the client.  Using these options properly can lead to highly secure communication with a very low probability of your messages being compromised.  Conversely,  even missing a small setting in the transfer security configuration can lead to messages that can have compromised privacy or integrity.

    Generally speaking, WCF supports four different ways to secure your service transfer mechanism:

    • Transport - This secures the messages by using a secure protocol that encrypts the entire channel that the messages are flowing over.
    • Message - This secures the messages by encrypting the messages themselves.
    • Both - This method combines both Transport and Message security.  This secures the messages by encrypting the messages themselves and encrypting the channel.
    • Mixed - This method uses Transport security to protect the message contents.   However, message security is used to protect the credentials of the user.

    A developer who is not experienced with WCF might have a hard time comprehending these concepts initially.  Therefore, I decided to show at a very high level how you can understand these transfer security modes visually.

    Unsecure (None) Transfer Security

    Messages are unencrypted over a channel stack that is unsecure

    • Messages are are unencrypted and the channel is unencrypted as well.
    • Unsecure transfer security is obviously not recommended.
    • Services DO NOT have to have content you want to protect in order to provide message security.   Without properly protecting your messages, your service can be exposed to hackers and it could cause unwanted performance problems as well attacks like relay or DOS attacks can bring the entire service down.
    Message Transfer Security

    Messages are encyrpted over a channel stack that is unsecure

    • Individual messages are encrypted.
    • Message transfer adds the most overhead and latency to the WCF service (other than the Both/Mixed option)
      • Each message needs to be properly encrypted and encoded as it leaves the client or service.
      • Each message needs to verified that it was not tampered with when it is received.
    Transport Transfer Security

    Messages are unencyrpted over a channel stack that is secure (If the channel were unsecure, you could see the messages in clear text.)

    • The messages are not encrypted; however, the channel is secure through using a secure protocol.
    • The communication channel is set up intially and transport security can take advantage of hardware acceleration and thus, can be further optomized.
    • Transport security is point to point.  Since the messages themselves are not encrypted, once they go to another point, they can be potentially exposed to integrity/privacy attacks as if they were unsecure.
    Message Transfer Security (mulitple hops)

    Messages are encyrpted over an unsecure channel between the client and the service endpoint (1st hop).  Notice the messages remain encrypted between the first service and second service (2nd hop).

    • The big advantage of message security is that it provides end to end security.
      • Messages leaving intermediary services retain their security.
    • Message security is not provided by all bindings and it is considered the best practice when designing enterprise services organized in a "matrix".
    Transport Transfer Security (multiple hops)

    Messages are unencyrpted over an secure channel between the client and the service endpoint (1st hop).  Notice the messages DO NOT remain encrypted between the first service and second service (2nd hop).

    • The big disadvantage of transport security is that it is only guaranteed to be point to point.
    • Message leaving and the intermediate service are not secure (by default).
    • Messages can be secured in the 2nd hop; however, it requires additional work.

    Silverlight supports Transport level security natively out of the box with WCF configuration.  Message security is possible inside Silverlight; however, it does require additional advanced programming beyond setting simple binding/behavior settings.  However, message security is not 100% supported with all the different options like securing Messages with credentials.


    In this article, I introduced the basics of WCF transfer security design scenarios.  I decided to show the differences visually so that this concept is easier to understand for those new to WCF.

    kick it on
    Posted: Dec 10 2008, 16:27 by Bart Czernicki | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Filed under: .net | WCF
    Social Bookmarks: E-mail | Kick it! | DZone it! |

    Silverlight enabled WCF Service Template is Bad Practice

    Silverlight-enabled WCF Service  Template

    Visual Studio 2008 SP1 with the Silverlight Tools includes a new template that makes creating a WCF service that can be consumed with Silverlight very easy.  Once you you have the Silverlight Tools installed, you can use the template when adding a new item:

    Adding a WCF service based on this template does several things for us:

    • Like any other WCF Service template, this adds the refrences to all the necessary System.ServiceModel assemblies.
    • It adds a WCF endpoint based on the BasicHttpBinding (which is one of the three Silverlight supports natively); Modifies the web.config with the endpoint information.
    • Adds a class/contract baseline information to our service class.
    • The service can be consumed by a Silverlight 2 client with no other necessary configuration (excluding deployment considerations).

    Let's take a look at the code that was generated from the service template:

    namespace SilverlightApplication1.Web{[ServiceContract(Namespace = "")][AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]public class Service1{[OperationContract]public void DoWork(){// Add your operation implementation herereturn;}// Add more operations here and mark them with [OperationContract]}}

    Above what we have is a public class called Service1 with one method DoWork().  The service is decorated with an attribute called ServiceContract (ServiceContractAttribute).  This tells the client what operations can be called on the service.  Applying the ServiceContract attribute on a class (or interface) exposes the type to service consumers.  WCF works on an opt-in model and methods need to explicitly configured to be exposed in the service.  This is what the OperationContract attribute (OperationContractAttribute) is for.  You apply this attribute on any methods that you want the client to be able to call through the service.  These two attributes are all that is needed to expose a service publicly. 

    The problem with the template implementation is that it places the attributes directly on the class itself.  This obviously is a bad practice as it couples the service implementation and the class implementation together.  If you have read any architecture books/resources, this paradigm is not new to you.  Why is it bad for WCF?  When designing a WCF service, a developer needs to prepare for future use of the service and be ready for possible changes.  The more places you make changes causes the more items that could potentially break.  This could cause QA to be involved in re-testing certain parts of the program.  We obviously want to split this up so that the service design/contract (what types and what methods the service exposes) are seperated from actual implementation (what the DoWork() method does).  Another reason we want to break the contract and implementation is so that the contracts can be re-used on the client.  WCF includes a lot of gotchas especially when generating a proxy on the client.  What actually happens when you generate a proxy is that these types and the service exposed methods actually are generated on the client class inside the proxy.  You can mitigate lot of these issues by simply having the service contract types on the client. (I will cover this in another article; showing how to create an assembly that can be used both in Silverlight and .NET that shares service contracts).

    Interfaces - The real Service Contracts 

    By defintion, an interface is a contract that a class implementing has to adhere to.  Interfaces by definition fit the WCF structure very well here and we should define our service contracts (how the service will be designed) in our interface and then have our class implement this design.  You can see we are essentially factoring out the structure of our services all in our interfaces and then creating the actual implementation in our classes (how the service is going to do these operations).  In any WCF book you will read, it is stated over and over that the service/operation attributes should be placed on the interface rather than directly on the classes.

    As you can see above, the template applied these service contracts directly on the class.  This is obviously a bad practice in WCF design.  Let's re-work the template above so we can create a service design that is factored outside of the implementation.  First, we can create an interface with one method DoWork() and apply the proper attributes and it will look like this:

    using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.ServiceModel;namespace SilverlightApplication1.Web{[ServiceContract(Namespace = "")]interface IService1{[OperationContract]void DoWork();}}

    Now we can refactor our Service1 class and simply implement the interface.  Notice I removed the ServiceContract and OperationContract attributes as they are now on the interface.  (Note: The AspNetCompatibilityRequirements attribute can ONLY be applied on a class, and this attribute is really there for backwards compatibility with ASP.NET and in true WCF rarely will you see it used).

    using System;using System.Linq;using System.Runtime.Serialization;using System.ServiceModel;using System.ServiceModel.Activation;using System.Collections.Generic;using System.Text;namespace SilverlightApplication1.Web{[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]public class Service1 : IService1{public void DoWork(){// Add your operation implementation herereturn;}// Add more operations here and mark them with [OperationContract]}}

    If you had followed the steps above, the service would not work when accessed.  The service will error and say that the contract could not be found.


    When the template generated the WCF configuration, the ServiceContractAttribute was applied to on the class directly.  The service is looking for a type called Service1.  WCF and the configuration is not smart enough to know that we have an interface called IService1 and that Service1 is a class that implements that contract.  Therefore, we have to explicity give the name of the class or interface that has the ServiceContractAttribute applied to it.  In our example, this is the IService1 interface.  We simply need to change service configuration inside the web.config from this:

    <service behaviorConfiguration="SilverlightApplication1.Web.Service1Behavior" name="SilverlightApplication1.Web.Service1">

      <endpoint address="" binding="basicHttpBinding" contract="SilverlightApplication1.Web.Service1"/>

      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>


    to this:

    <service behaviorConfiguration="SilverlightApplication1.Web.Service1Behavior" name="SilverlightApplication1.Web.Service1">

      <endpoint address="" binding="basicHttpBinding" contract="SilverlightApplication1.Web.IService1"/>

      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>



    The Silverlight-enabled WCF Service Template is a nice way to get started with implementing a Silverlight-based service.  However, because the contract definitions are directly applied to the class, it should not be used as guidance on how one should lay out their WCF design.  As you saw above, it is quite easy to refactor the service design from the implementation in a couple of steps.  This allows your WCF service to follow WCF best practice guidelines.  The template is a good starting point for starting a Silverlight WCF project but only after refactoring the initial contract.  In the next article I will show how to refactor the contracts into an assembly both the service and the client (service consumer) can share.


    kick it on
    Posted: Dec 04 2008, 15:37 by Bart Czernicki | Comments (6) RSS comment feed |
    • Currently 3.666667/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Filed under: Silverlight | WCF
    Social Bookmarks: E-mail | Kick it! | DZone it! |