Silverlight Unit Testing - adding a timeout to EnqueueConditional

Since a lot of Silverlight work is asynchronous in nature, the Silverlight testing framework has many helper functions to essentially do "non blocking wait until something happens"

The curious one to me is EnqueueConditional(Func<bool> conditionalDelegate

This one essentially waits until the condition is true - so you can call a method to populate your view model with data, and then wait until data.Count > 0

But the method has no support for timeout.  It can, and will, hold the unit testing framework in progress forever.

Here's my little tweak to the method.

        public override void EnqueueConditional(Func<bool> conditionalDelegate)
        {
            DispatcherTimer timer = new DispatcherTimer();
            timer.Interval = new TimeSpan(0, 0, 5);
            timer.Tick += delegate
            {
                // remember to stop timer or it'll tick again
                timer.Stop();
                throw new TimeoutException();
            };
            EnqueueCallback(delegate
            {
                timer.Start();
            });
            base.EnqueueConditional(conditionalDelegate);
            EnqueueCallback(delegate
            {
                timer.Stop();
            });
        }

Here's the unit test to go with it

        [TestMethod]
        [TestProperty("TestCategory", "Silverlight")]
        [Asynchronous]
        [ExpectedException(typeof(TimeoutException))]
        public void Test_Timeout()
        {
            EnqueueConditional(delegate
            {
                // return?  never!
                return false;
            });

            EnqueueTestComplete();
        }

And one more tweak in the App.xaml.cs

        private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
        {
            if (e.ExceptionObject is TimeoutException)
            {
                e.Handled = true;
                // stop any timeoutexception here or it'll bubble to the DOM
                return;
            }

            ...
        }

Here's the result picture:  Running just slightly over 5 seconds.

Updated: added a result picture.

Silverlight first asynchronous test run twice

I'm observing a pretty odd behaviour - the first test of my MVVM is running twice.

Exhibit Original code:

    [TestMethod, Asynchronous]
    public void VMConnectTest()
    {
        ViewModel clientVM = CreateVM();

        #region connect
        clientVM.Connect.Execute(null);
        base.EnqueueConditional(delegate
        {
            return clientVM.IsConnected;
        });
        #endregion
        base.EnqueueTestComplete();
    }

I have a break point in CreateVM - and it's firing twice, off the same line.

Changing the code to:

    [TestMethod, Asynchronous] 
    public void VMConnectTest()
    {
        ViewModel clientVM = null;

        #region connect
        base.EnqueueCallback(delegate
        {
            clientVM = CreateVM()
            clientVM.Connect.Execute(null);
        });
        base.EnqueueConditional(delegate
        {
            return clientVM.IsConnected;
        });
        #endregion
        base.EnqueueTestComplete();
    }

And now the CreateVM only runs once.

I suspect the Asynchronous test has a bug regarding mixing which thread is suppose to be creating the VM.  In this case, it's running twice.  Throwing everything onto the test stack seems to have fixed this, but makes the code look more complex than usual.

Silverlight Unit Testing Framework - modify/remove Tag Expressions dialog

The default Silverlight Unit Testing framework project has a lovely Tag Expressions welcome dialog that lets you decide (within 5 seconds), whether you want to run a subset.

How do you get rid of it?

Turns out it's pretty easy:

        private void Application_Startup(object sender, StartupEventArgs e)
        {
            UnitTestSettings settings = UnitTestSystem.CreateDefaultSettings();
            settings.StartRunImmediately = true;
            settings.ShowTagExpressionEditor = false;

            RootVisual = UnitTestSystem.CreateTestPage(settings);
        }

Use UnitTestSystem.CreateDefaultSettings() to get you started quickly, if you create your own UnitTestSettings class you will have to set up your own Test Harness or you'll face this Exception:

Test harness was not specified on test harness settings object. If a test harness settings object was passed in, please verify that it contains a reference to a test harness.

Develop and deploy Silverlight + SharePoint 2010 Solutions (part 3 - light it up)

A quick summary of part 2:

1. How to attach debugger, check network traffic with Fiddler
2. Do your VIEWFIELDS, FILTER and SORT on the server
3. LINQ is converted to CAML beneath the hood - but you can avoid CAML…  almost
4. Trim your service call

Part 3 is all where we Light up SharePoint and take it beyond the browser.  And see why SL + SP is just pure awesome.

OUT OF BROWSER

There's one change in Code necessary for Out-of-browser.

        public SharePointChart()
        {
            InitializeComponent();
            sharepointContext = ClientContext.Current;
 
            if (sharepointContext == null)
            {
                sharepointContext = new ClientContext("http://colt-sp2010/sites/Home/");
            }
 
            DispatcherTimer timer = new DispatcherTimer();
            timer.Interval = new TimeSpan(0, 0, 5);
            timer.Tick += new EventHandler(timer_Tick);
            timer.Start();
        }

When you are running Out of Browser you don't have a ClientContext.Current.  No worry, we create one by giving it the Site URL.

(NOTE: this will disable our "mock-data" code, since sharepointContext won't be null anymore)

Tools in VS.NET 2010 has really improved on this front.  Making Silverlight work out of browser is simply just ticking this one check box.

Which is great - because it means I can pack more stuff into my demo :-)

I don't actually need to change any Out-of-Browser settings.  But the one to take note is the "Require elevated trust".  Some features of Silverlight will require full trust in OOB.

Anyway, compile the solution again, and XAP-Deploy to SharePoint document library again.

Right click to install to computer.

Run this from the Computer.

DEPLOYMENT CONSIDERATIONS

While XAP-document-library-deployment looks awesome in a demo, there are drawbacks that must be taken into consideration:

1. Do you leave your end-users to manage versions?  Will they copy your SharePoint Silverlight component and deploy it to 20 document libraries, leaving you no way to centrally upgrade them as a single unit?
2. In many cases, it is much better for developers to build Silverlight + SharePoint solutions as Sandbox Solutions.  You do this by adding a SharePoint project into your VS.NET, and then configure the xap file to be added to SharePoint as a feature module
3. Finally, if you want to grant Silverlight additional capabilities that involves additional services deployed on the server, you may need to go back to full Farm-Solutions.  I don't see this as a common scenario.

So the summary version:

XAP document library deployment:

Great for IT PRO who doesn't have permissions.
Not great for version control.

Sandbox Solutions:

Great for site collection administrators.
Centralized deployment and good version control capabilities.

Farm Solutions:

Useful if you need to deploy server-side stuff, like an extra WCF service.
Build to target Sandbox.

SILVERLIGHT INIT-PARAMS

A question in the question time:  Can parameters be specified for Silverlight so that I don't have to hard-code the list internal name.

Yes it can:

Silverlight has a property initParam (think of void Main(string[] args))

The way you access it in code is during the Silverlight app startup.

In the application startup event - read the initialization parameters.

SharePoint web part configuration lets end-users specify the InitParams in this settings box.

This concludes the 3-part Silverlight + SharePoint solutions blog-series.  Let me know what you guys think and if I've made any blunders in the blog.

FUTURE IDEAS

A quick brain dump of the future of Silverlight + SharePoint

Silverlight Features

• Local storage
• Access Groove as offline storage
• Camera or mic
• Local event notification
• COM access

SharePoint + Silverlight Features

• "SharePoint-Repair" Silverlight tools
• Dynamic Language Runtime + SharePoint <- this is going to be super awesome
• Adding additional farm services

Development (unfortunately not written yet)

• Full Sandbox Solutions demo
• Full REST interface demo
• Full old-WCF services demo

SharePoint: Do you turn off auto update on your SharePoint servers?

Cross Posted from Do you turn off auto update on your SharePoint servers?

A recent Security Hotfix has broken SharePoint WSS3 stand-alone installations.  This has prompted Microsoft SharePoint team to quickly release information regarding how to fix the issue.
http://blogs.msdn.com/b/sharepoint/archive/2010/06/22/installing-kb938444.aspx
This again reminds us that it is always not a good idea to have Windows Update automatically updating your servers.  There are a few reasons.

1. The previously mentioned problem - where the hotfix could bring down a production environment. 
2. In fact, even in a development environment this could be hours of lost work as the development team struggles to understand why only some of the developers' SharePoint magically and mysteriously broke overnight.
3. Windows Update could restart your server, or put your server in a state where it requires restarting - preventing any urgent MSI installs without bringing down the server.

Windows Update remains the best thing for end-users to protect their systems.  But in a server, especially a production server environment - Windows Update patches are just like any new versions of the software that's built internally.  It should be tested and then deployed in a controlled manner.
So recommendations:

1. Windows Updates may be critical and should be kept relatively up to date.
2. Have a plan where your awesome Network Admins schedule time to keep the servers up to date - including testing that the servers still perform its functions.
3. Turn off Automatic Windows Update on Windows Servers