Windows Live Wave 4 Beta - Error 0x8104000b WaitForCatalog

0x8104000b
Source: WaitForCatalog.
Couldn't setup the installer. Check to make sure you are connected to the internet.

Had this nasty installer bug that hit me when installing Windows Live Wave 4 beta.  After a good deal of looking around, I ended up http://windowslivehelp.com/thread.aspx?threadid=ccb7680f-260f-4ebb-acf5-e2247a7aefe3 where various users were discussing their problems and Microsoft is trying to help.

My Particular problem was due to an old manual configuration script for my IE Proxy settings.  It had been un-ticked, but the address field wasn't blanked out.  So I had to tick it, enter <space> to blank it out, OK to save, then re-open the dialog to make sure the old proxy script is indeed gone.

Then run the installer from Microsoft again.

Check out the entire thread for other possible problems and fixes.  And if you see it asking you to download an exe from a non-Microsoft source, always exercise caution and double-check it with Microsoft Security Essentials first.

Len (MS)

We have identified a bug that occurs when your IE proxy settings point to a proxy script that is invalid or not reachable.  We are working on a permanent solution to this problem but in the meantime have come up with this workaround.

1) Open Internet Explorer.

2) Click Tools, then click Internet Options.

3) Click the Connections tab, and then click the LAN settings button.

4) Select the check box for Use automatic configuration script.

5) Copy the URL that is shown in the Address box below the check box. Paste it somewhere that you can retrieve it from later (in case you want to restore this setting when you are done installing Windows Live)

6) Delete the URL currently shown in the Address box, and replace it with a space character

7) Click OK in Local Area Network (LAN) settings dialog.

8) Click the LAN settings button again.

9) Now clear the check box for Use automatic configuration script.

10) Click OK in Local Area Network (LAN) settings dialog.

11) Click OK in the  Internet Options dialog.

12) Run the installation of Windows Live Essentials again.

You want your proxy, configuration script to be completely blank.

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

SharePoint MOSS 2007 - Style Library - File Not Found

A client called up - after they performed a site collection export and import (in order to duplicate a site), the Publishing features we developed for them stopped working.  The site looks wrong.

So I pull out my detective hat and get to work.

1. IE Developer Tools quickly showed that there's a problem getting the CSS files from Style Library, where our feature deploys the CSS files
2. Jumping into the Style Library - things look in place.  Click on the CSS file itself -> File Not Found
3. Times like this one just LOVES SharePoint.  The main trap here really is that a whole number of files could be "not found".  And that error doesn't actually mean an awful lot.
4. Tried the simplest: knowing this file is part of the site definition, I deleted the file and re-activated our package.  SharePoint says file is back.  But again, clicking on it leads to the File Not Found error, again
5. Quick check of the 12 Hive on the Web Front Ends (WFE) quickly determined that the file does exist in \FEATURES\
6. Imagining that it may be customized somehow, I tried Reset to Site Definition.  Still no good.
7. On the edge of going to the log files… 
8. When I remembered that we can try to see what the real error is.  So take a detour to the web.config
1. CustomError="Off"
2. CallStack="True"
9. Ah ha.  Site <guid> not found.  Stacktrace says Blobcache is involved.
10. This actually makes a lot of sense and confirms we weren't just mad.  Yes there is a file missing - the cache file!  Our file is actually fine sleeping in the content database.
11. Confirmed with customer they did switch on Blobcache a few month ago.  But obviously it's now interfering with the export/import routine. 
12. Switched BlobCache off via web.config
13. Refresh (F5) the site - everything's running just fine again :-)

All in about 50mins work.  In hindsight…  jump to the Stack Trace right away to save guess work.

In SharePoint 2010 - errors will be displayed with a Correlation ID, allowing admins to quickly jump to the error stack trace in the log files.

Develop and deploy Silverlight + SharePoint 2010 Solutions (part 2)

A quick summary of part 1:

1. Environment (tools)
2. Creating Silverlight project
3. Creating XAML
4. Hooking up Silverlight databinding to mock data
5. Implement real SharePoint query via Microsoft's Client Object Model
6. Quick discussion of the deploy to document library deployment strategy - I dubbed this XAP-deployment

Part 2 is all about Debugging and Tuning our service calls and see how much fine-grained control we have in talking to SharePoint.  Read on - it's really awesome. 

TIMER UPDATE (RE-QUERY)

First problem we have is that the Silverlight application does not re-query the service.  It runs, queries SharePoint once, and then stops.

1. Let's make it query SharePoint on a periodic basis.  There are various timers available in Silverlight, the easiest to use is the System.Windows.Threading.DispatcherTimer:

        public SharePointChart()
        {
            InitializeComponent();
            sharepointContext = ClientContext.Current;

            DispatcherTimer timer = new DispatcherTimer();
            timer.Interval = new TimeSpan(0, 0, 5);
            timer.Tick += new EventHandler(timer_Tick);
            timer.Start();
        }
        private void timer_Tick(object sender, EventArgs e)
        {
            if (sharepointContext == null)
            {
                GetData();
            }
            else
            {
                QueryDataFromSharePoint();
            }
        }

