Bryant Likes

One of the cool features of SharePoint 2010 (currently in beta) is that you can set it up on a Windows 7 machine. This means that as a SharePoint developer you no longer have to run a Server OS.

To get started I downloaded the SharePoint 2010 Foundations beta from here. You will also need Visual Studio 2010 which you can download from here.

To setup SharePoint 2010 on Windows 7 you need to follow this guide which explains how to configure the setup process to run on Windows 7 (it is only one change to an xml file).

Make sure you install all the prerequisites which I won’t list here (they are listed in the guide). It will still install even if you don’t, but you will get errors when you try to configure SharePoint (voice of experience here).

Once you have everything installed and have completed the configuration tool, your site should come up in the browser! Now you can start working with Silverlight and SharePoint.

Tip: Install the SQL Service Manager so that you can turn SQL Server off when you’re not doing SharePoint development. 

A some great resources for getting started with Silverlight and SharePoint 2010 are the PDC sessions which you can watch for free:

• Developer Patterns to Integrate Microsoft Silverlight 3.0 with Microsoft SharePoint 2010
• Developing Solutions for Microsoft SharePoint Server 2010 Using the Client Object Model

For this example we will primarily be utilizing the information in the first session by Paul Stubbs. With SharePoint 2010, Silverlight can live just about anywhere in the user interface, but this example will be geared toward how simple it is to publish a Silverlight application to a SharePoint site and use it in a web part.

Fire up Visual Studio 2010 and create a new Silverlight Application:

At the prompt asking you if you want to create a web application to host the Silverlight application uncheck the checkbox. We don’t need to host Silverlight in a separate web app since SharePoint will be the host.

In the Silverlight Application, edit the MainPage.xaml to have the following Xaml:

<Grid x:Name="LayoutRoot" Background="PowderBlue">
    <TextBlock Text="Silverlight In SharePoint" 
               TextWrapping="Wrap" 
               FontSize="56" 
               FontWeight="Bold" />
</Grid>

Now let’s add the SharePoint part of the project. Before we add the SharePoint project though we need to be running Visual Studio as the Administrator. Save your work and close the solution. Then right click the Visual Studio 2010 shortcut and select Run As Administrator. Back in the solution, right click the solution and select Add -> New Project. Select SharePoint –> 2010 as the project type and select an Empty SharePoint Project:

If you aren’t running as an Administrator then Visual Studio will tell you that the project requires elevated permissions in order to run.

The SharePoint customization Wizard dialog will pop up asking if you want to deploy as a sandboxed solution or a farm solution. Leave the sandboxed solution checked and click ok. Next, right click on the SharePoint project in the Solution Explorer and select Add -> New Item. Add a new Module to the project as shown below:

Now right click the new Module and select Properties. In the Properties window click in the Project Output References and then click the ellipse button (…). In the Project Output References dialog click the Add button. Expand the deployment location property on the new reference then change the Project Name to the Silverlight project name and the Deployment Type to ElementFile. You should end up with something that looks like this:

Next expand the module we created in the SharePoint project and delete the Sample.txt file. Then open the Elements.xml file. Edit the file to include the xap file that will be generated from our Silverlight application:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="SilverlightModule">
    <File Path="SilverlightModule\SilverlightInSharePoint.xap" 
          Url="_catalogs/masterpage/SilverlightInSharePoint.xap" />
  </Module>
</Elements>

At this point your application is ready to be deployed. Right click the SharePoint project and select Set as Startup Project and hit F5. Visual Studio will build and deploy your project to your local SharePoint site and then open it in the browser. However, at this point our Silverlight application isn’t active in any of the pages. Let’s add the Silverlight application as a web part in the default page.

On the SharePoint site click the edit icon then the insert tab, select Web Part, and choose the Silverlight Web Part in the Media and Content category:

Click Add and in the Silverlight Web Part dialog enter the value from the Url field in the Elements.xml file but add a leading slash. So for our example we would enter:

/_catalogs/masterpage/SilverlightInSharePoint.xap

