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.

ASP.NET MVC 3 Intranet Template with "This resource cannot be found" and User.Identity.Name is blank Error

ASP.NET MVC 3 Tools refresh recently was released and it includes a new Intranet Visual Studio project template.  This template is basically an ASP.NET MVC 3 template with Windows Authentication enabled (the Internet Application template uses forms based authentication).

I was recently playing with this template and it worked fine in development and even using the IIS 7.x Express Web Server.  However, when I deployed to a real Windows Server 2008 R2 application I saw this "The resource cannot be found" error:
So what is going on?  Notice (from the screenshot above) that we are being redirected to .../Account/Login.  This is a clue that the login/authentication is failing. The controller for login is throwing the error.  
If you explicitly actually type in /Home/About you will actually get a rendered page below.  Notice in the top right corner all you see is an exclamation point.  The @User.Identity.Name code in the _Layout.cshtml is blank/NULL and causing the error (shown below that is why you only see "Welcome !"). 
Why is Windows Authentication not working?  It looks to me that this is a bug in the ASP.NET MVC 3 Intranet template....I stumbled upon this by chance, by going through the "known issues" section in the ASP.NET MVC 3 release notes.  It mentions that we should add this line (<add key="enableSimpleMembership" value="false" />) to the web.config if we are upgrading from an ASP.NET MVC 2 application.  This has NOTHING to do BTW with Windows Authentication and I tried adding that key in web.config by chance and it properly authenticated me.
After adding the key (and restarting the application pool), ASP.NET MVC 3 properly is able to grab the identity of the user via Windows Authentication.  Basically the appsettings section of the web.config should look like this now:
    <add key="webpages:Version" value="" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
    <add key="enableSimpleMembership" value="false" />
If you receive a "This Resource Cannot be Found" error or the User.Identity.Name is blank or IsAuthenticated is false for an ASP.NET MVC application ensure:
  • Windows Authentication is turned on in web.config (IIS 6 and 7)
  • You are using the Integrated pipeline mode in the application pool (IIS 6 and 7)
  • All the wildcard mappings and ISAPI settings are properly set up (IIS 6)
  • Add the key: <add key="enableSimpleMembership" value="false" /> to the appSettings section
  • If you have Kerebos/NTLM etc authentication, make sure it is configured correctly in IIS
I hope this article helped anyone who is going through this annoying issue, as I spent several hours trying to figure it out myself.  It seems like Microsoft needs to update their ASP.NET MVC 3 Intranet template to include this line for production scenarios.
Posted: Apr 13 2011, 16:38 by Bart Czernicki | Comments (0) RSS comment feed |
  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: .net | ASP.NET MVC
Social Bookmarks: E-mail | Kick it! | DZone it! |

Maximizing your Silverlight LOB investment with Web Parts

Astract:  This article will show you how you can take advantage of the Silverlight architecture for easy deployment to web parts and easy client communication (intra web parts).  This article will amplify why Silverlight is still the technology of choice if you want to create modular functionality deployed as web parts into custom or SharePoint portals.

A few months ago Microsoft made the announcement that they are "repurposing" Silverlight from a general web technology in favor of HTML5.  They have backtracked a bit from this statement and have made statements like Silverlight has some "sweet spots" in line of business (LOB) applications.  Microsoft does a very poor job of defining these sweet spots and what they are.

Silverlight being a web browser plug-in offers some really nice deployment and integration capabilities; one of them being SharePoint and web parts.  This allows you to deploy Silverlight applications to existing custom portals, SharePoint 2003-2010 servers or other web part architectured sites with little/no additional code.  In my opinion this makes the Silverlight architecture very attrictive for intranet line of business applications.

Note: Additional details on this topic is provided in my new book "Silverlight 4 Business Intelligence", where I dedicate an entire chapter to Silverlight web parts. In the book you will see step by step instructions and code samples for the scenarios outlined below.


Silverlight as a Portable Web Part Module

Silverlight applications (XAP files) can be easily made into web part by simply surrounding the Silverlight application with a "web part wrapper".  This technique can be implemented via a ASP.NET Web Part interface, SharePoint 2003/2007 web part interface (deprecated) or the new SharePoint 2010 Silverlight Web Part.

