Microsoft yesterday announced a new product, called LightSwitch, which is a new Visual Studio-based IDE to rapidly develop applications. You can see a very impressive demonstration here:

http://channel9.msdn.com/posts/Dan/Jay-Schmelzer-Introducing-Visual-Studio-LightSwitch/

Looks like there's some very nice controls (for handling phone numbers etc.) in there, hopefully they will be made available outside of that product.

What is particularly interesting about this is that they are producing a Windows application, which is not using WPF. They have chosen to use Silverlight  running out of browser. This is bad for WPF, because that is what you would expect to be used on the Windows platform.  It suggests that over time WPF will be replaced by Silverlight, even on Windows.

So why have they chosen Silverlight? I guess there is some advantages in allowing organizations to be able  run the application on the web.  Hopefully, the reason for that decision will become clearer over time.

What I would've done is built the two desktop targets using WPF. However, what the Microsoft development team would've found is that it's almost impossible to share xaml code between WPF and Silverlight, so they would quickly given up and gone the Silverlight only route.

Hopefully Microsoft can improve the developer experience when single sourcing WPF and Silverlight, but there's still a long way to go.

….Stefan

As many people have already discovered Microsoft made a change in the.net framework resulting in the quality of bitmap scaling being reduced by default.  This is because the default mode is now low quality, rather than high-quality.  Optionally you can go back to the way it was previously, but this requires you to turn this feature on. 

It is very disappointing that Microsoft have chosen to break backwards compatibility in this way. Apparently it was to help some customers to were experiencing slow image scaling. Why they were not just told to set the default to low quality image scaling, rather than forcing everyone in this mode is beyond me! In another similar situation they specifically didn't change the default font scaling mode, designed to increase text quality because it would break existing applications. Why they did not apply the same theory to this feature is confusing at the least.

Details of the changes are here:.

Crappy Image Resizing in WPF? Try RenderOptions.BitmapScalingMode

I have found the best way to ensure that this feature used throughout a program is to set the default scaling mode in the window constructor:

public MainWindow()
{
    InitializeComponent();

    RenderOptions.SetBitmapScalingMode(this, BitmapScalingMode.);
}

However, this does not deal with a situation where you need to use RenderTargetBitmap, for which this setting does not apply.  You might use RenderTargetBitmap in a situation where you want to resize an image, something like this:

RenderTargetBitmap result = new RenderTargetBitmap(newWidth, newHeight, 96, 96, PixelFormats.Default);

DrawingVisual vis = new DrawingVisual();
using (DrawingContext dc = vis.RenderOpen())
    dc.DrawImage(Image, new Rect(0, 0, newWidth, newHeight));

result.Render(vis);

So obviously you would probably try and do this:

RenderOptions.SetBitmapScalingMode(vis, BitmapScalingMode.HighQuality);

Which would do nothing.  Unfortunately, Microsoft's support of this particular problem has been extremely poor with no responses in newsgroups or in comments on blogs. I e-mailed Pete Brown, and received no response.