The web part will give you a message that it could not download the xap file. You can ignore this message and just click the save icon. You will get the Silverlight application on the web page, but it will look messed up:

The problem is the default size for the Silverlight Web Part is 400x300 but our text is bigger than 300. So we need to set the size to be 400x400. Click the drop down arrow on the top right of the web part and select Edit Web Part. In the web part properties dialog set the height of the web part to 400 and set the chrome type to None. Click Ok and you should get a better looking page:

Congratulations! You’ve now gotten started with Silverlight 3 and SharePoint 2010. Silverlight development with SharePoint 2010 is much improved in this new version. Happy SharePointing!

A question came up in the Silverlight Forums about how to timeout a user when using .NET RIA Services. Since I have implemented this before I thought I would share an approach I used. There might be a better way that is more integrated with the ASP.Net security, but for now this works.

To start with, you’ll need the Sample Application that Brad Abram has been building and blogging about and you might want to read through this post on Authentication in RIA Services before going any further. Once you have that and can build/run it on your machine you can continue on.

The security in Brad’s example uses a simple membership provider that is using RIA Services FormsAuthentication since it takes a username and password to log in. For our example we will extend the FormsAuthentication and add a timeout to it. Below is my implementation of the FormsWithTimeoutAuthentication class:

namespace MyApp
{
    public class FormsWithTimeoutAuthentication : FormsAuthentication
    {
        private DispatcherTimer idleTimer;
        private int minutesIdle;
        private bool idle;
        private bool attached = false;

        public FormsWithTimeoutAuthentication()
            : this(20)
        { }

        public FormsWithTimeoutAuthentication(int idleMinutes)
        {
            IdleMinutesBeforeTimeout = idleMinutes;
            idleTimer = new DispatcherTimer();
            idleTimer.Interval = TimeSpan.FromMinutes(1);
            idleTimer.Tick += new EventHandler(idleTimer_Tick);
        }

        public int IdleMinutesBeforeTimeout
        {
            get;
            set;
        }

        protected override LoginResult EndLogin(IAsyncResult asyncResult)
        {
            var result = base.EndLogin(asyncResult);

            if (result.LoginSuccess == true)
            {
                if (!attached) AttachEvents();
                minutesIdle = 0;
                idleTimer.Start();
            }

            return result;
        }

        protected override LogoutResult EndLogout(IAsyncResult asyncResult)
        {
            idleTimer.Stop();

            return base.EndLogout(asyncResult);
        }

        private void AttachEvents()
        {
            attached = true;
            Application.Current.RootVisual.MouseMove += new MouseEventHandler(RootVisual_MouseMove);
            Application.Current.RootVisual.KeyDown += new KeyEventHandler(RootVisual_KeyDown);
        }

        private void RootVisual_KeyDown(object sender, KeyEventArgs e)
        {
            idle = false;
        }

        private void RootVisual_MouseMove(object sender, MouseEventArgs e)
        {
            idle = false;
        }

        private void idleTimer_Tick(object sender, EventArgs e)
        {
            if (idle == true)
            {
                minutesIdle += idleTimer.Interval.Minutes;
                if (minutesIdle >= IdleMinutesBeforeTimeout)
                {
                    Logout();
                }
            }
            else
            {
                minutesIdle = 0;
            }
            idle = true;
        }
    }
}

All this class does is add a timer that fires once a minute. If the user has either moved the mouse or hit a key in that minute then they stay logged in. If the user hasn’t, then a minute of idle time is added to the idle minute count until the timeout limit is reached. Once that happens the user gets logged out.

Note that the events are attached to the root visual and don’t get attached until the user logs in. This is because the Authentication is created prior to the RootVisual being set.

Simply add this code to the sample project (linked above) and then change the authentication service in the App.xaml as follows:

<Application   
  x:Class="MyApp.App"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:app="clr-namespace:MyApp"
  xmlns:appsvc="clr-namespace:System.Windows.Ria.ApplicationServices;assembly=System.Windows.Ria"  
    >

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Assets/Styles.xaml"/>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>


    <Application.ApplicationLifetimeObjects>
        <app:RiaContext>
            <app:RiaContext.Authentication>
                <app:FormsWithTimeoutAuthentication IdleMinutesBeforeTimeout="2"/>
                <!--<appsvc:WindowsAuthentication/>-->
            </app:RiaContext.Authentication>
        </app:RiaContext>
    </Application.ApplicationLifetimeObjects>

</Application>

Here I’ve set the IdleMinutesBeforeTimeout to 2 minutes so that it is easy to test.

Once you’ve modified the application, when you run it you will get logged out after the number of minutes you specify in the timeout. There are lots of enhancements that could be made to this simple approach, but this works for most situations.

On October 1st I was honored to receive the Microsoft Most Valuable Professional Award for Silverlight. I am very excited that I received this award and look forward to continuing my contributions to the Silverlight Community.

I wasn’t the only one to receive this honor as Tim Heuer blogged here:

As of today (01 OCT 2009) we welcome some new folks to the Silverlight group:

• Rick Barraza (@rickbarraza)– wicked interactive design/developer with kung-fu XAML skillz
• Bryant Likes (@bryantlikes)– great contributor to the Silverlight Forums helping others solve their problems!
• Corey Schuman (@cschuman)– UX design/developer in Atlanta doing a bunch of great Silverlight community work
• Davide Zordan (@davidezordan)– over the pond in Italy spreading the Silverlight love!
• Jeff Paries – Silverlight animation wizard – get his book!
• Robby Ingebretsen (@ingebretsen)– another kung-fu XAML/Blend ninja
• Ambrose Little (@ambroselittle)– co-author of Silverlight 3 Programmer Reference and the man behind Quince (no @ambrosesbeard was not awarded)
• Huijun Li – helping spread the Silverlight in China overseas!

I’m very excited to be a part of the Silverlight MVPs group and look forward to working with them all.

As a Silverlight developer, when you want to add functionality to an existing control, you have two main options as I see it (if you want to get reuse from your code). You can either subclass the control or, as of Silverlight 3,  you can write a behavior for it. For example, one of the requests for the current Silverlight application that I’ve been working on was to have the TextBox select all the text when you tabbed to it or clicked in it. We can easily add this functionality using both of the above methods:

Here is how this could be done using subclassing:

public class SelectAllTextBox : TextBox 
{
    public SelectAllTextBox()
    {
        this.GotFocus += new RoutedEventHandler(TextBox_GotFocus);
    }

    private void TextBox_GotFocus(object sender, RoutedEventArgs e)
    {
        this.SelectAll();
    }
}

And here is how you would write this as a behavior:

public class SelectAllBehavior : Behavior<TextBox>
{
    protected override void OnAttached()
    {
        base.OnAttached();
        AssociatedObject.GotFocus += new RoutedEventHandler(AssociatedObject_GotFocus);
    }

    void AssociatedObject_GotFocus(object sender, RoutedEventArgs e)
    {
        ((TextBox)sender).SelectAll();
    }
}

The behavior has one more line of code and the added requirement of adding a reference to System.Windows.Interactivity.dll from the Blend 3 SDK. The bigger difference is how the code looks in our view when we add the control to it.

The subclassed control looks like (where ctrls is the controls namespace of our subclassed control):

<ctrls:SelectAllTextBox Text="{Binding MyText}" />

And the behavior looks like (where i is the System.Windows.Interactivity namespace and b is our behavior’s namespace):

<TextBox Text="{Binding MyText}">
    <i:Interaction.Behaviors>
        <b:SelectAllBehavior />
    </i:Interaction.Behaviors>
</TextBox>

Obviously the behavior is more verbose in this case than the subclassed approach.

Since both of these approaches work, which is the better approach? I think the subclassing is the easier approach, but I think the behavior would be the recommended approach. The reason is that I can build my SelectAll behavior today and then down the road build a different behavior and then selectively apply them to my TextBoxes as appropriate. However, if use the subclass approach I would automatically get the new behavior on all my controls which might not be what I wanted. It also means that if someone builds a better TextBox that I want to use that I would have to try to subclass that control, but with the behavior I could just apply it to the new control.