Hosting Silverlight in web parts is as simple as "rendering" the XAP package inside the web part. 

Lets take a look an example of how to host an existing Silverlight application in a SharePoint 2010 portal using the new Silverlight web part.  SharePoint 2010 includes a new "Silverlight Web Part" which does exactly this.

SharePoint 2010 includes the "Silverlight Web Part" in the "Media and Content" section.

As long as the SharePoint 2010 server can access the URL location of the XAP file, you host the Silverlight application as a web part.  This means that SharePoint can host Silverlight content as a web part from a:

  • Remote Silverlight XAP file located on the internet
  • Document/SharePoint list URL location of the XAP file inside SharePoint
  • Another internet/intranet portal that is hosting the Silverlight application
SharePoint 2010 Silverlight Web Part requires just the Silverlight XAP file URL to render Silverlight content.
The SharePoint 2010 Silverlight Web Part also includes an additional parameter for initialization parameters passed into the Silverlight application before the content is rendered.  This is a nice feature; for example, if you want to let the Silverlight application know that it is being rendered in SharePoint to pull data from ShrePoint lists instead of portal services.
What if you want to create a Silverlight web part for SharePoint 2003/2007 or for an ASP.NET portal?  What if you want advanced features like web part communication configuration connections?  In those situations you will need to create a custom Silverlight web part wrapper or use an existing open source one.
Silverlight web parts are a VERY powerful feature that is often overlooked.  Imagine you have an existing ASP.NET MVC or ASP.NET web forms site that you want to host inside SharePoint.  This is not very easy without having already invested in a web part architecture.  However, with Silverlight hosting this content in SharePoint is trivial
Example of a full Silverlight dashboard hosted in SharePoint 2010 with NO CODE CHANGES (imagine doing this with another web technology if you didn't invest in web parts from the start; Silverlight's plug-in architecture pays dividends here)
Silverlight Web Part Communication 
Creating a single web part whether its an ASP.NET web part or Silverlight web part is fairly easy.  There is a lot of material out there to guide a developer through this.  However, web part communication gets very tricky in ASP.NET/SharePoint.  In these situations you will want an action on one web part to trigger a data refresh in the other web parts on that page.  This is where Silverlight really shines.
An example of three web parts, where an event on a single web part will update the content of the other two web parts on a page. 
In order to do this type of web part communication involves creating custom web parts with the provider and consumer interfaces explicitly defined.  Not only that, but traditional ASP.NET web parts post back and do not provide that "Ajax/web 2.0" feel.  Furthermore, when you have multiple layers of web parts (i.e. providers and consumers switching roles) then this gets very complicated with state management and the web part lifecycle.  Furthermore, interactivity (i.e. a slider moving and changing another web part contents in real-time) is not trivial as well.
Note: If you are not familiar with web part connections, look over the MSDN article that describes this.  As you can see the components involved: Web Part Manager, provider/consumer connections, web part interfaces, web part lifecycle all have to "play nice" with each other for this to work.
What advantages do Silverlight web parts provide:
  • Allows client-side, real-time communication between web parts without post backs
  • Allows communication between Silverlight and non-Silverlight web parts (using the Silverlight HTML bridge)
  • Simplifies the design/coding of the web parts by NOT having to implement web part interfaces, worrying about lifecycle management, which part is a provider consumer (you can of course do this if you want)