As it turns out, thankfully there is a workaround. You just need to recode,using a DrawingGroup (I found the solution here: http://xiu.shoeke.com/2010/07/15/resizing-images-with-wpf-4-0/) and set the attached property on the DrawingGroup. e.g:

RenderTargetBitmap result = new RenderTargetBitmap(newWidth, newHeight, 96, 96, PixelFormats.Default);

var group = new DrawingGroup();  

RenderOptions.SetBitmapScalingMode(group, BitmapScalingMode.HighQuality);
group.Children.Add(new ImageDrawing(Image, new Rect(0, 0, newWidth, newHeight)));  

DrawingVisual vis = new DrawingVisual();
using (var drawingContext = vis.RenderOpen())  
    drawingContext.DrawDrawing(group);  

result.Render(vis);

Which does result in a large amount of additional unnecessary code, but at least it is still possible for your application to work in WPF 4!

….Stefan

Update 29/June/2010: Colin Eberhardt who originally developed this technique has posted an update, including these changes: http://www.scottlogic.co.uk/blog/colin/2010/05/silverlight-multibinding-solution-for-silverlight-4/

The Silverlight multi-binding functionality that I have described previously (see here) doesn't work in Silverlight 4, due to the changes in the xaml parser. This code:

<local:MultiBinding TargetProperty="Text" Converter="{StaticResource TitleConverter}">
    <Binding Path="Surname"/>                            
    <Binding Path="Forename"/>
</local:MultiBinding>

Gives this exception:

System.Windows.Markup.XamlParseException: Set property 'SLMultiBinding.MultiBinding.Bindings' threw an exception

the solution is to wrap the bindings in a binding collection, e.g:

<local:MultiBinding TargetProperty="Text" Converter="{StaticResource TitleConverter}">
    <local:BindingCollection>
        <Binding Path="Surname"/>                            
        <Binding Path="Forename"/>
    </local:BindingCollection>
</local:MultiBinding>

 

As I did after the Silverlight 2 & 3 releases, I thought it would be a good idea to review the bugs that I have submitted, to see what progress is.

If you haven't already downloaded the Silverlight 4 beta, you can get all the information you need about this release from Tim Heuer's blog: http://timheuer.com/blog/archive/2009/11/18/whats-new-in-silverlight-4-complete-guide-new-features.aspx

Thankfully bug fixing progress is much better than I expected this time. Five bugs are fixed, although there are still three fairly basic bugs that have not been fixed. These issues are in situations where you would expect things to work - they do work correctly WPF but don't work in Silverlight.  In some cases, I suspect that this is because of the internal structures in Silverlight - hopefully these will be resolved soon!

Fixed:

#377171 Using a path style from app.xaml fails the second time in Silverlight

#428412 Linked files in folders are not output correctly in SL 3

#459475 ImageBrush ImageSource binding parsing error

#460375 Silverlight doesn't work correctly with multiple resource dictionaries

#462271 Binding to Items.Count doesn't work

Not Fixed:

#373116 ToolTip causes ArgumentException

#373957 Value does not fall within the expected range assigning PointCollection in Silverlight

#425334 Binding to ActualWidth ignores changes in Silverlight

#473411 Set Uri as "" in xaml not consistent with WPF

#475639 Silverlight should support nullable dependency properties

#482404 XamlParseException when setting values on a converter

#511396 Binding parser inconsistent between WPF and Silverlight (filed this week)

Not going to fix:

#469091 Referencing an image in a custom control which is a RootVisual will not load the image

New issues in Silverlight 4:

#511958 Hyperlink should be able to be inserted in a textblock

#512043 The runtime has encountered a fatal error - SL4

Update 31/July/10: Having had problems with .net reactor not correctly working with my WPF application, I have evaluated and chosen CodeFort as my obfuscation tool. A review will follow at some stage, but it supports obfuscating Baml and xaml on WPF and Silverlight and is very affordable ($199US), I would highly recommend it!  Their support has been outstanding!

Update 10/Nov/9: .net reactor can now directly work with xap files

Update 2/Nov/9: .net reactor now has no problems with control flow obfuscation, and as a result it is now my recommended product (see updated conclusion).

Update 24/Oct/9: DeepSea obfuscator now has anti-disassembly support, and have updated the review to reflect that it can open xap files directly.  Please note however that the current DeepSea as obfuscator build (2.1.6.120) causes exceptions with my project which requires me to exclude one assembly from removing unused delegates.

As I have expressed in a previous post I had struggled to find an affordable obfuscator that worked for Silverlight.  When it came time to submit my entry for the ComponentArt Silverlight coding competition (http://www.componentart.com/community/competition2009/details.aspx?id=1109), I wanted to ensure that the code was obfuscated before uploading it so that my hard work is not stolen. Unfortunately, the vision I had of .net reactor 4 beta didn't in fact work with my project.

So I set out on a very quick evaluation of the available obfuscators. This review describes my experiences with three products:

• .net reactor 4.1.0 (final release) - $179US
• DeepSea Obfuscator 2009 2.1.6.120 - $299US
• {smartassembly} 4.1.39 Professional Edition - $699US

Not evaluated:

• Spices.Net 5.6.6.0 - $699. At the time I started the evaluation they hadn't released a new version since Silverlight 3 was shipped and it is not clear what their Silverlight support was like
• Dotfuscator for .NET - ~$2000US. Too expensive.
• Crypto obfuscator - Enterprise edition $399US.  Wasn't aware of it when I started this review.
• Eazfuscator.NET – Free. Needs to be added into the Visual Studio build process and looks too complicated.
• If there are others I've missed, please let me know.

If you are developing a WPF application, please be aware that the findings may be completely different. WPF applications can include native code to make the obfuscation more effective, is not possible in Silverlight.

What is an obfuscator?

From Wikipedia: (http://en.wikipedia.org/wiki/Obfuscator)

“Obfuscated code is source or machine code that has been made difficult to understand. Programmers may deliberately obfuscate code to conceal its purpose (a form of security through obscurity), to deter reverse engineering, or as a puzzle or recreational challenge for readers. Programs known as obfuscators transform human-readable code into obfuscated code using various techniques.

Obfuscating code to prevent reverse engineering is typically done to manage risks that stem from unauthorized access to source code. These risks include loss of intellectual property, ease of probing for application vulnerabilities and loss of revenue that can result when applications are reverse engineered, modified to circumvent metering or usage control and then recompiled. Obfuscating code is, therefore, also a compensating control to manage these risks. The risk is greater in computing environments such as Java and Microsoft's .NET which take advantage of just-in-time compilation technology that allow developers to deploy an application as intermediate code rather than code which has been compiled into machine language before being deployed.”

Types of Obfuscation

Below is a list of the things that you might want a Silverlight obfuscator to be able to do.

Name Obfuscation

This involves changing the name of the type/function/property etc… so that it cannot be understood e.g:

From:

To:

Control flow obfuscation

This involves making it difficult to understand the flow of your function. E.g:

From:

To:

Even better is when the obfuscation is so complicated that .net reflector can't do anything with it at all. Currently the only reviewed product that can do this is {smartassembly}:

 

Eually as good is what .net reactor can do, which ensures that it can't even be viewed in reflector:

Merging

One of the great features of obfuscators when working with Windows Forms is the fact that they can merge multiple assemblies into a single assembly, and therefore make all public classes internal, and as a result these classes can then have their names obfuscated. Unfortunately this is not possible with WPF because the compiled xaml, called Baml, is not a publicly documented file format and changing class names would break the Baml.

In Silverlight the xaml files are compiled directly and unchanged into the executable as resources. This means a decent obfuscator should be able to appropriately change the names of classes referenced in the xaml files and merge assemblies into one. Unfortunately, no obfuscator that I'm aware of is doing that at this point.

However, what can be done is that any data access layer classes with no xaml could be merged and made internal. None of the tools tested currently have that feature working, although I expect this to be working in DeepSea obfuscator very soon - it can build it this way, but it is currently causing exceptions at runtime. In .net reflector it looks like this:

Xaml obfuscation

None of the tools make any effort to change xaml files. This makes it very easy for anyone to take any of your xaml code and reuse it.

They don’t even make the simple effort to obfuscate the names of event handlers and change the reference in the xaml.

Anti-Disassembly

It's worth looking for an obfuscator that can make it impossible for people to look at in .net reflector. What happens here is that some changes are made to the metadata so that .net reflector cannot handle it - so it won't load your assembly, which makes it more difficult for people to look inside your code.

String Encryption

All the obfuscators can encrypt your strings so that people can search through your executable to find where your code is based on strings.

General Silverlight obfuscator issues

Files

One problem with most Silverlight obfuscators is that you have to work with the files outside of the xap file.  Admittedly, this is not too hard because you just work with the files on the release folder, but then you then have to manually copy them into the xap file. It would be preferable to have an automated process that can work directly on the xap file.

Currently DeepSea obfuscator and .net reactor allows you to directly open and work with xap files.

One alternative to this is that some of the tools describe how to add their obfuscation process into the Visual Studio build process. Unfortunately, this requires some manual work on the project file, which puts me off doing that.

Tips for obfuscating

Make every class you possibly can internal.

This allows the obfuscator to be more aggressive and make it more difficult for people to understand your code because the class names can often be changed. An exception to the class name being changed is when you make a class with an associated xaml file internal. However, .net reactor and DeepSea are able to then hide the InitializeComponent function more effectively. To make a class with a xaml file internal you need to add x:ClassModifier="internal" in the Xaml and make it internal in the .cs file

 

.net reactor

.net reactor is very easy to use. Simply select your main assembly, and then any other related assemblies that you wish to obfuscate:

Then you should select the type of obfuscation you require from the protection presets menu:

You can edit settings in a more detailed fashion via the settings tab:

in the latest version .net reactor protects the virtual tour viewer project perfectly.

Merging does not work at all, it crashes .net reactor when trying to build your project.

Here's how it looks when you load it up in.net reflector, which is what you want to see:

Unfortunately, by default, .net reactor outputs every assembly into a separate folder which makes it a time-consuming task to add to the obfuscator DLLs back into the xap file as you have to go into many separate folders.  However, you can set the target location to a particular folder, as you can see above in the target file property, and then it appears in one folder.

Support

Two separate Google groups have sprung up to provide for .net reactor because the support from the developer was either slow or non-existent. . More recently, the developer has been, very active in these forums and has provided me with fixes for problems I was having with control flow obfuscation.  The support was excellent , and I'm very much looking forward to some of the functionality in upcoming releases

 

DeepSea obfuscator

In DeepSea obfuscator you add all your files into a single list:

DeepSea obfuscator places all the output files in a single folder, which is very easy to use, because then all you need to do is add those files back to your xap file. It also produces a map file, which can be used to de-obfuscate the stack trace if you encounter any problems in your obfuscated application.

One really brilliant feature of this product is that if you go to the external configuration tab, you can see before it builds exactly what is going to do to each function in terms of obfuscation:

Also on this tab is full control over each and every setting for each and every function. This probably makes the user interface slightly more complicated than it needs to be, but it does give substantial power and flexibility. Once you get used to it, it is probably very useful.  However, if you want to set the same setting on multiple assemblies, you have to go through each assembly and change the settings - very time-consuming.

Unfortunately some of the concepts a bit confusing, they have a separate project and external configuration file, and I'm not entirely sure what the difference is.

Merging with DeepSea obfuscator is a slightly complicated task - there is no way to specify this in the user interface. You have to go into the assembly that you want to merge with other assemblies and add an attribute like this:

[assembly: Obfuscation(Feature="inject /a:TourObjects.dll /i:true")]

The /i:true indicates that I want to make all the classes in that DLL internal in the new dll (SilverlightTourViewer.dll). Unfortunately, DeepSea obfuscator has a problem with this and causes an exception when trying to run the application. If you don't make the classes internal the merge does work. As discussed below the support has been excellent and they are working on a fix for this.

The current release of DeepSea obfuscator now has any support for anti-disassembly, but not yet support for anti-disassembly features in the control flow obfuscation.

Support

The support from DeepSea obfuscator people has been outstanding. In response to my first e-mail requesting anti-disassembly support in the product they agreed to add it in. They've keep me up to date throughout the process of adding in this functionality. When I had problems with implementing the merge feature, their support was excellent and they have taken the files that are causing the problem and are working on a fix.

You can't ask for better than that!

 

{smartassembly}

Smart assembly was the first tool I tried. In some ways the user interface is the simplest. All you have to do is select your main assembly and check a few boxes.

Your files are output into a single folder, which is very easy to use, because then all you need to do is add those files back to your xap file.

Unfortunately, having checked all the boxes and built my application, it came up with all sorts of exceptions. The only two features that you could check that actually worked were control flow obfuscation and anti-disassembly. Name obfuscation, merging, pruning and anything else didn't actually work. It turns out that the problem with obfuscation is that it is obfuscating it ends that are referenced in the xaml. It is not changing the xaml, and therefore causes problems for Silverlight.

Support

The support from the {smartassembly} people was good, responses generally took around 24 to 48 hours. Unfortunately the support person didn't really appear to understand the problem and that it was actually a bug and suggested all sorts of things which made no difference, including excluding all the namespaces that were causing problems with the build - which effectively meant the application was not obfuscated.

He tells me that they will be working on this, but there is no timeframe for it to be fixed.

Conclusion

{smartassembly} didn't work for me at all. In addition, it is substantially more expensive than the other two options.

There are now two affordable Silverlight obfuscators in .net reactor and DeepSea obfuscator. Both of them work reasonably well.  Personally I have chosen to go with .net reactor. It provides better control flow obfuscation at this stage,  As long as the developer continues to provide excellent support I'm sure that the product will be very successful. However DeepSea obfuscator is an equally valid choice and it has excellent support.

A couple of other vendors have been in touch with me regarding reviewing their products, and I'll add these in at some stage in the future. However, both are more expensive than either the DeepSea or .net reactor obfuscators.

As mentioned in my previous post. I have developed FlowDocument viewers for Silverlight which are intended to be API compatible with the WPF FlowDocument viewers. FlowDocuments give you the ability to display rich text content and are a feature of WPF.

Unfortunately this functionality is not currently available in Silverlight. When building the Virtual Tour Viewer I needed to flow documents, because the WPF version already displayed its text using flow documents. The solution was to build my own flow document viewer for Silverlight.

Here's what it looks like in the virtual tour viewer:

And here's what it looks like in the sample application for it:

 

This unfortunately was not quite as easy as it might sound. The first problem is caused by the fact that flow documents are xaml, but the Silverlight xaml parser will not read them because they contain classes that are not in the default namespace. This unfortunately means that the documents have to be read using Linq to XML , which is a lot more work.

WPF has a couple of different types of FlowDocument viewers, the FlowDocumentScrollViewer, which as you might imagine scrolls the document. Then there is a FlowDocumentPageViewer, which displays it either in pages or columns. These are then brought together into a single FlowDocumentReader class, which as you can see in the sample above provides support for zooming and changing between these modes.

The flow document viewer as it currently stands provide support for most of the basic flow document structures as you can see above in the sample. Some features, such as embedded controls are not currently demonstrated. I intend to add support for lists and hyperlinks before release.

Unfortunately as you can imagine a project like this can take up quite a bit of time. I would love to release this as open source, but I do need to do a little bit of cleanup before it can be released, which takes time I have to take off other (paying) work. If you would like to see that flow document viewer made available, please submit a 5 star vote for the Virtual Tour Viewer in the ComponentArt Silverlight coding contest. If I win this, which your votes will help, I will release the FlowDocumentViewer and the RoutedCommand support I’ve built for Silverlight onto codeplex.

Using the FlowDocumentReader

Loading a FlowDocument

here's how you load of flow document from the resources:

StreamResourceInfo r = Application.GetResourceStream(new Uri("test.flowdoc", UriKind.RelativeOrAbsolute));
StreamReader sr = new StreamReader(r.Stream);
XElement el = XElement.Load(sr);

FlowDocument fd = FlowDocument.Load(el, FlowDocumentStyles, null, null);

Displaying a FlowDocument

To display a FlowDocument you need a FlowDocument viewer of some kind and to set the Document property. This can be done by binding, or in code as shown below:

In Xaml (the control):

<Controls:FlowDocumentReader Grid.Row="1" Foreground="White" x:Name="_Viewer"/>

In code:

_Viewer.Document = fd;

I hope that this has wet your appetite for what is possible with flow documents, and hopefully I'll win the Silverlight contest and have time to release it as open source!

Please Vote for the virtual tour viewer by clicking here

ComponentArt are currently holding a competition to find the best Silverlight application. The community can vote for their favourite application and they will then be judged by some of the most respected people in the Silverlight community.  The winner gets $10,000 US!  You can see and vote for all entrants here:
http://www.componentart.com/community/competition2009/

Over the past couple of weeks I've spent a lot of time redesigning the Virtual Tour viewer I have described in previous posts.  It's not yet perfect, but it is an improvement on the previous releases. Having redesigned the WPF version, I have ported those changes across to the Silverlight version and have entered in the competition.    There is still some work to do removing a few bugs before the official judging starts on 23 October.

You can find (and vote for) my entry here:
http://www.componentart.com/community/competition2009/details.aspx?id=1109

The competition entry includes the full Versailles Virtual Tour. We are trying to see if people will be willing to donate to help improve the tours, because it will give greater access for a larger number of people.

As I've discussed in previous posts, the Silverlight version makes use of the Silverlight WPF compatibility library that I have built, which provides Silverlight versions of routed commands, flow documents and a number of other features not found in Silverlight.  The WPF version of the Silverlight compatibility library includes features such as the URI mapper and child window.

As an incentive to encourage you to vote for the virtual tour, I will release the Silverlight WPF compatibility library on codeplex, if I win the competition.  The reason for this is the competition provides a substantial financial prize for the winner, and it would give me some additional time to be able to complete the code and samples.  The more five-star votes I get, the more likely I am to win, so please go and vote!!

If you have feedback on the tour we'd love to hear from you either via e-mail or via the comments.

…Stefan

Unfortunately the dataform that was shipped with Silverlight 3 RTW (in the Toolkit) was massively changed from the beta version, and as a result has a number of bugs that were not there during the beta.

To find these bugs create a new project using the business application template, and run it.  Click login, type some text into Username and then click OK and you will see the following screen:

You will note that there are two problems with this screen:

1. the first one is that the data form has become opaque

2. the second one is the fact that the password and confirm password, which are required fields are not marked in red.

3. If you add in a checkbox as a label and click OK, you get this screen:

Workarounds

1. This bug is caused because the DataForm doesn’t listen for IsEnabledChanged, but in the UpdateStates() function will call GoToState to change for the disabled state. Unfortunately if it doesn't go back and to update states after if you enable, you're left in the disabled state. The workaround is to create a derived class that looks like this and use it in place of the dataform:

public class LessBuggyDataForm:DataForm
   {
       private const string DATAFORM_stateDisabled = "Disabled";
       private const string DATAFORM_stateNormal = "Normal";

       public override void OnApplyTemplate()
       {
           IsEnabledChanged += LessBuggyDataForm_IsEnabledChanged;
           base.OnApplyTemplate();
       }

       void LessBuggyDataForm_IsEnabledChanged(object sender, DependencyPropertyChangedEventArgs e)
       {
           if (!IsEnabled)
           {
               VisualStateManager.GoToState(this, DATAFORM_stateDisabled, true);
           }
           else
           {
               VisualStateManager.GoToState(this, DATAFORM_stateNormal, true);
           }
       }
   }

 

2.  I'm not entirely sure why this bug is caused. What happens is that unless the password text is updated, the validation doesn't seem to occur. Therefore, the workaround is every time you want to force validation to happen. You need to call a function like this in the password control:

public void UpdatePasswordText()
        {
            this.PasswordText = this.password.Password;
        }

Normally you'd call this before you call ValidateItem() or CommitEdit()

3. This problem is caused by the fact that when you click the okay button, CancelEdit() is called, which completely rebuilds the label. The exception is because checkbox is already the child of another control, and it tries to make it a child of the new label.

The workaround is to stop the ability to cancel the editing like this:

registerForm.EditEnding += new EventHandler<DataFormEditEndingEventArgs>(registerForm_EditEnding);
}

void registerForm_EditEnding(object sender, DataFormEditEndingEventArgs e)
{
    if (e.EditAction==DataFormEditAction.Cancel)
    {
        e.Cancel = true;
        return;
    }
}

Hopefully these solutions will save someone else some time.

…Stefan

As I did after the Silverlight 2 release, I thought it would be a good idea to review the bugs that I have submitted, to see what progress is. It's taken me a while to get this done because I've been busy with other things.

Four of the bugs are fixed. Unfortunately, the Silverlight team are very poor at communicating the status of bugs - often bugs will be closed then opened and then closed again and there's often never any explanation as to whether the bug is ever going to be fixed.  The majority of these issues are in situations where you would expect things to work - they do work correctly WPF but don't work in Silverlight.  In some cases, I suspect that this is because of the internal structures in Silverlight - hopefully these will be resolved soon, but I'm not holding my breath.

Suggestion implemented:

#373013 BindingOperations should be included in Silverlight (partially implemented)

Fixed:

#378419 Assigning new content to a ContentControl clears other controls in the template in Silverlight

#470822 Image.source with no source set is not null

#461978 ItemContainerStyle gets incorrectly applied within a control template

#458014 Changing title on page just does not change title on title bar

Apparently By Design:

#377494 ToggleButton doesn't display the IsChecked visual state correctly

#377655 Referencing an image via a relative path in generic.xaml causes exception in Silverlight

Not Fixed:

#373116 ToolTip causes ArgumentException

#373957 Value does not fall within the expected range assigning PointCollection in Silverlight

#377171 Using a path style from app.xaml fails the second time in Silverlight

#425334 Binding to ActualWidth ignores changes in Silverlight

#428412 Linked files in folders are not output correctly in SL 3

#459475 ImageBrush ImageSource binding parsing error

#460375 Silverlight doesn't work correctly with multiple resource dictionaries

#462271 Binding to Items.Count doesn't work

#469091 Referencing an image in a custom control which is a RootVisual will not load the image

#473411 Set Uri as "" in xaml not consistent with WPF

#475639 Silverlight should support nullable dependency properties (filed after SL 3 RTW)

Update: I'd forgotten to update the sample that goes along with the download. It has now been updated to support the .net RIA services July CTP.

I’ve received a couple of requests in the past few days asking if there will be an update to the URI mappers (Updates to custom routing using the Uri Mapper in Silverlight 3 and Displaying a login dialog based on page attributes in Silverlight 3) that work with the Silverlight 3 RTW & .net RIA services July CTP. 

The CustomUriMapper works just fine with Silverlight 3. However, I have fixed one bug and provided a project you can include in your solution to make it easy to use it. You can find it under UriMapper\AuthenticatingUriMapper\CustomUriMapper.csproj.

Unfortunately I had forgotten that changes were required to get the AuthenticatingUriMapper working with the July CTP and had neglected to update it on the website.

Download

You can download the latest source code and example here.

…Stefan