Update: A couple of quick updates. First, Alan Le pointed out that it depends on reuse. Obviously if you had to add the behavior to 20 TextBoxes it would take more time to use the behavior. However, Blend makes this a lot easier. Secondly, Brian mentioned in the comments that you could also use an attached property to do this so I thought I would quickly show what that might look like.

The code for the attached property would be:

public static class TextBoxProperties
{
    public static readonly DependencyProperty SelectAllProperty =
        DependencyProperty.RegisterAttached("SelectAll", typeof(bool), 
        typeof(TextBoxProperties), new PropertyMetadata(false, OnSelectAllChanged));

    public static void SetSelectAll(DependencyObject o, bool value)
    {
        o.SetValue(SelectAllProperty, value);
    }

    public static bool GetSelectAll(DependencyObject o)
    {
        return (bool)o.GetValue(SelectAllProperty);
    }

    private static void OnSelectAllChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        if ((bool)e.NewValue == true)
        {
            ((TextBox)d).GotFocus += new RoutedEventHandler(TextBoxProperties_GotFocus);
        }
    }

    private static void TextBoxProperties_GotFocus(object sender, RoutedEventArgs e)
    {
        ((TextBox)sender).SelectAll();
    }
}

And the Xaml would look like:

<TextBox Text="{Binding MyText}" ctrls:TextBoxProperties.SelectAll="true" />

I still think the Behavior is the best method to use since (at least in this case) we are just trying to add a behavior to the TextBox, not add significant functionality. The attached property also doesn’t feel right to me, but it does work just fine. Ultimately it comes down to preference and what method you like to use. :)

The current Silverlight application that I’m building has a Login view. One of the things that bugged me when I started using the application is that you would have to click the Login button after typing your password. I wanted to duplicate the default button behavior of HTML forms where when you hit the enter key it would trigger the default button on the form. I did some googling on the subject and came across this post by Patrick Cauldwell which is one way to solve the problem. However, in my case I had a username Textbox, a password Passwordbox, and a company Combobox and didn’t want to specify the button for each control.

So I create a simple solution of creating a content control that attaches to all the KeyUp events of all the child FrameworkElements in the content. To do this I used the FindChildren<T> extension method from the Avanade Silverlight Accelerator which is a toolkit we use internally at Avanade to speed up Silverlight development. The ContentControl exposes a DefaultCommand property which you then bind to the ICommand property on your ViewModel.

Below is a trimmed down example of the Login view. I’m using a variant of the RelayCommand/DelegateCommand as the LoginCommand here (see Laurent’s post on the RelayCommand for a good overview of Commands in Silverlight).

<ctrls:FormControl DefaultCommand="{Binding LoginCommand}">   
  <TextBox Text="{Binding Username, Mode=TwoWay}" />
  <PasswordBox Password="{Binding Password, Mode=TwoWay}" />
  <Button IsEnabled="{Binding LoginEnabled}" 
          cmds:ButtonClickCommand.Command="{Binding LoginCommand}" 
          Content="Login" />
</ctrls:FormControl>

There are many other things you could add to this but this is all the functionality that I needed and I decided to keep it simple. Download the class file (plus the extension method) below. Let me know if you find it useful!

This is another nugget of gold gleaned from the Climbing Mt Avalon workshop, although I believe this one came from Jonathan Russ. He was talking about a bunch of threading tricks in WPF and showed how if you wanted to run some code after everything was initialized you could use the BeginInvoke method of the Dispatcher object. Since there are many places in my code where I want to execute something when the control loads, but only once (since the loaded event gets fired whenever the object gets re-added to the visual tree) I end up writing a lot of code like:

public partial class Page : UserControl
{
    private bool initialized = false;

    public Page()
    {
        InitializeComponent();
        Loaded += new RoutedEventHandler(Page_Loaded);
    }