Silverlight web parts allow you to create very modular pieces of functionality inside Silverlight.  However, it also allows the SharePoint admin to expose the pieces of functionality that is interesting from the complete Silverlight application very easily in SharePoint with NO/LITTLE code changes.  Imagine if you have a great Silverlight application with MEF that composes the application in real-time.  You can leverage that composable and dynamic architecture into creating a modular SharePoint gallery that allows Silverlight web parts to communicate with each other based on what the portal admin or power user decide to place on the portal canvas.
How does Silverlight Web Part Communication Work? 
Silverlight web part communication has nothing to do with the web part framework provided in ASP.NET nor SharePoint!  It is actually natively provided with the Silverlight framework using the local communication APIs.   This means that if you have two Silverlight applications that utilize Silverlight messaging can be deployed a seperate web parts.  Furthermore, they can communicate between each other WITHOUT having to write additional web part framework code around providers/consumers/web part managers etc.
The primary mechanism for this is the LocalMessageSender and the LocalMessageReceiver classes.  For example, from the API documentation this all the code that is required to set up communication between two Silverlight applications:
// In the receiving application:
LocalMessageReceiver messageReceiver = new LocalMessageReceiver("receiver");
messageReceiver.MessageReceived += new EventHandler<MessageReceivedEventArgs>(receiver_MessageReceived);
catch (ListenFailedException)
{MessageBox.Show("Cannot receive messages." + Environment.NewLine +"There is already a receiver with the name 'receiver'.","LocalMessageReceiver", MessageBoxButton.OK);}
// In the sending application:
LocalMessageSender messageSender = new LocalMessageSender("receiver");messageSender.SendCompleted += new  
In my book, I provide an example of two Silverlight web parts that can communicate between each other in SharePoint.
Note:  If you want Silverlight web parts to communicate with non-Silverlight web parts, this can be done easily using the HTML bridge.  For example, if a user clicked a Silverlight button this could trigger a post back and via the web part framework send the proper message via the agreed provider/consumer interface.  The part that is tricky is maintaining state between web parts and losing some of the client-side/non-flicker web part messaging.
Summary and Takeaways
This article hopefully showed you some of the advantages that Silverlight posseses when using web parts. Some of the key takeaways should be:
  • It is really easy to deploy a Silverlight application as a web part by simply "hosting it" in an ASP.NET web part.  This allows Silverlight applications to be deployed into custom ASP.NET portals or SharePoint 2003-2010 portals with no or minimal code changes.
  • SharePoint 2010 includes a new Silverlight Web Part that allows you to host local, remote or any Silverlight applications that are URL addressable.  Therefore, deploying a Silverlight application to SharePoint 2010 usually requires no additional code.
  • Web Part communication (which is not trivial to implement in advances scenarios) simply works without code changes inside Silverlight web parts using the local communication APIS.
  • Web Part communication within two Silverlight web parts happens on the client-side.  This provides real-time communication between two web parts without server postbacks nor page refreshes.  Silverlight web parts allow for many interactive scenarios that make UIs feel non-obsolete.
  • Advanced MEF scenarios can enable distributing Silverlight as seperate functional modules that can be deployed into portals dynamically.  This allows you to "break up" a larger Silverlight application into seperate Silverlight web parts that expose particular pieces of functionality.