2. Notes:
   • Create a DispatcherTimer, set it to tick every 5 seconds
   • On each tick - query data from SharePoint
   • By magic of the earlier work we did with databinding in XAML - there is no UI update code required.  The code (controller) updates the data (model) and the UI (view) updates automatically.  This is best practice to move towards full MVVM in Silverlight, and the least amount of headaches down the road.

DEBUGGING SILVERLIGHT

As Silverlight is running in the Browser, debugging the Silverlight application can be done via Attaching the debugger to a running browser process.

In the list of processes - look for the browser process that has Silverlight run time loaded.

You can attach to other browsers as well.

Key notes:

• Client side debugging Silverlight is superior:
• Managed Code - not Javascript
• Browser-independent - no fiddling with different DOM or browser behaviours
• Server-independent - you could be talking to your development, test, UAT or Production server, the server could be on-premise or in-the-cloud (SharePoint Online).  You are still, debugging the Silverlight that's running on your own machine, calling the server via published services.

TUNING SILVERLIGHT

Let's see what Silverlight is doing under the hood.  Run our favourite HTTP sniffer Fiddler 2 (you can also use FireBug or Wireshark - whichever you are familiar with):

Since our Silverlight is faithfully re-polling the server every 5 seconds, we see this particular HTTP connection repeating - for as long as the Silverlight app is running (close browser window to stop it)

Notice the return traffic is 1.3K - relatively tiny in the scheme of things.  By comparison:

• Full page reload starts at 30k for bare page
• AJAX web parts are about 20k (rough estimates)

Digging in a bit more on the traffic

The request is XML

The response is gzipped-compressed JSON (Javascript Object Notation)

TWEAKING THE QUERY IN LINQ

This next part is tricky but interesting.  The code first.

        private const string ListName = "Football";
        private const string InternalFieldName = "FavouriteCountry";
        private ListItemCollection listItems;
        private IEnumerable<ListItem> listItems2;

        private void QueryDataFromSharePoint()
        {
            Web web = sharepointContext.Web;
            // get our list
            List list = web.Lists.GetByTitle(ListName);
            // get items in our list
            listItems = list.GetItems(CamlQuery.CreateAllItemsQuery());

            
            // still need the earlier syntax to tell sharepoint where to get it
            listItems2 = sharepointContext.LoadQuery(
                listItems.Include(
                    item => item["Title"],
                    item => item[InternalFieldName])
                );

            // but don't actually load it!
            //sharepointContext.Load(listItems);

            // execute the load asynchronously
            sharepointContext.ExecuteQueryAsync(SucceededCallback, FailedCallback);
        }

Notes:

• We still need a reference to the ListItems Collection via List.GetItems(CamlQuery.CreateAllItemsQuery());
• We use it as a reference point to begin our LINQ Query
• The SharePoint ClientContext has a separate LoadQuery method, that returns a new ListItems collection - listItems2, we start from the CAML definition, and further refine it to ONLY include the Title and FavouriteCountry fields.
• But we don't actually ever call Load on ListItems

Result:

We've shrunk the data load from 1.7k down to 359 bytes!

The returned JSON object is a lot lighter - and contains only a few of the required fields (ID, ObjectType, ObjectVersion), as well as our Title and FavouriteCountry.

MAKE YOUR SERVER DO WORK

Imagine the list is thousands of items.  We don't always want to bring back every list item.  What we should always consider is how to use SharePoint to do much of the work for us, and keep our connection traffic low.

            listItems2 = sharepointContext.LoadQuery(
                listItems.Include(
                    item => item["Title"],
                    item => item[InternalFieldName])                    
                .Where(
                    // add where clause for server to execute
                    item => (string)item["Title"] == "john")
                );

Notes:

• I'm inserting here a Where clause to my LINQ query.  The Query is to be executed on the server.
• IMPORTANT: do not use Where clause on the Load method - because that is a LINQ to objects filter and is very bad:  imagine bringing down 1000 items and then do your filtering in memory on the client side…

Result:

Only pulling back 1 record.

Check out the Request XML - includes the Where clause filter.

SUMMARY

• How to attach debugger, check network traffic with Fiddler
• Do your VIEWFIELDS, FILTER and SORT on the server
• LINQ is converted to CAML beneath the hood - but you can avoid CAML…  almost
• Trim your service call
• You probably don't need to poll the server every 5 seconds as well

NEXT UP

Wrapping up in the next part for:

• Deployment considerations
• Out of Browser
• REST interface
• Silverlight initParam

Update: Part 3 (final) is now up.