    void Page_Loaded(object sender, RoutedEventArgs e)
    {
        if (!initialized)
        {
            // do some initialization work
            initialized = true;
        }
    }

}

This works, but it isn’t perfect and there seems to be a lot of issues with the timing of the loaded event. So based on what Jonathan was saying, you could instead just put a call into BeginInvoke in the contructor like so:

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();
        Dispatcher.BeginInvoke(Initialized);
    }

    private void Initialized()
    {
        // do some initialization work
    }
}

So what is this actually doing? BeginInvoke puts a message in the message pump that is running under the covers of everything (note: I’m not a C++ programming so I don’t really fully understand message pumps so this is an over simplification). Because it is last in line in the queue of messages to process, it gets executed after all the other initialization code which has already lined up. If you debug this you will see it actually gets called after the Loaded event gets called. However, this code is the first thing to execute once everything has been loaded and setup which is usually when I want my code to execute.

So this is a much better way to handle initialization code since you aren’t adding event handlers that really only need to fire once and it executes once everything is fully initialized.

In my last post I blogged about using Attached Properties to get around the limitation that only Dependency Properties can be animated. One astute commented noted that he was guessing this could be applied to animations as well and the answer is yet it can. However, it requires one extra step that makes it a little less appealing.

Also I mentioned in my last post, I got this idea from the Climbing Mt Avalon workshop at MIX which has now been posted online and I would recommend watching if you’re doing Silverlight or WPF work. And now on to the code…

Typically if you want to animating something like the width of a grid in a column that isn’t animatable either because it isn’t a double, color, or another easily animatable type, then you would declare a dependency property on your own host class, usually a UserControl, and then animate that instead. A good example is this blog post on the subject which is what I’ve referred to many times.

However, if we take the attached property route instead of putting the code in our user control, we could declare our own attached property to do the work for us. Here is a simple example:

public static class Attachments
{

    public static readonly DependencyProperty ColumnWidthProperty =
            DependencyProperty.RegisterAttached("ColumnWidth", 
            typeof(double), typeof(Attachments), 
            new PropertyMetadata(
                new PropertyChangedCallback(OnColumnWidthChanged)));

    public static void SetColumnWidth(DependencyObject o, double value)
    {
        o.SetValue(ColumnWidthProperty, value);
    }

    public static double GetColumnWidth(DependencyObject o)
    {
        return (double)o.GetValue(ColumnWidthProperty);
    }

    private static void OnColumnWidthChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        ((ColumnDefinition)d).Width = new GridLength((double)e.NewValue);
    }

}

Once we have this code we can now simply animate the attached property like so:

<UserControl x:Class="SilverlightApplication1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:SilverlightApplication1"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <Grid.Resources>
            <Storyboard x:Name="expandBlue">
                <DoubleAnimation Storyboard.TargetName="blue"
                                 To="300" Duration="0:0:1" />
                <DoubleAnimation Storyboard.TargetName="red"
                                 To="100" Duration="0:0:1" />
            </Storyboard>
            <Storyboard x:Name="expandRed">
                <DoubleAnimation Storyboard.TargetName="red"
                                 To="300" Duration="0:0:1" />
                <DoubleAnimation Storyboard.TargetName="blue"
                                 To="100" Duration="0:0:1" />
            </Storyboard>
        </Grid.Resources>
        <Grid.ColumnDefinitions>
            <ColumnDefinition x:Name="blue" local:Attachments.ColumnWidth="200" />
            <ColumnDefinition x:Name="red" local:Attachments.ColumnWidth="200"/>
        </Grid.ColumnDefinitions>
        <Rectangle Grid.Column="0" Fill="Blue" MouseLeftButtonDown="Blue_MouseLeftButtonDown" />
        <Rectangle Grid.Column="1" Fill="Red" MouseLeftButtonDown="Red_MouseLeftButtonDown"/>
    </Grid>
</UserControl>