If you want more details, excercises or code samples on this subject I dedicate an entire chapter to this topic in my book "Silverlight 4 Business Intelligence".
Posted: Jan 22 2011, 10:05 by Bart Czernicki | Comments (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: .net | Silverlight
Social Bookmarks: E-mail | Kick it! | DZone it! |

Are you ready to learn F#? Concepts to be familiar with before learning the F# language

I have been learning, absorbing and playing with F# for several months now.  I worked primarily with C# since 2002.  I figured I would write some .NET and developer concepts that one should be familiar with before trying to learn F#.  Hopefully, the list compiled below will help you determine if you are ready to learn F#.  If you are not familiar with most or any of these items below, it doesn't mean you can't learn (or shouldn't learn) F#.  However, in my opinion, the more you know from the items listed below, the easier it will be to learn the language.

Background Information

F# is a new functional programming language (from Microsoft) that is being released with .NET 4.0 and Visual Studio 2010 in March 2010.  The language is a "first-class" language and is completely integrated with the entire .NET ecosystem (debugger, tools, framework, support) like C#, C++.NET and VB.NET.  Therefore, F# is not like Delphi.NET, COBOL.NET or other third-rate .NET languages.  Functional languages are based on mathematics and this makes them ideal for statistical, financial operations on large data sets.  F# is a unique .NET language that will have many uses in the near future.

Programming Concepts

This is a list of programming concepts you should be familiar with before learning F# (Note: I ommited a lot of beginner programming concepts). You will see a lot of these concepts/patterns used in F# programs and examples.

  1. Data Structures - You should have a good understanding of the differences between a linked list, array, hash set, etc.  F# natively uses certain data structures (in underlying types) and knowing the differences between them will aid you when writing programs.  If you need a refresher, check out this FREE PDF book Data Structures and Algorithms Book.
  2. Big Oh Notation - You have to be able to understand the performance implications of your algorithms.  This is especially true for functional programming languages like F#.  If you do not know the difference between O(1) or O(n), you need to refresh your memory.  This is important when writing functional (non-imperative) style programs when doing many operations on a sequence or list of types.
  3. Type Inference - By default,  the F# compiler uses type inference to determine what types a function uses.  C# has partial type inference using the var keyword.  However, in C#, you still need to pass in the type explicitly for method signatures.  Being used to not seeing these "type aids" will help you understand F# syntax faster.
  4. Immutability -  In object-based languages such as C#, C++ or VB.NET the created objects are mutable.  This means that their state can be changed.  Functional programming languages are by default immutable and do not allow the state of the value/variable to change after it has been assigned a value.  For more information on immutability go here.
  5. Recursion - Recursion is the ability of a piece of code to call itself over and over until the desired result has been completed.  In C#, methods can be recursive.  In SQL (SQL 2005), a developer can use CTEs (common table expressions) to recursively iterate through the same algorithms.  This pattern is very popular in functional programming and whatever F# book you pick up, this will be one of the first chapters you read.  If you are familiar with the more advanced topic of recursion like "tail recursion," that will be really beneficial as well.  For more information on recursion, click here.
  6. Closures - Closures are a more advanced topic that most developers use every day without even knowing it.  Closures allow you to use constructs that are declared outside of the scope of the function as if they were part of the local scope.  I recommend Jon Skeet's book to fully understand them.  A link to an article on his website can be found here.
  7. Currying -Function/method currying is the process of creating new functions/methods from existing functions/methods and their parameters.  You will see function currying in a lot of F# examples as it makes code simpler and easier to read.  For more information on currying, click here.
  8. Iterator pattern - I think this is one of the more important design patterns.  For example, as a .NET developer, you should know the difference between a List type and an IEnumerable and how to use the yield keyword to implement the iterator pattern in C# (In F#, an iterator is implemented in a sequence).  As mentioned above, functional programming languages are designed to work with lots of data.  Therefore, optimizing data structure access is essential to create performant F# modules.  For a great article on the iterator pattern, please look at Juwal Lowy's MSDN article.
  9. Asynchronous Programming - Since F# is by default immutable and tries to get the developer to program without side effects, this makes it great for asynchronous programming.  The reason is that by definition, all constructs should be thread-safe since their state cannot change.  Knowing about async programming helps, but it does not mean you can't do synchronous F# programs.
  10. Writing Clean Code - In my opinion, this is probably the most important one of all.  When writing C# code, you have curly brackets and semicolons to aid you in laying out your code and determining scope.  However, in F#, the way you lay out code matters!  This means whitespace and bad code formatting could create unwanted bugs.  The reason I mention this as important is that this could be a hard habit to break.  For example, learning about closures could take a very small amount of time compared to breaking a bad habit in formatting your code.
  11. Other functional languages - This is an obvious one. If you have experience with other functional languages such as Haskell or OCaml, you will obviously feel right at home with F#.

.NET/C# Concepts that Translate to F#

This is a list of .NET/C# concepts that translate well into F# and will help you understand functional programming more easily.

  1. LINQ/SQL - If you have used LINQ or SQL, this will dramatically help you understand how to write functional algorithms.  LINQ/SQL favor declerative (opposed to imperative) syntax like F#.
  2. Lambda Syntax - If you are familiar with lambda syntax in C#, you will see a very similar lambda syntax in F#.
  3. Extension Methods - This could be associated with knowing LINQ but it is worth mentioning here as extension methods are essential in "fluent" code.
  4. Generics - Generics were introduced to the .NET framework to aid in code reuse.  In the same manner that you can write a generic method in C#, you can write a generic function in F#.
  5. Delegates and Simplified Delegate Syntax - If you have used delegates as parameters or to pass pieces of code around, then the functional composition concept will be familiar to you in F#.  You can read my Evoloution of C# Delegate Syntax article to understand how delegates allow you to write code in a more functional paradigm using C#.
  6. Parallel Task Library/PLINQ - Writing algorithms that can take advantage of many cores should not be hard.  This is exactly what the Parallel Task Library/PLINQ allows you to do in .NET 4.0 in a simpler, functional way.  These concepts are closely aligned to F# asynchronous workflows which allow concurrency (even in Silverlight!!)
  7. var Keyword (type inference) - Being familiar with the var keyword in C# will get you familiar with type inference in F# faster.  Most F# examples make use of this feature and declare types explicitly only when needed.


If you read reviews of available F# books, some are negative - in my opinion, unfairly - because the developers expect to be taught everything.  There are a lot of core concepts listed above that a single F# resource simply cannot cover.   Understand when purchasing F# resources, you are expected to know a decent amount of these developer topics.  I hope this list aids you in the way you approach learning F# either by jumping into F# directly or by brushing up on some intermediate/advanced programming concepts.

Getting started with F#

Information on F# has been around for several years.  There are many articles, white papers and books on F#.  However, you do have to be careful and get content that is recent and relative to the current F# release.  The F# specification has changed dramatically over the last several months as the language was being "productized" and many methods/functions simply don't exist in F# anymore.   Below are some links I put together where to get started.


  • Getting Started with F# - This video (from the 2008 PDC) is the place to start if you have zero F# experience and/or if you want a really good introduction into functional programming and some F# examples.

Books (I have read four different F# books and the two below are by far the best ones and most current.  Don Syme's F# book is good but a little outdated.)


  • This the main Microsoft F# page.  Includes numerous links, downloads for Visual Studio, F# extensions, etc.
  • Don Syme's blog - Don Syme is one of the main "creators" of F#.  His blog is a must read to get insight into advanced topics and upcoming F# news.


kick it on
Posted: Dec 06 2009, 12:29 by Bart Czernicki | Comments (3) RSS comment feed |
  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: .net | F#
Social Bookmarks: E-mail | Kick it! | DZone it! |

Silverlight 3 Relase Download Links and Installation Instructions

Silverlight 3 has been released here are some of the released links:

Silverlight 3 Runtime
Blend 3 with Sketchflow
VS 2008 Tools
.NET RIA Services (July 2009)
Silverlight Control Toolkit (July 2009)
Change list of the Silverlight Control Toolkit:
DeepZoom Composer
Seven Additional Navigation Themes

Still waiting on these:

  • Bing Enterprise Map Control for Silverlight (currently in CTP)
  • ADO.NET Data Services (currently 1.5 CTP)
  • Prism Update (saw some blog post MVVM templates they were adding to the framework)
  • Visual Studio 2010 Beta 1/2 tools for Silverlight 3 RTW
  • Other (Silverlight Mobile maybe (?), XBOX Developer Add-Ons etc.)

Installation notes for developers:

  • You need to uninstall EVERYTHING Silverlight developer related to get it to work: Silverligh 3 SDK, Visual Studio 2008 Tools, Blend 3 Beta.  Otherwise you will get a message saying your developer tools are out of date.
  • Silverlight Control Toolkit March 2009 will not work with Silverlight 3 RTM
  • Expression Blend 3 is NOT RTM it is apparently RC (Update: the version out now is RC, which will work with Silverlight 3 RTM.  Expression Studio 3 RTM is shipping within the next 30 days.)
  • When you upgrade your projects from Silverlight 2/3 Beta to Silverlight 3 RTM make sure you have the correct assemblies referenced!  Note some controls have moved from the SDK to the Control Toolkit and vice versa.

Installation Order (if you have Visual Studio 2008 SP1)

  1. VS 2008 Silverlight Tools (installs the runtime, SDK as well)
  2. Expression Blend 3 Trial
  3. .NET RIA Services
  4. Silverlight Control Toolkit

Installation notes for casual users:

  • Your users will automatically be upgraded to Silverlight 3 (if they have the auto update selected, which is the default).They can always upgrade manually.
  • If you are developing a product on Silverlight 2, you should turn off automatic updates of the runtime...just in case.
kick it on
Posted: Jul 09 2009, 08:38 by Bart Czernicki | Comments (1) RSS comment feed |
  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: .net | Silverlight 3
Social Bookmarks: E-mail | Kick it! | DZone it! |