Unfortunately if you try the above code (after adding in the mouse event handlers) it won’t work. Why not? Well there seems to be an issue with animating custom attached properties when setting the target property directly in code (actually you’ll notice I left that out above. However, there is a way around it which I found over on Ed’s blog which is to set the target property in code. So here is the code behind with the work around:

public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();
        Storyboard.SetTargetProperty(expandBlue.Children[0], new PropertyPath(Attachments.ColumnWidthProperty));
        Storyboard.SetTargetProperty(expandBlue.Children[1], new PropertyPath(Attachments.ColumnWidthProperty));
        Storyboard.SetTargetProperty(expandRed.Children[0], new PropertyPath(Attachments.ColumnWidthProperty));
        Storyboard.SetTargetProperty(expandRed.Children[1], new PropertyPath(Attachments.ColumnWidthProperty));
    }

    private void Blue_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
    {
        expandBlue.Begin();
    }

    private void Red_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
    {
        expandRed.Begin();
    }
}

Once we set the target property via code, then everything works great. However, that is a pain and makes things a lot less clean. But still I think this is a useful approach to animating the properties that are not easily animatable.

I need to find the forum post where this question was asked, but I’ll have to do that later since I’m at MIX09 and searching the forums is low on my list. But I wanted to share a cool hack that I came across in the Climbing Mt Avalon (it was definitely a climb, not a hike).  One of the many cool things that was shared was a tidbit by Jaime Rodriguez about using Attached Properties.

The question in the forums was how you can style the VerticalScrollBarVisibility property on a TextBox. The problem is that since this property isn’t a DependencyProperty  so it can’t be styled. You can test this out by trying the following Xaml:

   1: <UserControl x:Class="Attachment.Page"

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:     Width="400" Height="300">

   5:     <UserControl.Resources>

   6:         <Style TargetType="TextBox" x:Key="test">

   7:             <Setter Property="FontSize" Value="24" />

   8:             <Setter Property="VerticalScrollBarVisibility" Value="Visible" />

   9:         </Style>

  10:     </UserControl.Resources>

  11:     <Grid x:Name="LayoutRoot" Background="White">

  12:      <TextBox Text="This is a test" Style="{StaticResource test}" />

  13:     </Grid>

  14: </UserControl>

If you try to run this it will fail. So how can we set this property in style? Well, a trick you can use is to set your own attached property and then have the property set the VerticalScrollBarVisibility property on the TextBox for you. Here is a very quick example that I cooked up (using Robby’s code snippet):

   1: namespace Attachment

   2: {

   3:     public static class Attachments

   4:     {

   5:         public static readonly DependencyProperty MyVsbvProperty =

   6:             DependencyProperty.RegisterAttached("MyVsbv", 

   7:                 typeof(ScrollBarVisibility), 

   8:                 typeof(Attachments), 

   9:                 new PropertyMetadata(OnMyVsbvChanged));

  10:  

  11:         public static void SetMyVsbv(DependencyObject o, ScrollBarVisibility value)

  12:         {

  13:             o.SetValue(MyVsbvProperty, value);

  14:         }

  15:  

  16:         public static ScrollBarVisibility GetMyVsbv(DependencyObject o)

  17:         {

  18:             return (ScrollBarVisibility)o.GetValue(MyVsbvProperty);

  19:         }

  20:  

  21:         private static void OnMyVsbvChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

  22:         {

  23:             ((TextBox)d).VerticalScrollBarVisibility = (ScrollBarVisibility)e.NewValue;

  24:         }

  25:     }

  26: }

Very unintuitive name and my casts could be bad since there are no type checks, just an example. So here when the attached property is changed we change the property on the TextBox that the property is declared on. So if we change our style to use the attached property instead of the actual property it will work:

   1: <UserControl x:Class="Attachment.Page"

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:     xmlns:local="clr-namespace:Attachment"

   5:     Width="400" Height="300">

   6:     <UserControl.Resources>

   7:         <Style TargetType="TextBox" x:Key="test">

   8:             <Setter Property="FontSize" Value="24" />

   9:             <Setter Property="local:Attachments.MyVsbv" Value="Visible" />

  10:         </Style>

  11:     </UserControl.Resources>

  12:     <Grid x:Name="LayoutRoot" Background="White">

  13:                 <TextBox Text="This is a test" Style="{StaticResource test}" />

  14:             </Grid>

  15: </UserControl>

So there you have it. If you need to style a property on a control that isn’t a dependency property you can use this method to get around that limitation. There are a bunch of other uses for this that I’ll be blogging when I have another minute.

Enjoy!

Yesterday I was working through another question in the Silverlight Forums about how to upload video to Silverlight Streaming via code. At first I tried to reference the Video.Show application, but there is a lot of code there and it doesn’t help if you just want to upload a bunch of videos to the same application. So I ended up taking some of the code from Video.Show and some of the code from the SDK/API and created a very simple Utility class to help with the process.

You can download the code on the Code Gallery site. It is very simple in that there is no error handling and I didn’t create a Silverlight version yet. I did implement GET, POST, PUT, MKCOL, and DELETE as well as creating the functionality to package a bunch of videos into a single zip which can be posted all at once.

A few examples from the code, first creating a directory and PUTting a file in it:

WebDavClient client = new WebDavClient("Your AppID", "Your Key"); 
// get those from http://silverlight.live.com
 
client.CreateFolder("MyVideos");
client.PutFile("MyVideos","C:\\videos\reallyCoolVideo.wmv");

Next, packaging up a bunch of videos and POSTing the zip as an application:

WebDavClient client = new WebDavClient("Your AppID", "Your Key"); 
// get those from http://silverlight.live.com
 
client.PackageAndPostFiles("MyVideos","C:\\videos\firstCoolVideo.wmv","C:\\videos\anothercoolVideo.wmv");

Let me know if you’d like to see a Silverlight version (be easy to implement) or if there are any other features you’d like added.

Enjoy!

This question has come up in the forums a few times so I thought it would be worth a blog post. Most people are pretty familiar with debugging a Silverlight application running locally during development, but what people many times don’t realize is that you can also attach your debugger to a xap file that is hosted remotely. This MSDN article touches on this briefly, but doesn’t really go into details on how it works.

The important thing to understand about Silverlight is that it runs the .NET code on the client machine, not on the server. The code runs in the browser process, so if you’re going to debug it you need to attach to that process. The one caveat is that the xap on the server must be the same as the compiled xap on your development machine. In other words, you can’t debug the remote xap after you’ve made changes locally and haven’t deployed them.

As an example I will demonstrate remotely debugging the Twilight badge on my blog.

First I open the Twilight.sln and since I’ve made a few changes in the last week I’ll deploy the latest xap file from my project to my server at http://blogs.sqlxml.org/wpfe/twilight.xap.

Next, now that I am sure the xap file on the server has the same code as my solution, I can set a breakpoint on Line 36 (using version 1.5.2) where the Twitter javascript callback calls into Silverlight with the latest list of tweets:

Now instead of hitting F5 to start debugging my application, I’ll open a new instance of Internet Explorer (or you could use Firefox to debug that as well) and navigate to my blog since that is where the xap shows up. Back in Visual Studio I click Debug –> Attach to Process and select the iexplore.exe process which is Internet Explorer (or firefox.exe if you’re debugging Firefox).

NOTE: Make sure you click highlight iexplore.exe or firefox.exe and then click the Select button and choose Silverlight as the type of code you wish to debug.

Once I click attach I can go back to my Internet Explorer window and hit refresh to force the breakpoint to get hit. If everything was setup correctly you should get taken back to Visual Studio where your breakpoint is highlighted and you can now step through your Silverlight code.

So why is this useful? Well a lot can change in your application when you start hosting it on a real server instead of in your localhost. For one, you now have to access services running on the server and you are subject to a lot more security checks that were ignored on your localhost. So I find this to be a useful tool for troubleshooting things when they work locally but break once I deploy out to a server.

One last thing, you can also set this up to remotely debug code running on the Mac.