Viewpoint

The SUESS Lifecycle: Stage 3 - SmoothStreaming

2010-09-04T18:22:00Z

The SUESS Series

Stage 3 – SmoothStreaming

We can now upload media. We can now encode media. Sweet. Now all we need to do is be able to watch it as well! This post covers the final stage of SUESS, which is the SmoothSreaming portion: the actual delivery of content from IIS Media Services to Silverlight. I want to get into a little bit more detail about what's going on both server side and client side to deliver SmoothStreaming content to our users.

There is already a lot out there that describes the basic concepts of SmoothStreaming, and outlines it with stunningly beautiful Visio diagrams. So instead of anteing up into that game, I'll deal my own, giving a more practical overview of the process, and discussing some of the roadblocks I encountered along the way.

So in one sentence: SmoothStreaming, part of IIS Media Services (3.0 at this time this was written), defines a media file format that IIS can adaptively stream to Silverlight clients. Microsoft Expression Encoder allows you to define various "streams" for the media file, containing different bitrates, sizes, and resolutions. The "adaptation" means that IIS will detect your bandwidth and serve up the appropriate version of the file.

Most of the work we need to do to finish off SUESS regards configuring IIS on the media server. Here's all you have to do:

Install IIS Media Services on your server. You can get that here.
Create a new virtual directory under the Encoder Service's website (let's call it "media") that points to the destination folder that our SUESS Encoder dumps the new sparkly SmoothStreaming files into.
Set both EncoderService (website) and media (virtual directory) to only have Anonymous Authentication enabled. A clientaccesspolicy.xml file in the root of EncoderService handles security for us.
Make sure the application pool identity and the "Physical Path Credentials" of the virtual directory have sufficient I/O permissions to read from this folder. We don't have to worry about the IIS Double Hop issue here, since Silverlight's call to EncoderService is anonymous. So even if the media virtual directory is on a different machine, that's only one bunny hop. For performance reasons, however, I have Encoder dump its files to the same server that is hosting Media Services.

Let's see where that gets us.

On the left, you can see "EncoderService" and its "media" virtual directory. Expression Encoder, by default, creates a folder with the following naming convention "<computer name> <timestamp>" under the destination folder. This is of course directly configurable in the API. On the right, I have the IIS "Content View" of one of these folders.

Here is what SmoothStreaming formatted media looks like in the light of day. The "ISMV" files are the actual streams that Encoder creates. To ensure again file name collusions, I prepend a Guid to the beginning of each. (This was from a beta version of SUESS that didn't have Encoder create a folder for each media file, which I now like better; the aforementioned "-Guid" is therefore superfluous.) Finally, Encoder affixes an underscore plus the bitrate to the end of each stream file.

Next we have those "ISM" and "ISMC" files hanging around. These are the manifest files that the server uses to define the SmoothStreaming file and tells the requesting clients what to expect. Both are just XML. The "ISMC" one is the "client" manifest file that helps Silverlight dissect the streams into the video and audio components, and exposes the different quality levels available.

The "ISM" file is the "server" manifest that is written in a special dialect of XML called "SMIL." This is more of a file manifest that defines the physical locations of all the constituent pieces that make up the SmoothStream. Finally, the thumbnail is (optionally) created here as well, following the same naming convention. You can specify the size and image format (by way of a codec) in the API, and the appropriate image will be generated.

Something that was way more difficult than it should have been was determining the actual URL of the SmoothStreaming media! For whatever reason, the research I did yielded misleading and conflicting results, so let me explicitly show the construction of the URL that Silverlight needs to have fed to its Uri for the SmoothStreamingMediaElement's SmoothStreamingSource property:

http(s)://<"EncoderService" web site>/<"media" virtual directory>/<folder(s) - if used>/<file name without extension>.ism/manifest

And guess what? That's it. Even though there's a new section called "Media Services" in the "Features View" of each IIS site, you don't need to mess with anything there. Encoder gives us so much control over the format of the SmootheStreaming files that we don't need to tell IIS to do anything else; it just servers the file, and Media Services and Silverlight high-five each other and tag team to show it.

On the client side, Silverlight can play these files by way of the SmoothStreamingMediaElement. This was one of the points that tripped me up: the standard MediaElement doesn't know what to do with these files. Instead, you have to get your hands on Microsoft.Web.Media.SmoothStreaming.dll, which can be found in "C:\Program Files (x86)\Microsoft SDKs\IIS Smooth Streaming Client\v1.0" after you install IIS Media Services.

Drop this DLL into your Media Player Silverlight project, and you can then use the SmoothStreamingMediaElement the same as a MediaElement. The only major different is that this control has a SmoothStreamingSource Uri property in addition to the standard Source property. Just set this to a Uri pointing at your SUESS media server and code up the rest of your player all the same. SmoothStreamingMediaElement also has support for "Live" Encoding, so you can broadcast source from a web cam down to Silverlight clients.

That's really all there is to discuss in terms of SmoothStreaming. Like I said, most of the magic is within the Encoder itself, as it converts raw media into this format. IIS Media Services just sort of knows what to do with it server side, and Silverlight controls with SmoothStreamingMediaElement players just sort of know what to do with it client side.

It just works.

Well, that closes the book on SUESS! Hopefully, as you've trudged through this series with me, there has been some enlightenment not only in terms of creating a Web 2.0 media stack for your clients in general, but also specifically to the new generation of .NET technologies. Silverlight 4, WCF/.Net 4, Microsoft Expression 3.0, and IIS Media Services 3.0 all wrap around the concept of SmoothStreaming and add their own functionality to the paradigm. My goal with SUESS was to bring these separate technologies together in a cohesive, media-centric way.

Have fun!

Configuring Custom Providers Using SharePoint 2010 Claims Based Authentication

2010-09-02T16:21:00Z

Introduction

For those of you who have been with me since the beginning, you'll remember the first major accomplishment I made in the SharePoint space: The Hybrid Provider. This little puppy is a custom authentication provider for SharePoint 2007 that allows simultaneous authentication, authorization, and profiles for both Active Directory and Forms (SQL) users against the same web application. This made a big splash, as not only was the ASP.NET provider infrastructure new in the 2.0 timeframe, but making it work with SharePoint was a very difficult challenge.

And as we all migrate over to 2010, we explore the familiar paradigm of transitioning our expertise from the old tried-and-true techniques to the new and exciting ones. I am always interested to see functionality that used to require a ton of customization to work the way you wanted it to now magically working out of the box. Would custom authentication be gobbled up by SharePoint 2010, thus rendering the Hybrid Provider retired?

Well the answer is...sort of. There's this new "Claims" thing, replacing, at least semantically, "Forms" authentication, and bringing with it a new architecture for authentication. Gone are the days of having to extent your web app to another zone if you wanted to implement an out of the box extranet. What happens now is a "pre-login" page that gives you a drop down to select the authentication mechanism (namely, Windows or Forms), and based on that selection, the AutoPostBack on the drop down will either pop up the Windows NTML dialog or redirect you to the login page.

Although it's cool to see "first class citizen" support for dual authentication, this extra step is still a kludge, and therefore there's still room for the Hybrid Provider. However, this post isn't about the Hybrid Provider, mainly since the MembershipProvider abstract class hasn't changed in .NET 4.0; the old code will still work in SharePoint 2010. The difference, however, is in the configuration and architecture that a custom authentication has to adhere to in the new environment. Therefore, I instead want to talk about how to get this stuff working in general, weather you're using the out of the box SqlMembershipProvider, the Hybrid Provider, or your own creation.

This gives us two topics to discuss. First, we need to understand the new Claims-based Authentication at a high level, and then dig into the nitty-gritty details of what you need to do to get your provider all wired up.

SharePoint 2010 Claims Authentication

Following the paradigm shift from SSPs to Service Applications, authentication has been "offloaded" to the "Security Token Service Application." The "STS" (as it's known) is one of those service applications that has no configurable properties. (When you select it in Central Admin, the "Properties" and other Ribbon options are disabled.) This is, as far as I'm concerned, both good and bad: good because there's nothing extra there to break; bad because there's nowhere to go to fix it when it indeed is broken.

Behind these ominous scenes, the STS is just a WCF service, hanging out in "14\WebServices\SecurityToken." They way this works is that SharePoint routes all authentication through this service. Whenever anyone logs into anything, STS is the mechanism giving users the nod. Now, the web applications are still operating as normal ASP.NET sites; authentication, authorization, forms, etc. (in terms of configuration) don't change. It's just that instead of code running the web app to do the work, a service call is made instead.

So architecturally, this is really the only big change. In 2007, each web app (Central Admin included) did its own thing for auth. 2010 has now integrated this into its service application layer, with all web apps plug into.

However there is one caveat that will lead us into the second part of this post which covers implementation. Even though the STS handles authentication, web apps are still on their own to implement all other user-centric functionality. The best example is the PeoplePicker. Despite the PeoplePicker depending on the very same mechanics as the STS' authentication and authorization do, it's not actually doing authentication or authorization; it's simply querying into these interfaces against our user store (weather it's AD, SQL, etc.).

What does this mean to us? Basically, when implementing custom authentication or authorization, the STS is what needs to be configured to talk to the ASP.NET MembershipProvider. However, any web app that needs to interact with these users, be it searching within a PeoplePicker, adding users to a group, or granting people Site Collection Administrator permissions in Central Admin, needs to be configured to use the authentication provider as well.

Just not for authentication.

So in SharePoint 2010 Claims-based Authentication, there are now three places you need to go to configure a custom authentication provider (verses just two in 2007): the web application itself (to allow permission and security functionality to work), Central Admin (to implement the provisioning of Site Collection Administrators and other more global user management tasks), and STS (which, again, is doing the actual authentication).

Before we move on to the implementation, I want to briefly discuss some semantics. As it stands, offloading authentication across the farm to the STS does not constitute "claims" authentication all the way. In claims (with a lower-case "C") auth, you provide your credentials to a third party "issuer" who authenticates you and gives you (or your session) a token. It is this token that you give to the actual site or application.

So STS is the first "half" of this paradigm. What about the token? That is abstracted to us, and SharePoint wires up its own "claims" provider that does this work for us. We're using claims auth without having to worry about anything beyond forms auth!

To summarize:

Forms authentication is configured for the web app, so it knows to provide a login page to you.
The login page passes your credentials to STS.
STS uses our custom provider to authenticate you and issues back a token.
This token is sent to the web app, which uses the SPClaimsAuthMembershipProvider and SPClaimsAuthRoleProvider to process the token and use it for final authentication and authorization respectively.
The web app then uses the custom provider directly to power user-centric functionality, such as the PeoplePicker.

Implementing a Custom Claims Authentication Provider

So what do we have to do? Here's the good news: not much, from a technical perspective, has actually changed! Like I said in the previous section, the code is identical, so if you're migrating from 2007, just GAC your DLLs. As far as Central Admin is concerned, configuring the Authentication Provider for your web app basically mirrors what you had to do in SharePoint 2007. In fact, other than having to deal with a third web.config file, you still wire up your custom provider in pretty much the same way.

So the only new task we have is dealing with some of the nuances of what SharePoint 2010 needs. In 2007, once you got one web.config wired, you could copy-and-paste it around. The major difference here is that each web.config file (STS, Central Admin, and each web app) varies slightly in what you have to do. So let's dive into that.

Take very careful notice of the usage of <clear /> in the following web.config snippits. This is very important, and SharePoint 2010 requires it in certain scenarios.

</Important Note>

Web.config for Web Applications (In virtual directory)

Membership
- Clear
- Add SPClaimsAuthMembershipProvider
- Add Custom Membership Provider
- Set SPClaimsAuthMembershipProvider as the default
Role Manager
- Clear
- Add SPClaimsAuthRoleProvider
- Add Custom Role Provider
- Set SPClaimsAuthRoleProvider as the default



	<membership defaultProvider="i"> <providers> <clear /> <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add connectionStringName="AspNetSqlProvider" passwordAttemptWindow="10" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" description="Stores and retrieves membership data from the Microsoft SQL Server database" name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </membership> <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All"> <providers> <clear /> <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="AspNetSqlProvider" applicationName="/" /> </providers> </roleManager> <connectionStrings> <add name="AspNetSqlProvider" connectionString="Data Source=SHAREPOINT2010;Initial Catalog=TestProvider;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>

Web.config for Central Administration (In virtual directory)

Membership
- Clear
- Add Custom Membership Provider
- Set Custom Membership Provider as the default
(NO Role Manager)



	<membership defaultProvider="AspNetSqlMembershipProvider"> <providers> <clear /> <add connectionStringName="AspNetSqlProvider" passwordAttemptWindow="10" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" description="Stores and retrieves membership data from the Microsoft SQL Server database" name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </membership> <connectionStrings> <add name="AspNetSqlProvider" connectionString="Data Source=SHAREPOINT2010;Initial Catalog=TestProvider;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>

Why no Role Manager in Central Admin? Well, because it doesn't work. The behavior I've seen is that, when you have a role provider configured in Central Admin, although you can log in to the site, certain links to interior pages challenge you for credentials, which then always fail. Take the role provider out and everything works again.

I don't have any good technical reasons why this is the case, but the only thing I can think of at all is that the role manager interferes somehow with the Windows auth. In the custom provider scenario, Central Admin is the only web app actually using OOTB authentication, so at least that makes sense given it's the only web app with no role manager configured.

Either way, this isn't a big deal, since we are not using a custom provider to log into Central Admin, and all user-centric functionality you'd do there doesn't really need a role manager. Personally, I only use Central Admin to grant the first SQL user Site Collection Administration permissions, so I can log into the actual web app as that user, and go all my group stuff there.

Web.config for STS (In 14\WebServices\SecurityToken)

Membership
- Clear
- Add Custom Membership Provider
- Set Custom Membership Provider as the default
Role Manager
- Clear
- Add Custom Role Provider
- Set Custom Role Provider as the default



	<membership defaultProvider="AspNetSqlMembershipProvider"> <providers> <clear /> <add connectionStringName="AspNetSqlProvider" passwordAttemptWindow="10" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" description="Stores and retrieves membership data from the Microsoft SQL Server database" name="AspNetSqlMembershipProvider" type="YMCAProvider.YMCAMembershipProvider, YMCAProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bf6b2d725b284803" /> </providers> </membership> <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All"> <providers> <clear /> <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="AspNetSqlProvider" applicationName="/" /> </providers> </roleManager> <connectionStrings> <add name="AspNetSqlProvider" connectionString="Data Source=SHAREPOINT2010;Initial Catalog=TestProvider;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>

Note that the connection strings are added for reference only; they do not belong in the System.Web section of course. Also, I used the SQL Membership Provider here as an example. You can do whatever is necessary to wire up your own provider. But that's about it! Hopefully this helps demystify not only one of the most intense configurations involved in a custom SharePoint component, but Claims authentication in general.

Have fun!

The Truth About How Daily SharePoint Alerts Actually Work

2010-08-26T16:26:00Z

A document changes.

An Email gets sent.

What could be easier?

Well, off the top of my head: open-heart surgery, underwater basket-weaving, and giraffe tooth-brushing to name a few things. SharePoint alerting architecture is a powerful communications tool that provides a convenient mechanism for users to consume information from around the site.

That is, if you don't mess with them.

But of course, we are going to mess with them. We want to control the time, frequency, and appearance of the Emails. The default out-of-the-box settings work, but not quite well enough. All that my client wanted to do was simplify (not go nuts, but simplify ) the standard digest (daily) Email template, and have the notifications shoot out at 9:00 AM. I estimated about a day to do this.

All we had to do was comment out some CAML from the alerttemplates.xml file (located in 12\TEMPLATE\XML) and run an STSADM command, right? Remove the links and columns that they didn't want in the template, and set the time when alerts go out. RIGHT?

WRONG!

To make a story that is longer than it is interesting shorter and more interesting, we went from OOTB alerts to a custom template to a custom handler using IAlertNotifyHandler to alerts not working for a month to users getting Email bombs of duplicate alerts. We went through three different solutions, two different Microsoft support representatives, and one scary spelunk into the SharePoint database. However, we came out safe and sound on the other side, with a cathartic clarity around how SharePoint daily alerts actually work. It wasn't a perfect outcome; there was quite a bit of drama, but a happy client is a happy client.

What I'm not going to do is take you through all the steps required to either customize an alert template, or wire up a code handler to build the Email from scratch (which is what I opted for, since alerttemplate.xml is 10,211 lines long and besides I really like writing code). Someone already did a good enough job of that here.

Instead, I want to provide a high level description of how SharePoint 2007 alerting infrastructure is put together. As I dug though the dumpsters of the Internet looking for any clues to this end, I heard a lot of rumors and false positives and frightening tales. I also came across a new golden nuggets, either from dependable sources, my own research, or the words from Microsoft's mouth itself. So what I'm going to do is simply list out the pieces that work together to make alerts work, having already scrubbed out all the wrong turns I made while traversing down this path.

So here are the truths about daily alerts, in Q & A form...

Which timer job executes daily alerts?

The "Immediate Alerts" job.

Wait isn't that job that runs the immediate alerts?

Yes.

So the one job handles all alert notifications?

Yes.

There is no "Daily Alerts" job?

No.

Promise?

Promise.

Which server physically executes this job?

Officially: All timer jobs run on all front end servers. So any web front end (or indexer, as I've seen) that has the proper assets deployed to it for a particular timer job (DLLs, XML files, etc.) can execute it successfully. Unofficially: not really; even though Central Administration -> Operations -> Timer Job Status reports that the Immediate Alerts job runs on all servers, only one is actually doing the work.

To determine which one, you have to dive into the database. I know. It's ugly; it hurts. Shush. Run the following query against the content database for your web application:



	SELECT * FROM TimerLock

What this does is return the one and only row there will ever be from this table. The two columns are a name of a server, and a date. All we really care about is the name of the server: this is the one that's going to do the notification work. If you want to change it to another server, stop the "Windows SharePoint Services Timer" service on this box, and wait for another server to jump in and acquire this lock.

When do daily alerts get sent?

OOTB, alerts are enabled, and the Immediate Alerts job runs every five minutes. What these runs do is ask the question: Are there any alerts that want to be sent out, but haven't been? All alerts that answer "Yes!" get sent out.

So how do daily alerts know that they want to be sent?

Every alert has a time. For daily alerts, this time defaults to one day (or, more accurately, 24 hours) from the instant they are created. If you create an alert OOTB, you can select an hour on the UI, and the alert will be sent 24 hours from that time. In either case, this "Alert Time" is stored as a real, absolute time, not a TimeSpan.

So every time the Immediate Alerts job runs, it checks for alerts whose time is less than the current time. For each one, it fires the Email, and increments this time by another 24 hours.

What about the job-immediate-alerts property?

All this does is regulates how often the Immediate Alerts job runs. This has no effect if alerts are disabled (the "alerts-enabled" property is set to false). Remember, these properties are specific to a web application.

And what about the job-daily-alerts property?

The main purpose of this property is to confuse the hell out of everyone. This command has been deprecated since SharePoint 2003, but was never removed from the command line.

It has NO effect.

On anything?

NOTHING. Don't ever think about it. Ever.

So in summary?

In summary, alerts store the next time they want to be sent. Every execution of the Immediate Alerts timer job on the server that has acquired the "TimerLock" (for that content database) will send any daily alerts whose time is in the past. Finally, it will increment these times by 24 hours.

Anything else?

Now, there's one other phenomena that I've observed with all this alert stuff: duplicates. And just duplications, but DUPLICATES - as many as a half dozen extra Emails per each unique notification. The most bizarre case we saw was when a user had an alert against a document library that saw five changes in one day, and he received five Emails: one with all five changes listed, one with only the first four, and so on, down to one Email advertising just one change.

What was causing the duplication? The prime suspect was of course the customization of the template, which, admittedly, had a bug, and was broken for some time: there were no alerts for weeks. But eventually I fixed it, and proved it by writing to the ULS logs each time the handler was invoked. And indeed, it was called exactly once for each Email the aforementioned user received. So why was one alert sending out so many notifications?

The most bizarre aspect of this problem was how it was solved, because it solved itself. It was as though the SharePoint alerting infrastructure had a cold: it got worse and worse, barfed, and then started to get better and better. Seriously. My user reported that he got fewer and fewer duplicates each day, until it completely worked itself out and only sent out one notification per alert; each Email containing a list of changes that that document library had experienced over those last 24 hours.

Of course this is unsettling; problems that solve themselves usually have the propensity to start themselves back up. I had a hunch, and I don't blog about hunches. However, I will blog about hunches that Microsoft Premier Support endorses!

<HUNCH>

First, a bit of background: there is another database table that people seem to get their hands dirty with when it comes to fixing alerts: EventCache. What from I can tell, this is the backlog of all changes made to all document libraries. We can then think of alerts as sort of queries into this table. Once an alert gobbles up a change, that change is marked as processed and won't be alerted against again.

Therefore, a daily alert notification is actually the intersection of all unique changes that an alert (which is welded to a document library) "finds." What happens if those changes in EventCache are never processed? They are dangling there, like icicles, waiting to melt back down to the ground. If alerts are broken, these changes seem to just stack up.

Eventually, when alerts are fixed, that stack will topple. It will be like unclogging a drain. However, that's not what happened. The Email duplications diminished slowly, as if each alert could only pull changes from one day at a time. In other words, the alert, when activated by the Immediate Alerts job, doesn't seem to blindly ask EventCache for "all unprocessed changes for this document library" (as I would assume) but rather for "some 24 hour block of changes." Maybe it's that timeframe that gets out of whack, and changes from two different days are processed in the same batch. Or perhaps the logic is flawed, and times aren't updated properly if the notification system is malfunctioning due to a bug somewhere in the template customization.

It still makes more sense to me that, once repaired, all notifications will be shot out in the next batch. Furthermore, I think it's counterintuitive that "old" changes should be notified at all. If a user hooks up an alert, they want new information - new content. The apropos availability of old news isn't new news.

</HUNCH>

Each day as the alerts were "worsening" and then "healing" themselves, my client user forward me all the Emails he got. So did another user, who only had one alert, and only got dups sometimes. The point is that there were no discernable patterns. I poured over the frequencies among alerts, number of Emails, and number of changes in each Email, but came up with nothing. I spent hours digging though verbose ULS logs, only to further validate that my custom handler was called exactly once per whatever it was that SharePoint was detecting as a notification.

When my Microsoft rep backed up the above hunch, I was encouraged, but not satisfied. Unfortunately, this remains a mystery to this day. Microsoft closed the case without any more discussion. My client closed the bug without any more discussion. It's like everyone but is happy that this one little bug - which was only supposed to take a day to implement - has magically disappeared.

Well it's time for me to join their ranks, as there is no more time, money, calories, or sanity to invest into the duplicate alert issue. Usually my posts have happy endings, but alerts are emo like that. If anyone out there has any ideas, please don't hold back. Hopefully I was able to at least help a little bit in terms of cracking open the black box of enigmatic SharePoint 2007 daily alerts.

The SUESS Lifecycle: Stage 2 - Encode

2010-08-23T21:09:00Z

The SUESS Series
Introduction
Stage 1 - Upload
Stage 2 - Encode
Stage 3 - SmoothStreaming

Introduction

Anatomically speaking, Encoding is the heart of SUESS. (I guess, to stretch out the metaphor, that makes Silverlight the head, SmoothStreaming the eyes and ears, and I guess Uploading the digestive system.) Encoding, implemented via Expression Encoder, is what makes the process of media uploading feasible to end users.

By "feasible" I really mean "usable" - people want online functionality to be really easy to understand. Usability 101 tells us that the more hoops people have to jump through, the less inclined they will be to use your site, regardless of how pretty the UI is. The hoops here are presented by the fact that Silverlight does not support every media format under the sun. We can't simply upload a random file and then watch it; Silverlight has to "know" how to play it.

Do you think if people could only upload Flash media to YouTube it would have been nearly as popular? Of course not. I'm surprised that abilities like uploading media and capturing live web cam feeds are exoteric enough for the general Internet-goer. But encoding a movie or image? Not only is it an extra hoop, but it's simply too much to expect from a user.

By automating the encoding process, we can enable people to provide IIS SmoothStreaming media to their website's audience with just as much effort as it would take to upload an image. SmoothStreaming itself is the other side of the coin: we need to encode anyway if we want to take advantage of this new media streaming technology! So by putting in all this effort to solve these intrinsic media usability problems (large files, wide arrays of formats, etc.) we are awarded by having the otherwise heavily-guarded SmoothStreaming gate automatically unlocked for us! (See the final post on SUESS for more information about IIS SmoothStreaming; we still need to open the gate, of course!)

Those are the two reasons why we encode. The next question, which leads us into our architectural discussion, is of course: how? I went with Microsoft Expression Encoder 3.0 (4.0 was still in beta during development). Here are some of the determining factors that lead me to this decision:

.NET API that exposes progress events
Much wider file support than native Silverlight
Explicitly supports encoding to the IIS SmoothStreaming format

And, I didn't feel like dealing with the Media Player SDK, buying and kluding a third party control, or reverting back to a "Web 1.0" paradigm of an upload screen that says something like "Thank you for uploading your media. Please try back later to see it when it's done because we couldn't figure out a more elegant way to implement our site's media administration."

I wanted this to be first class.

Architecture

Let's start by first taking a look at the detailed architecture of the Encoder. Back to everyone's favorite Visio diagram:

Basically, there are three major sub components running on the Media Server tier of SUESS. (And boy am I ever excited to have built something complex enough to have "sub components!") The first one is the Media Service WCF endpoint. This is a standard WCF service that, after the Silverlight client completes the Uploading phase of SUESS, it calls to kick off the encoding process.

The interface for the Media Service is very simple, containing only two methods: Encode and Cancel. I tried to choose really intuitive names here; "Encode" performs the encoding, and "Cancel" cancels it. Encode wraps the Expression APIs and does all the work needed to get our media into the IIS SmoothStreaming format.

There is also a web.config file that goes along with the Media Service to store the application settings (along with all the WCF goo). These dictate the size of the thumbnail images, and the locations of both the temporary upload path for our raw media files as well as the destination for the IIS SmoothStreaming-formatted files. These settings, combined with the file name passed in from the Uploader, is all the Encoder needs to do its thing.

There is one more quite architectural consideration to point out before we jump into code. The Expression Encoder APIs are 32-bit only. This is generally not an issue if you are hanging out in 2007 or earlier, because starting with Windows Server 2008, 64-bit has become the de facto standard in making developers crazy. That's not to say that 32-bit applications won't work; .NET handles all of that "WOW" stuff for us.

However, when you try to have a 64 bit process (such as a Windows Service, or an ASP.NET app like SharePoint) call into the 32 bit Encoder DLLs, things die. If your first instinct (like mine) was to compile the Media Service using Visual Studio's "x86" or "Any CPU" configurations, you won't get there. The problem isn't that one piece of code can't talk to another; it's that the entire process needs to be in the same architecture.

So to circumvent this, we need to be running our entire stack in 32-bit mode. Whether it's a Windows Service set explicitly to compile to x86 or a 64-bit IIS application pool that has 32-bit support enabled, since Encoder requires us to be in 32-bit world, we need a 32-bit process. The clear choice here is to use IIS and flip one setting (App Pool -> Advanced Settings -> Enable 32-Bit Applications -> True) verses going through all the hell of building, deploying, and configuring a Windows Service.

<RANT>

Windows Services suck.

</RANT>

Media Encoding

The second sub component is the Encoder API itself. Let's look at the Encode method first to get an idea of everything that's going on programmatically. Then, we're going to jump back to the WCF side of things are discuss the bi-directional communication (awesome).



	public void Encode(string fileName, string quality) { //initialization string uploadPath = string.Empty; this._client = OperationContext.Current.GetCallbackChannel<IEncoderClient>(); try { //create new encoder job this._job = new Job(); this._job.CreateSubfolder = true; int size = this.GetThumbmailSize(); this._job.SaveJobFileToOutputDirectory = false; this._job.OutputDirectory = this.GetMediaPath(); uploadPath = Path.Combine(this.GetUploadPath(), fileName); //complexity VideoComplexity vc = new VideoComplexity(); switch (quality) { //determine quality case "Best Quality (Slowest Upload)": vc = VideoComplexity.Best; break; case "Better": vc = VideoComplexity.Better; break; case "Good": vc = VideoComplexity.Good; break; case "Normal": vc = VideoComplexity.Normal; break; case "Low": vc = VideoComplexity.Fast; break; case "Lowest Quality (Fastest Upload)": vc = VideoComplexity.Fastest; break; default: vc = VideoComplexity.Normal; break; } //smooth streaming video AdvancedVC1VideoProfile videoProfile = new AdvancedVC1VideoProfile() { Complexity = vc, AdaptiveGop = false, SmoothStreaming = true, }; //streams videoProfile.Streams.RemoveAt(0); videoProfile.Streams.Add(new ConstantBitrate(600, false), new Size(400, 300)); videoProfile.Streams.Add(new ConstantBitrate(1050, false), new Size(640, 480)); videoProfile.Streams.Add(new ConstantBitrate(1450, false), new Size(800, 600)); //crappy aduio WmaAudioProfile audioProfile = new WmaAudioProfile() { Channels = 2, BitsPerSample = 16, SamplesPerSecond = 44100, Bitrate = new ConstantBitrate(64, false) }; //create media item MediaItem mi = new MediaItem(uploadPath) { ThumbnailCodec = ImageFormat.Jpeg, ThumbnailMode = ThumbnailMode.FirstFrame, ThumbnailSize = new Size(size, Convert.ToInt32((size / 1.3))), OutputFormat = new WindowsMediaOutputFormat() { VideoProfile = videoProfile, AudioProfile = audioProfile } }; //hook events this._job.EncodeProgress += new EventHandler<EncodeProgressEventArgs>(this.Job_EncodeProgress); this._job.EncodeCompleted += new EventHandler<EncodeCompletedEventArgs>(this.Job_EncodeCompleted); this._job.StartFileEncoding += new EventHandler<StartFileEncodingEventArgs>(this.Job_StartFileEncoding); //encode this._job.MediaItems.Add(mi); this._job.Encode(); } catch (Exception ex) { //error string error = string.Format("The following error occured while encoding {0}: {1}", string.IsNullOrEmpty(uploadPath) ? fileName : uploadPath, ex.ToString()); EventLog.WriteEntry("EncoderService.Encode", error, EventLogEntryType.Error); this._client.EncodingError(error); } finally { //clean this._job.Dispose(); } }

The main workhorse of the Expression Encoder API is the Job object. I couldn't find any formal documentation on the API, so I sort of reverse engineered it by mapping class names in Visual Studio to menu options in the Encoder product. Whenever you encode something using the application, you create a new "Job" and set a bunch of options on it. This is pretty much the same way I learned SharePoint many years ago; the Encoder API, although undocumented, is more intuitive than SharePoint's, so I was able to hack my way though it a little easier.

So let's take a look. Line #5 is the WFC bi-directional stuff, which we'll look at in a bit. Line #9 instantiates our Job object. It's global in the service because, skipping down to Lines #75-77, where we hook the events, we need to refer back to properties on the Job object. Again, we'll look at the event handlers themselves when we move back from the Encoder to the WCF/Silverlight communication logic. Lines #10-14 round out the Job initialization code, calling helper methods that simply grab values from the web.config file.

Starting at Line #16, we get into the meat and potatoes of media side of the Encoder API. Encoder allows you control a vast array of characteristics of an encoding process. The first one here is the video complexity (which I covered in the Uploader post). Basically, this enumeration dictates an arbitrary ratio between video quality and encoding speed. While this particular property is a bit black-box-ish, (I couldn't track it down in Reflector) the rest that we're going to look at really show how much control you have over your users' viewing experiences.

Basically, an Encoder Job needs three pieces of information to encode media: a VideoProfile, an AudioProfile, and a MediaItem. The VideoProfile has information of the "target" video properties; same deal with the AudioProfile. The MediaItem combines the two profiles, as well as contains a myriad of properties pertaining to things such as thumbnail information, markers, general media settings, audio overlays, and on and on.

Let's pick back up with the code at Line #43. An AdvancedVC1VideoProfile is one of many classes that is derived from a deep inheritance tree originating with VideoProfile. All of these classes correspond to options available in Expression Encoder's UI. Without going into too much detail, the type initializer made up of Lines #45-47 basically tells the Encoder API to encode into the IIS SmoothStreaming format using the "Advanced" VC1 codec presets.

Each class derived from VideoProfile adds lots of different options that allow you to tweak your output video format according to your requirements. If we were supporting "straight" HD Silverlight video, we'd probably use the MainH264VideoProfile instead. Note that setting the "SmoothStreaming" property to true on any VideoProfile derivation simply "enables" the IIS SmoothStreaming output format; the files themselves will adhere to which ever video codec you assign them, based on the profile you select and properties you set. And if you enable SmoothStreaming, there are other properties that need to be set a certain way. I haven't dug too deeply on this, but don't worry: the exception details you'll get are description enough to guide you through the programmatic configuration of your video profiles.

With the profile out of the way, we now need to tackle the SmoothStreaming aspect of the video. Check out Lines #50-54. This is great example of what IIS SmoothStreaming is all about. If I had to describe this format in one sentence, it would be thus: The focus is on dynamically assessing the bandwidth of the connection between the Silverlight client and IIS Media Services 3.0 server, and selecting the correct quality version of the requested media.

The aforementioned lines of code determine how many different options we are giving IIS Media Services to work with when it determines quality, and what each option, or "Stream," can deliver. First, Line #50 clears out the "default" stream that "comes with" the AdvancedVC1VideoProfile instance. This is a best practice. Next we need to define our own streams. As you can see from the code, a stream is made up of a bitrate and a size. The next three lines then each define streams of increasing sizes (and therefore qualities) while maintaining a native 4:3 aspect ratio.

So let's dig, taking the second parameter fist. The "Size" portion of a stream is easy enough to understand: a movie that's 800x600 natively will look better in a standardly-sized player than one that's 400x300. But since more pixels are crammed into the same space, the file is denser, and therefore larger on disk. This requires more bandwidth to be pushed down in a timely manner that keeps up with the bitrate. The smaller file has fewer pixels and less quality, and requires less bandwidth to deliver.

Cool. So what's a bitrate? Well, that's a "bit" more complicated. Sorry. There are two types in the Encoder API: VariableBitRate (with its few derivations) and ConstantBitRate. I'll let Wikipedia do the honors here, but at a high level, different segments of a media file have different complexities. If the movie starts out blank with no sound for a few seconds, those frames are very "small" compared to frames later in the movie that have high-speed motion or explosions. These portions of the file have a lot more detail.

A variable bitrate allows the file to sort of throttle itself, so that "easy" portions (like all black intro frames) can transmit over the wire at lower speeds, but more "complicated" segments can start sprinting and stream and higher rates. The drawbacks? Larger files and longer time needed to encode. By comparison, a constant bitrate "forces" every segment of the file to have the same quality. Of course, this is much simpler logic, and transfers at a constant speed making IIS Media Services' life easier, but those aforementioned "more complicated" portions of the film will be scaled back to meet the constant bitrate.

So when you choose the bitrate that works for your situation, you can choose from goodies such as: VariableUnconstrainedBitrate, VariableConstrainedBitrate, VariableQualityBitrate, and ConstantBitrate. You can discern among these by the parameter that each class takes. The code sample uses ConstantBitrate, because SUESS was first created for a SharePoint intranet, where we had complete control over network bandwidth. IIS SmoothStreaming was key in general because the client had offices all over the world, but beyond that, we pushed for speed over quality.

Once thing to note about ConstantBitrate: even though it yields a leaner, faster format, it could take longer to encode! By default, Encoder will make TWO passes through the file, essentially doubling the time it takes to encode. The first pass determines the average bitrate across the file, and the second pass actually does the work with the correct average. That's what the false parameter in the ConstantBitRate constructor in Lines #51-53 controls; it tells Encoder to use the BitRate passed in and to not worry about being too fancy about it.

And that's just the video; audio is a separate story in the media world. When watching any modern media (Film, DVD, Web, etc.) you're actually watching a video track and listening to an audio track - separate from each other - that both started at the same time. In much the same way video was configured with bit rates and quality settings, you can customize the audio portion of SUESS to the same extent.

I won't go into nearly as much detail for audio, because it's really the same idea. In fact, the concepts of profiles, bitrates, and customizable quality settings all work exactly the same; there's just different types (and actually, the bitrates are identical). So you can play around with these settings the same way we played around WAV files ripped from CDs back in Windows 95!

In this example, (which again was for an intranet project) I sacrificed audio quality so I could push as much video through the pipes as possible. What's interesting is that the same audio settings are applied to each video stream; in other words, SmoothStreaming only considers video, and pushes the same audio profile irrespective to which quality it detects. Lines #55-61 configure the audio in the above code example.

Finally we have the MediaItem, which acts as a single encoding "task" for our Job object to perform. If you add multiple MediaItems to the Job (or even if our service gets a request while another encoding operation is in progress) they will queue up and finish in series, so that your processor doesn't have a heart attack.

As I alluded to before, the MediaItem houses the video and audio profiles and collects the rest of the data that tells the Job exactly what to do. For my purposes, which was more to the end of allowing pervasive formats and maximum performance verses actual media processing (I'm a developer, not a DeeJay) I was able to configure everything I needed media-wise in my profiles. However, I again encourage you to experiment with the vast array of options available on MediaItem; the API is extremely powerful!

The only additional customization I needed to do on the MediaItem was to define how to pull a thumbnail from the uploaded media. I new up my object on Line #63, passing it the string path of the final upload destination for the file. Then, Lines #65-67 define how I want my thumbnail to be generated. In this example, it's a 4:3 JPEG of the first frame. The file will be saved in the same directory as the SmoothStream files.

And that's about it! Lines #68-72 pull my video and audio profiles together into an OutputFormat. I'm using WindowsMediaOutputFormat because that's the one directly compatible with Silverlight. There are a few others you can play with, primarily if you are doing Live encoding. This is a bit confusing, since we've been talking about SmoothStreaming this whole time, but now we're telling the Job to dump out a WMV? Think of it this way: we are encoding for Silverlight, so Windows Media is the best option. SmoothStreaming is special type of format for WMV that IIS knows how do all the fancy streaming with.

The code block ends with hooking the events, adding our MediaItem, and then calling Encode! We'll check in with our events in the next section. One quick thing to note is that some operations around MediaItem can take a while (seconds or longer) to execute, so plan your progress bars as necessary. Watch how the Expression Encoder product does its thing. When you select a new file to encode, it chugs for a bit as it pulls thumbnails, applies default profiles, etc. So if you don't start your progress bars until the first progress event fires, your users might think you app is hung while they wait for the Encoder API to warm up!

Silverlight 4 / WCF Bi-Directional Communication

.NET RIA Services is cool. Web cam integration is fun. File drag & drop is neat. But as someone who pays for his drinks by building business applications, I have to say that support for the WCF bi-directional HTTP Polling Duplex binding is my favorite new Silverlight 4 toy. AJAX greatly improved UX by eliminating post backs and making it easy to implement "please wait" functionality while the page churned. Silverlight takes us further by allowing real time progress bars during long-running processes.

Finally, we can do serious work on the web.

So how does this bi-directional stuff work? First of all, it's still straight WCF: contracts on the server, proxies on the client, and tons of glue in the web.config file. The ServiceContract works the same way, exact that you add a reference to a second ServiceContract that acts as the CallbackContract. What this means is that we have a normal ServiceContact that guarantees certain methods are available on the server. The second ServiceContact (which is a separate interface) defines certain events that the client can handle; in other words, the server can basically call methods on the client!

Well, not really: when the client makes the first call, it keeps a channel open with the server, through which it "polls" [hence the name] - asking the server constantly if something has occurred. When the server raises notification that something has indeed happened, the corresponding event is fired. The cool thing about this is how WCF abstracts away the hairy details, and lets us work in the comfortable event-driven programming model.

Let's look at some code. First, here are the contracts:



	#region Server [ServiceContract(CallbackContract = typeof(IEncoderClient))] public interface IEncoderService { [OperationContract(IsOneWay = true)] void Encode(string fileName, string quality); [OperationContract(IsOneWay = true)] void Cancel(); } #endregion #region Client [ServiceContract] public interface IEncoderClient { [OperationContract(IsOneWay = true)] void EncodingProgress(double progress, string timeRemaining); [OperationContract(IsOneWay = true)] void EncodingStarted(); [OperationContract(IsOneWay = true)] void EncodingCompleted(string jobId); [OperationContract(IsOneWay = true)] void EncodingError(string errorText); } #endregion

Like I said this is pretty much straight WCF. The only additions are in the attribution. The main "new" concept is the "CallbackClient" in Line #2. This basically tells the service what "methods" it can "call" on the client. You'll also notice a lot of attribution setting the IsOneWay switch to true. This enables the "event-driven" style we discussed earlier. Even if methods return voids, if IsOneWay is false, the server is still expecting a reply message form the client. This behavior is more client/server than event-driven, and breaks the duplex model.

Next, let's look at how we define our "global variables." The first one in the code below is our Encoder Job object, which like I said is "global" so that I can more easily reference it in its events. The second one is our Encoder client interface (of type, well, IEncoderClient of course). Line #6 (which is an excerpt from the Encode method in the first code sample [Line #5 there]) shows how we can grab a proxy to our client using the OperationContext. This is a magical call that, when invoked inside a method corresponding to one of our service's operation contracts, "knows" about the client who called it.



	#region Members private Job _job; private IEncoderClient _client; #endregion //this next line is at the beginning of the Encode method from the first code listing in this post this._client = OperationContext.Current.GetCallbackChannel<IEncoderClient>();

Now that we have a solid reference to our client, we can call methods on the global _client interface, and the corresponding events will be raised and handled as normal WCF service events down on our Silverlight clients. Beautiful. Finally, let's look at one of these duplex method calls from both the server's and client's perspective. The example I'll use here is the Encoder API's "EncodeProgress" event. First, the event handler to what we hooked in Line #75 from the first code listing in this post:



	private void Job_EncodeProgress(object sender, EncodeProgressEventArgs e) { //get progress time TimeSpan sp = this._job.MediaItems[0].FileDuration.Subtract(e.CurrentPosition); //call client this._client.EncodingProgress(e.Progress, string.Format("{0}:{1}:{2}", sp.Hours.ToString("00"), sp.Minutes.ToString("00"), sp.Seconds.ToString("00"))); }

The Encoder API gives us a lot of information in the EncodeProgressEventArgs parameter. However, as I defined my IEncoderClient interface, I'm only interesting in the percentage done and the time remaining. So Line #3 subtracts the current time position of the Job from the total duration of the first (and always only) MediaItem and that's the time remaining. I pass the progress straight through to Line #6, which actually fires this event on the client. Speaking of the client, let's see what's going on in the Silverlight side of things to bring this full circle.



	private void svc_EncodingProgressReceived(object sender, EncodingProgressReceivedEventArgs e) { //animate value Utilities.AnimateDouble(this.pbUpload, e.Progress, "Value").Begin(); //update text this.tbProgress.Text = string.Format("Encoding file... {0}%", Math.Round(e.Progress, 1).ToString("#0.0")); }

As you can see, this is very standard WCF/Silverlight functionality. The UI is updated with values that the server sends down. And since this event is hooked the same exact way as any other WCF method (just get a reference to the service proxy object and wire up an event handler) we are guaranteed to be on the UI thread when we update controls. It's...and I'm getting emotional here...just beautiful...

The last thing we need to talk about is the configuration. Did you think we'd talk about anything WCF related and not have to dig into a web.config file? Actually, like everything else we've discussed on Silverlight side of the Encoder stage, there's nothing new, per se; just additional. Since the Polling Duplex binding didn't ship with Silverlight 4, (and if your service is still in .NET 3.5.1) we need to manually reference it.

First, we need to get the correct WCF assembly. Once you install all the latest bits for the Silverlight 4 developer run time, go to this folder on your development box (assuming it's an x64 OS): C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries (and then either the \Client or \Server folder). Grab the appropriate DLL (System.ServiceModel.PollingDuplex.dll) and reference the "client" version in your Silverlight project and the "server" one in the WCF project.

Now, let's look at the server side web.config file:



	<?xml version="1.0"?> <configuration> <appSettings> <add key="ThumbnailSize" value="400"> <add key="MediaPath" value="\\DatabaseServer\Media"> <add key="UploadPath" value="\\DatabaseServer\Temp Uploads"/> </appSettings> <system.serviceModel> <extensions> <bindingExtensions> <add name="pollingDuplexHttpBinding" type="System.ServiceModel.Configuration.PollingDuplexHttpBindingCollectionElement,System.ServiceModel.PollingDuplex, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> </bindingExtensions> </extensions> <bindings> <pollingDuplexHttpBinding> <binding name="multipleMessagesPerPollPollingDuplexHttpBinding" duplexMode="MultipleMessagesPerPoll" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" receiveTimeout="01:00:00" closeTimeout="01:00:00" openTimeout="01:00:00" sendTimeout="01:00:00" inactivityTimeout="01:00:00" /> </pollingDuplexHttpBinding> </bindings> <services> <service behaviorConfiguration="Services.Media.EncoderServiceBehavior" name="Services.Media.EncoderService"> <endpoint address="" binding="pollingDuplexHttpBinding" bindingConfiguration="multipleMessagesPerPollPollingDuplexHttpBinding" contract="Services.Media.IEncoderService"> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"> </service> </services> <behaviors> <serviceBehaviors> <behavior name="Services.Media.EncoderServiceBehavior"> <serviceMetadata httpGetEnabled="false"> <serviceDebug includeExceptionDetailInFaults="false"> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> </configuration>

In Lines #9-14, we reference the aforementioned assembly as a valid binding. Then, in Lines #14-18, we wire up the binding like another WCF service. Note that Visual Studio will complain, since the "pollingDuplexHttpBinding" isn't part of the out-of-the-box schema. On the Silverlight side, I programmatically create my binding objects so I don't have to worry about updating client-side configuration files. Here's the code for that (refer to the Uploader post for the details).



	private EncoderServiceClient GetEncoderClient() { //get binding PollingDuplexHttpBinding binding = new PollingDuplexHttpBinding() { MaxBufferSize = int.MaxValue, OpenTimeout = TimeSpan.FromHours(1), SendTimeout = TimeSpan.FromHours(1), CloseTimeout = TimeSpan.FromHours(1), MaxReceivedMessageSize = int.MaxValue, ReceiveTimeout = TimeSpan.FromHours(1), InactivityTimeout = TimeSpan.FromHours(1), DuplexMode = PollingDuplexMode.MultipleMessagesPerPoll }; //return return new EncoderServiceClient(binding, new EndpointAddress(string.Format("{0}EncoderService.svc", this._parameters["MediaServerURL"]))); }

It is against the object that this method returns that you can hook the "polling" events to enable bi-directional communitcation.

That closes the book on the Encoding phase of SUESS. As you can see, there's a lot going on, but all of the pieces are very straightforward. It's taking all of the cutting edge functionality from Encoder, IIS, WCF, and Silverlight, and gluing them all together. The hardest thing I ran into when built all of this is finding the right glue...and knowing when to use a lot and when to use a little.

Onto the final stage: SmoothStreaming!

Overriding SharePoint 2010 RTE CSS classes

2010-08-16T12:00:00Z

I’m going to shift gears a bit from my normal posts and jump into a little bit of the nuances of SharePoint’s CSS… SharePoint’s Rich Text Editor (RTE) is a great tool as it gives your content authors the freedom to modify the look and feel of their text. Granted, this laizze-faire approach is okay in certain environments, and in others a bit more control is required. One way of controlling user’s markup is to give them specific styles that they can use. For the uninitiated, these styles live under the ‘Markup Styles’ button as shown here:

Of course, to make these your own, all you have to do is override the appropriate classes. For instance, if I wanted to change Heading 2 to display in gray font, I would simply add the following class to my custom CSS (or theme, or masterpage, or content editor web part; you get the idea, just put it wherever you’re referencing your CSS) [Also, I should note that you can match the names from SharePoint’s GUI in the CSS with the ‘-ms-name’ reference].

H2.ms-rteElement-H2 {color: #CCCCCC;}

Likewise, if I wanted to change ‘Colored Heading 2’ to display in red it would be:

H2.ms-rteElement-H2b {color: #FF0000;}

Seems easy and straightforward, and it’s not a trap or a trick, it’s really that easy! However, our astute-readers will notice that when I select either of these headings, the font-size is in percent. While that method of sizing may make perfect sense to a designer or developer, to the end user that isn’t very helpful.. How are they supposed to know what that 150% is even based off of? Alright, so let’s go ahead and make this a nice pixel-size based font, so my class changes would be these right?

H2.ms-rteElement-H2 {font-size: 16px;}

H2.ms-rteElement-H2b {font-size:16px;}

Wrong…Silly CSS and tons of Microsoft classes everywhere. As it would turn out, Microsoft has a bit of a web created with these rte classes. So to make all of the changes I’ve discussed in this post, my final code would be:

h2,
.ms-WPBody H2,
.ms-WPBody H2.ms-rteElement-H2,
.ms-rteElement-H2
{
    -ms-name:"Heading 2";
    font-size: 16px;
    font-weight: normal;
    text-align:left;
    color:#cccccc;
}
.ms-WPBody H2,
.ms-WPBody H2.ms-rteElement-H2b,
.ms-rteElement-H2b
{
    -ms-name:"Colored Heading 2";
    font-size: 16px;
    font-weight: normal;
    text-align:left;
    color:#ff0000;
}

Granted, that’s a few more selectors than you were probably expecting, but there’s quite a bit going on with all of the different CSS sheets and classes floating around out there. You’ll also notice that this code will ‘match’ against most web parts and the use of Header classes. This isn’t necessary to get the rte bits to work, but I included it as it will keep all of my ‘heading’ elements consistent.

Following a similar formula, you could also add your own classes, like ‘Heading 5’ and ‘Colored Heading 5’. Simply copy/paste my more recent code snippet above and modify the 4’s to 5’s. Please note, these new classes will appear at the bottom of the RTE styles list (in other words, they would display beneath Heading 4/Colored Heading 4.

InfoPath Browser Enabled Forms and Crossing Web Applications

2010-08-13T17:09:15Z

Scenario:

A browser-enabled InfoPath form was to be built that allowed users to fill out a form, email it to themselves, attach a document to be uploaded to SharePoint, and then sent to an individual that understands SharePoint. Sure, the easy answer here is to make the user upload the file directly and just classify it there. The problem is that many users are unwilling to be trained on SharePoint, so this was elected as a compromise to fully utilizing SharePoint. There’s some other border-cases that this form solves, but this is neither here nor there.

Challenge:

The form has a number of drop-downs in it, some are SharePoint ‘choice’ fields, and two are SharePoint ‘lookup’ fields. The choice fields all function just fine since I’m using a nice little XML file to specify those dropdowns (they rarely change and it’s much quicker to load than querying all of the lists). The lookup lists do need to be refreshed on each form load, since those are subject to additions. However, InfoPath Browser forms have a nasty habit of ordering SharePoint-list-data source values by ID rather than Title. [To add further insult to injury, the full-blown InfoPath client orders by Title..] Users wouldn’t go for that on lists that contain upwards of 500 choices, so I had to find a way to order by Title…

After reading some great articles on using owssvr.dll to get a XML output for a particular list, I figured I had the problem licked. This method would allow me to return live data (on form-load), required no code-behind, and seemed straight-forward. So I followed the instructions (http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx), and then pressed enter to get a plain-white IE window (no XML as promised). After verifying that this wasn’t some obscure browser setting, I looked at the lists I was referencing and they were (both) custom lists that also had lookup columns contained within. I then suspected that the lookup column (especially one that allowed multi-select) wasn’t supported by the owssvr.dll method. Luckily for me, we are running a nifty little master-list data synchronization on this environment. The custom code basically reads a list (considered the ‘master’) on Web Application A, Site Collection A, and then writes any add/update/delete actions to copy-lists stored other Site Collections under Web Application B. Anyways, the ‘synchronized’ lists don’t contain the lookup columns, just the ‘ID’ and ‘Title’ values. Effectively, this allowed me to test owssvr.dll reading a ‘simple’ list…

After running a quick test, I discovered that owssvr.dll worked famously with the sync-lists! So, I rebuilt my form data connections, redeployed the form, and then BAM! Yet another error about SharePoint not being able to access data sources [Error ID 6932](and all of my dropdowns of lookup lists were blank). After some poking around, I surmised that InfoPath form services (even with cross-domain enabled) doesn’t like crossing SharePoint web applications, even though the user account I was using had permissions to both web applications.

Fix…Workaround:

So, to get the form to play nice, I simply deployed my form and associated data sources in a site under Web Application B. By doing this, my owssvr.dll XML files could reference the appropriate sync-lists correctly and in the same web application. After I did this, the form worked as advertised and I simply changed all of the applicable links to point to the new form location.

I realize that this is a fairly unique scenario, but I think there are a couple of important takeaways. First of all, for users that are running into the blank-white IE screen when using owssvr.dll, hopefully this post helps you in your test cases by trying the method after removing lookup columns. And Second, for those who might be considering/trying to get InfoPath Browser Forms to cross web applications, realize that you may have to somehow provide a simplified version of your list-data.

At the end of the day, the form worked as advertised, and the correct columns were returned (and ordered).

Server Tags within Sharepoint 2010 v4.master

2010-08-05T17:33:00Z

Just got done creating my first Masterpage for Sharepoint 2010 and I thought I would outline some of the new server tags I discovered in v4.master. V4.master refers to "Version 4 UI" and is the default 2010 master which includes all the new bells and whistles including the Ribbon.

If you are looking to maintain the look and feel of a 2007 masterpage default.master is also included within each team site. This supports the standard 2007 look and feel known as the "Version 3" User Interface.

Starting with the <head> tag you will notice the following javascript variable. This tag is needed to kickoff the Sharepoint Ribbon in the version 4 UI.

These two tags go inside <head> tag

1. <SharePoint:SPPageManager runat="server"/>

2. <SharePoint:ScriptLink language="javascript" name="core.js" OnDemand="true" runat="server"/>

ScriptManager is placed immediately after the <Form> tag

3. <asp:ScriptManager id="ScriptManager" runat="server" EnablePageMethods="false" EnablePartialRendering="true" EnableScriptGlobalization="false" EnableScriptLocalization="true" />

4.)<SharePoint:SPRibbon
Places the Ribbon control on the page. For more info on the div tags required for the Ribbon placement see links at the bottom of this page.

<SharePoint:ULSClientConfig runat="server"/>
This control would output the relevant script that enables error reporting.

<SharePoint:SPShortcutIcon runat="server" IconUrl="/_layouts/images/favicon.ico"/>
Simple tag to output a shortcut icon for your site. The default looks like this:

<SharePoint:SPHelpPageComponent Visible="false" runat="server"/>
Adds the following script to the page:

function _registerHelpComponent()    {
       SP.Ribbon.HelpPageComponent.registerWithPageManager();
}
ExecuteOrDelayUntilScriptLoaded(_registerHelpComponent, \"sp.ribbon.js\");

<SharePoint:SPNoScript runat="server"/>
adds the following tag to the page, used in the event javscript is turned off
<div class="noindex">You may be trying to access this site from a secured browser on the server. Please enable scripts and reload this page.</div>

<SharePoint:PopoutMenu
Container for popup menus used throughout Sharepoint 2010.

<SharePoint:ListSiteMapPath
Display breadcrumbs within site, subsites, and libraries.

<SharePoint:SPRibbonPeripheralContent
Exposes design controls, tagging controls, view state controls, and related design and behaviorial controls for the ribbon user interface. You can use the Location() method to update where the content appears on the page.

<SharePoint:PageStateActionButton id="PageStateActionButton" runat="server" Visible="false" />
Actually.... not really sure what this do-hickey does

<SharePoint:DeveloperDashboard runat="server" />
The developer dashboard displays information relevant to each page load, including:

1. What controls loaded and how long each took to load
   2. Specific database queries executed and the execution time of each
   3. Events that were fired during the page load
   4. Order of the page lifecycle and time during each stage

<div id="DeveloperDashboard" class="ms-developerdashboard" />
Actual location of dashboard

<Sharepoint:DeveloperDashboardLauncher
Displays an icon to launch the developer dashboard if active. You can activate the developer dashboard either through stsadm or code.

1. stsadm: STSADM –o setproperty –pn developer-dashboard –pv OnDemand
2. code:
    SPWebService cs = SPWebService.ContentService;
    cs.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.On;
    cs.DeveloperDashboardSettings.Update();
3. If you enable the dashboard but remove the Launcher Icon you can still launch it by appending the querystring: "?DeveloperDashboard=true"

<SharePoint:UIVersionedContent UIVersion="3" runat="server">
Indicates UI version of encapsulated content. Content that does not match the UI version is not rendered.

References:

This article outlines exactly which placeholder and classes to be aware of when upgrading an Existing Master Page to the SharePoint Foundation Master Page
http://msdn.microsoft.com/en-us/library/ee539981.aspx

NightAndDay.Master
http://msdn.microsoft.com/en-us/library/ff625186.aspx

Customizing Ribbon positioning
http://www.facebook.com/notes/microsoft-sharepoint-server-2010/customizing-ribbon-positioning-in-sharepoint-2010-master-pages/440358734744

Ribbon Customization: Changing Placement, Look and Behavior
http://styledpoint.com/blog/ribbon-customization-changing-placement-look-and-behavior/

SharePoint 2010 – Enable & using Developer Dashboard
http://blogs.technet.com/b/patrick_heyde/archive/2009/11/16/sharepoint-2010-enable-using-developer-dashboard.aspx

Working with SharePoint 2010 Foundation Master Pages
http://blog.allyis.com/blog/bid/48102/Working-with-SharePoint-2010-Foundation-Master-Pages

TechNet
http://social.technet.microsoft.com/Forums/en-US/category/sharepoint2010

Umbraco: Resolving the “Opening edit screen is very slow when macros are present” issue

2010-07-27T15:30:01Z

On our shared Umbraco development server, we were having some performance issues with the backend that neither I nor the other developer on the project were experiencing with the same code/document types/macros on our local system. Even backing up the shared system and restoring to our local machines didn’t reproduce the problem. When we’d open up certain pages for editing, it would take a *very* long time for the server to send back the editContent.aspx page (about 35s as measured by Firebug). Other pages didn’t have the issue. A quick comparison of the pages showed one obvious difference – the slow page had a macro in a content block, the fast page didn’t. After checking a few things (umbracoLog table in the DB, CPU usage), it was obvious the server wasn’t pegging it’s CPU or anything like that, and the SQL Server process wasn’t going crazy either (which might indicate an excessive number of queries running), so on a whim, I thought I’d dig into the code and see what happens before that “No macro content available for WYSIWYG editing” message is generated.

Now, I could just download the source code for Umbraco and dig in a bit, but I started my investigation on my evening train ride home, where I don’t have Internet access, and I didn’t already have a copy of the code on my machine. So, I pulled up the secret weapon of a .Net developer’s arsenal, Reflector. After a search for the message above, I was led to umbraco.macro.MacroContentByHttp, which uses Request.ServerVariables[“SERVER_NAME”] to find out it’s name and makes a request to /macroResultWrapper.aspx to get the contents of the macro:

Could this be our culprit? I logged onto the server and tried to access the site via the name we were using. Sure enough, timeout… So I try pinging the hostname we’re using from the server itself – same result – no response. I added a host entry for that name using 127.0.0.1 as the IP address, tried hitting the server again from the browser, and sure enough, success. I cycled IIS, loaded up the backend of the shared dev environment from my client machine, and went to edit a page with a macro – 3 seconds to load. Much better. Apparently, due to firewall issues on our hosting environment, the server can’t access itself via it’s ‘public’ IP, only via the private IP, but DNS still resolves it’s name to the public IP.

The lesson here: with Umbraco, make sure your server can reach itself using the name you’re using to access it. Ie. if you use a hosts entry to map myshareddevserver.local to the IP address of your shared dev server in the office and set up an Umbraco instance in IIS on that server, make sure you put the same hosts entry on the dev server too, or you’ll have (at least) this issue.

Note: this may be changed/resolved in Umbraco 4.5 (released last month) – I haven’t worked with that version yet.

SQL Server Geospatial Part 3 – Visualizing Spatial Data in SSRS

2010-07-25T00:18:00Z

In the previous post, we finished by calculating population density for the city of Chicago. Today we will continue to build on that same dataset and will look at a cool way to visualize our spatial data using SSRS in SQL Server 2008 R2. If you haven’t done so yet, run through the tutorials in posts one and two to bring your database up to speed.

First of all, let’s look at an interesting way to join spatial datasets, as well as building a little on the knowledge from the last post about geography vs. geometry data. If you remember my comments about spatial reference systems, you’ll remember that the only way to truly measure distance is to use the geography type, which maps to three-dimensional space. However, you’ll also remember that the geography type supports far less functions that the geometry type. One of the convenient, and missing, functions from the geometry type is STCentroid() which returns a point at the center of mass of any shape. There’s a good explanation here.

Thankfully with some casting back and forth, we can find the center points of two geometry objects, and calculate distance between them in meters. The comments in the query below illustrate what’s happening. Of note is also the join between the two datasets, you’ll find yourself using this type of join over and over when working with spatial data, whether you’re calculating distances or overlaps, ranking overlaps to find primary geographical relationships between towns and zip codes, the list goes on.

select places.NAME
,referenceplace.name
,places.geom
,pops.POP_2008
/*
Find the distance between the centroid of the place and
Chicago's centroid. Both need to be converted to geometry
to find the centroid and then this point is converted
back to geography
*/
,dbo.MakeValidGeographyFromText
(places.geom.MakeValid().STCentroid().STAsText(),4326)
.STDistance(dbo.MakeValidGeographyFromText
(referenceplace.geom.MakeValid().STCentroid().STAsText(),4326))
as CentroidDistanceFromChicagoCentroid
/*
This finds the population density per square mile. See last
post for an explanation. The large number represents the
number of square meters in a square mile.
*/
,convert(int,pops.POP_2008
/ (dbo.MakeValidGeographyFromText
(places.geom.STAsText(),4326).STArea() / 2589988.11))
as PopDensity
from tl_2009_17_place as places
inner join ILPlacesCensusPops as pops
on pops.place = places.PLACEFP
/*
This syntax joins the data sets together on distance < 20000
meters to find towns with a center less than 20 kilometers from
the center of Chicago. See centroid logic above.
*/
join tl_2009_17_place as referenceplace
on dbo.MakeValidGeographyFromText
(places.geom.MakeValid().STCentroid().STAsText(),4326)
.STDistance(dbo.MakeValidGeographyFromText
(referenceplace.geom.MakeValid().STCentroid().STAsText(),4326))
< 20000
where referenceplace.Name = 'Chicago'
and pops.STATENAME = 'Illinois'

You’ll see that we return a nice little dataset, with population, population density, and distance from Chicago for 49 communities, including Chicago itself.

Now let’s see what we can do with our little dataset. I am going to go ahead and assume that you have BIDS installed along with SQL Server 2008 R2, if not you can install the free evaluation from this site. Fire up Visual Studio, and select “File –> New –> Project”. Select “Report Server Project” and call your new project GeoExamples.

Add a new report through the solution explorer and call it ChicagoAreaPopulation.rdl.

Right-click “Data Sources” and select “Add Data Source”. Connect to your local GeoExamples database.

Now right-click the data source we just added, and select “Add Dataset”. Name it ChicagoAreaPopulation and paste in our query from the beginning of this post. It should look like the image below.

Now right click in the main report area and select “Insert –> Map”

Select “SQL Server spatial query” and click “Next.”

Select the dataset we just created and click “Next.”

Now this SSRS report starts getting cool. Make sure the geom field is selected as the Spatial field, select “Add a Bing Maps layer” and choose “Aerial” as the type. Leave all other default options selected and click next.

On the next pane, select “Color Analytical Map” as the map type and go to the next screen.

We are going to add a new dataset using the same query. Really you should be writing different queries for the spatial data and the analytical data but for this example using the same query in both places will work. If you use the same dataset in both places it will only allow you to display aggregates of our analytical field (population density) so that won’t do. This is also a good time to point out that for any type of production environment you’ll want to materialize all the spatial calculations, running them at execution time is not recommended. Select “Add a dataset that includes fields that relate to the spatial data that you chose earlier” and hit “Next”.

Paste in our same query and hit “Next.”

Accept all the defaults on this page (after all, we’re using the same query twice) and hit “Next.”

Now, leave the theme “Generic”, leave the color rule “Green-Yellow-Red”, select #PopDensity as the visualization field, Select “Display labels” and choose #NAME (this second one, in all caps), and hit “Finish.”

Edit the map title to read “Chicago Area Population Density” and toy around with the font sizes to display more place names. This is the result! A pretty little map showing population density per square mile for towns within 20km of Chicago. All based on free data, and using technologies you already own.

There are many other ways to unlock the power of your spatial data, SSRS is just one of many outlets. Stay tuned for more in future posts!

SharePoint Search: The Difference Between RowCount And TotalRows

2010-07-19T18:17:00Z

I just wanted to post a real quick note about something that finally dawned on me regarding the SharePoint 2007 search API. There are two properties in the ResultTable object that I've been using interchangeably, as the documentation on MSDN does little to discern them from one another. These are RowCount and TotalRows.

Turns out, the way I usually customize my queries also technically didn't discern them. I'm working on a paged search result viewer control. The way it worked previously was that it got all of the data from a single query and chopped up the results into pages client side. Using Silverlight, these pages could then be navigated via prettily-animated transitions. With this style, since we are interested in ALL of the results in the query, RowCount is always the same as TotalRows.

As a performance enhancement, we punted the animations, and instead only started requesting a certain block of results. Now, each query gives us results X though Y of Z. When you tell SharePoint to only give you a certain number of results (Y) starting from a particular index (X), you actually get (Z) for free! So if you are doing paged searches, you don't need to worry about doing an "empty" search (in terms of columns) to just get the total number of rows; the API is smart enough give us this number without actually doing the work of calculating all the corresponding results.

So: RowCount is the actual number of search results, based on the StartRow and RowLimit properties. TotalRows is therefore the actual about of search items that exist in the index that correspond to their query, irrespective to any paging trimming.

Here's a quick code block to demonstrate how to use these properties:



	private ResultTable RunQuery(string text, int rowLimit, int startIndex) { //initialization FullTextSqlQuery query = new FullTextSqlQuery(ServerContext.Current); //build query query.RowLimit = rowLimit; query.QueryText = "(query)"; query.TrimDuplicates = true; query.StartRow = startIndex * rowLimit; query.ResultTypes = ResultType.RelevantResults; //return return query.Execute()[ResultType.RelevantResults]; }

Have fun!

The SUESS Lifecycle: Stage 1 - Upload

2010-07-17T04:57:00Z

The SUESS Series

Introduction
Stage 1 - Upload
Stage 2 - Encode
Stage 3 - SmoothStreaming

Our in-depth media adventure begins, well, at the beginning of the SUESS "lifecycle" with Uploading. This stage contains two sub-components: the Uploader Silverlight control, and the WCF service on the Web Server that facilitates the file upload process. The only prerequisite required here is to have your data tier (Component 3) in place (which can simply be a folder on the Web Server).

Of course, there is nothing new about a file upload control; it's been in HTML longer than I have. Over the years, I've seen a lot of modifications to the familiar read only textbox and "Browse..." button to get the effects people are starting to expect in this whole Web 2.0 craze: progress bars, client-side file type filtering, large file support, etc.

To achieve these nice features, a lot of magic needs to happen client side. If you've read anything I've written before, you'll know that I don't consider AJAX to be magic; it's voodoo at best compared to the wizardry of Silverlight. The argument remains the Silverlight needs to be installed on the client's machine while AJAX comes down for free from the server along with the rest of the page. However, when it comes to programmatic benefits such as a first-class development experience (IntelliSense, compilation, UI designer, etc.), robustness of code, and extent of possibilities of what you can build, you cannot argue against Silverlight.

<RANT>

Now don't get me wrong: AJAX is a really cute technology that has a lot of niche uses. The difference, as far as I'm concerned, falls in the mindset of the developer. Take animating progress bars for example. In AJAX/HTML, you'd need to arrange a few nested divs, set all their widths and background colors, and then when the upload mechanism reports progress, update the width of the inner-most div. To me, that's not really a true progress bar; it's HTML kludginess.

Now, in Silverlight, you see, you literally just animate a ProgressBar.

THAT'S the point.

</RANT>

The example Uploader control I'll show you shortly lacks all the bells and whistles with which it could be adorned to truly make the life of a content manager much better. These features include drag and drop support, multi-file uploads, a slick UI, etc. However, the big ones, like progress bars and cancellation, will demonstrate how uploading large files (such as media) can be a pleasant experience for a user.

First of all, what does it look like? Well, not much, unfortunately. A pretty admin UI was not a requirement of the project through which I came up with SUESS, since this was all back end functionality. But here's what we have:

The title and description fields are watermarked textboxes with some gradient borders to implement the comps of the project. I really don't want to bore you with the details of the code that updates the visual state of the UI; it's hard to make hiding buttons and displaying error messages sexy. You'll be able to download SUESS in its entirety and comb through all the details yourself. Instead, let's take a quick trip through it, and then dive into the cool stuff.

The only input we actually need from the user is the file itself. Depending on your data tier, you could accept more metadata. (SUESS was actually born into SharePoint, so the sky was the limit for metadata.) But for now, we'll just have two optional textboxes for the name of the media and a description. If the name is blank, we'll use the file name. (As you'll see later, with the way Encoder outputs its SmoothStreaming formatted files, we don't have to worry about filename collisions; it's only a consideration during uploading.)

Next we have the "Encoding Quality" drop down. Once again, this is optional, and included only as an example to show another aspect of what you can do with SUESS in terms of explicitly controlling a myriad of Encoder options. (You'll see what I'm talking about in the Encoding post about SUESS.) These are hard-coded (barf, I know) values mimicking the Video Complexity (no documentation available) enumeration in the Encoder SDK. This is the best we can do to this extent, since we can't actually reference the DLL in our Silverlight project and reflect each enum member.

The purpose of including this in the example Uploader is to allow the user the ability to "throttle" the encoding process, which, as previously mentioned, could be very processor (and, of course, time) intensive. Unfortunately, I don't have a lot of metrics regarding just how much quality is sacrificed in terms of time taken to encode. However, I can say that media encoded with the highest quality settings indeed takes much longer than with the lowest.

Finally, we have the media itself. Silverlight gives us the OpenFileDialog control that is more or less identical to what you'd find in Windows Forms. The one immediate advantage it gives us over what is available in the HTML version is the ability to filter the file types (by extension) that the user is allowed to select in the dialog. This not only gives us a more elegant user experience (since we can "label" our filter with something like "Media Files,") but also makes the development much easier, since we don't have to go through the "hand slapping" input validation experience.

<RANT>

Back in the HTML/AJAX version of a file upload control, if you need to enforce a certain type (or types) of file(s), the best you can do is inspect the file the user selected, check its extension, and display an error message, forcing the user to have to go through the entire exercise again. Instead, with Silverlight, we can simply hide invalid file extensions in the folders they navigate within the dialog via the Filter property. This probably doesn't seem like a big deal, but I think it's huge: small UX improvements like these are what Web 2.0 is all about; with Silverlight, you are really using an application, not just a webpage.

</RANT>

Let's talk about a few of the more interesting code samples. The first one simply sets the OpenFileDialog to only allow the files that Encoder supports to be uploaded. It also has a hard coded value (which can easily be made to be configurable) to disallow files over 1GB (purely for sanity purposes).



	private void btnSelectFile_Click(object sender, RoutedEventArgs e) { //initialization OpenFileDialog ofd = new OpenFileDialog(); //show open file dialog ofd.Multiselect = false; ofd.Filter = "Media Files\|.asf;.avi;.bmp;.gif;.jpg;.jpeg;.m2t;.m2ts;.mov;.mp4;.mpeg;.mpg;.png;.tif;.tiff;.ts;.vob;.wmv;"; bool? fileSelected = ofd.ShowDialog(); //check for file if (fileSelected.HasValue && fileSelected.Value) { //check legth if (ofd.File.Length > this._maxFileSize) { //(omitted UI code) //file too large this.tbProgress.Text = "You cannot upload a file larger than 500 MB."; return; } //(omitted UI code) //start upload this.StartUpload(ofd.File); } }

Line #7 above sets the Filter property of the OpenFileDialog to the Encoder 3 supported file types. This is what ensures that Encoder will be able to handle whatever the user throws at it. Line #15 shows that "UI" code has been omitted. You'll see this in a lot the code samples throughout SUESS. Like I said, I don't want to bore you with the details of dealing with VisualStates in the application. Here are some more action shots:

Next let's look at the logic that implements the recursive "chunky" upload. If we send the entire file up to the server, we can't show progress bars, and really don't take advantage of client side functionality at all. Instead, the SUESS Uploader sends 1MB of the file up to the server at a time. After each call, the UI is updated with the current progress, and then the next "chunk" is uploaded.

Since all Silverlight service communication is done asynchronously, we need to daisy chain the "Completed" callback for each of these calls so that they are executed serially within it. Normally, if service calls can be done in parallel (such as downloading images or assembling the content of unselected tabs), you can kick off them all off at the same time; when they're done, they're done, and the corresponding part of the UI lights up.

Otherwise, if you need to call service A and then pass its result on to service B (or a subsequent call back to A, like the Uploader), then there will be some chaining going on. Here's a quick diagram that demonstrates these two paradigms.

In the top half, where we show "parallel" calls, all of the service references are explicit. We invoke a service, and when the associated completed event handler is fired, we do something back on the UI. What if we need to call the same service multiple (and in an unknowable amount of) times in a specific order? This is the case with the Uploader. Since we obviously can't know the size of the file, then we further don't know how many chunks we'll be dealing with. We need to make these calls serially.

The answer is recursion, as shown in the bottom half of the diagram. (Of course, this is only logical recursion, since the same physical method isn't actually calling itself.) I experimented with some crazy iterative algorithms, but they got real messy real quick, and were all ultimately besmirched by the asynchronousity of Silverlight. Instead, I created a method that uploads a chunk (array of bytes) of a file, and when it's done, increments a counter and progress bars. Finally, the same service is called again with the next chunk.

This algorithm, other than being sweet at uploading files, makes two additional features of the Uploader trivial: real time progress bars and upload cancellation. We'll discuss those next. First, however, let's look at this code. This piece is the StartUpload method that the above code block calls to kick off the recursion.



	private void StartUpload(FileInfo file) { //(omitted UI code that resets progress bars, clears errors, etc.) //start recursive upload this._index = 0; this._fileName = string.Format("{0}-{1}", Guid.NewGuid(), file.Name); this.UploadFile(file, true); }

The Boolean passed as the second parameter to UploadFile in Line #7 simply tells the algorithm this is the first chunk. UploadFile actually doesn't care; it just passes this along to the service so that it knows whether to create a new file on the data tier or open an existing one. This can probably be inferred on the server rather than made explicit, but I didn't want to have to burn an extra trip to the disk for each chunk if I didn't have to.

Here's the algorithm:



	private void UploadFile(FileInfo file, bool isFirstChunk) { //initialization byte[] buffer = new byte[this._bufferSize]; MediaServiceSoapClient svc = Utilities.GetMediaClient(); //get chunk using (Stream data = file.OpenRead()) { //write to buffer data.Seek(this._index, SeekOrigin.Begin); data.Read(buffer, 0, this._bufferSize); } //upload chunk svc.UploadFileChunkAsync(this._fileName, buffer, isFirstChunk); svc.UploadFileChunkCompleted += (sender, args) => { //determine result if (args.Cancelled \|\| args.Error != null \|\| !string.IsNullOrEmpty(args.Result)) { //(error code very much truncated here; the above if statement should check each OR'ed condition separately and update the UI appropriately) } else if (this._index > -1) { //update text progress double progress = (Convert.ToDouble(this._index) / Convert.ToDouble(file.Length)) * 100; this.pbUpload.IsIndeterminate = false; this.tbProgress.Text = string.Format("{0} / {1} MB uploaded...", Convert.ToDouble(this._index) / Convert.ToDouble(this._bufferSize), this.GetTotalSize(file.Length)); //animate value Storyboard sb = new Storyboard(); DoubleAnimation da = new DoubleAnimation(); Storyboard.SetTarget(da, this.pbUpload); Storyboard.SetTargetProperty(da, new PropertyPath("Value")); sb.Children.Add(da); da.To = progress; //determine if we've reached the end of the file if (file.Length > this._index) { //pause and upload next chunk Thread.Sleep(200); this._index += this._bufferSize; //recurse this.UploadFile(file, false); } else { //(omitted UI code) //we're done - start encoding this.EncodeCompletedFile(); } //animate progress sb.Begin(); } else { //update canceled this.ShowCancel(); return; } }; }

The first thing to point out here is the utility method in Line #5. This method is a nice Silverlight helper that alleviates the need to have to deal with the "ServiceReferences.ClientConfig" files that store the Service URLs and other WCF settings. Using this method allows you to promote your control from development through production without having to worry about maintaining it.



	public static MediaServiceSoapClient GetMediaClient() { //return return new MediaServiceSoapClient(Utilities.GetBinding(), Utilities.GetAddress("Media")); }

Here are the two internal methods that build the WCF binding and get the URL of the service dynamically:



	private static BasicHttpBinding GetBinding() { //initialization BasicHttpBinding binding = new BasicHttpBinding(BasicHttpSecurityMode.None); //set timeout binding.SendTimeout = TimeSpan.FromHours(1); binding.OpenTimeout = TimeSpan.FromHours(1); binding.CloseTimeout = TimeSpan.FromHours(1); binding.ReceiveTimeout = TimeSpan.FromHours(1); //set messags sizes binding.MaxBufferSize = int.MaxValue; binding.MaxReceivedMessageSize = int.MaxValue; //return return binding; }

And the piece to get the service endpoint. (Note that since this example was lifted from a SharePoint implementation of SUESS, I had to be a bit creative with the URL.)



	private static EndpointAddress GetAddress(string name) { //window.location.href Uri uri = new Uri(((ScriptObject)HtmlPage.Window.GetProperty("location")).GetProperty("href").ToString()); //return return new EndpointAddress(string.Format("{0}://{1}/_vti_bin/{2}Service.asmx", uri.Scheme, uri.Host, name)); }

The rest of the main algorithm is actually pretty straight forward. The recursiveness happens in lines 39 through 42. We pause a bit in Line #39 so that Silverlight doesn't try to open the file from a new thread before the previous one properly closed it, increment the index of where we "are" in the file, and then recursively call the service.

How do we break out of the recursion? Three things can happen. First of all, if something goes terribly wrong on the server or some other exception is thrown, it will be caught on Line #20, handled, and then we'll hard return out of the method. (Again, since this isn't physical recursion, we don't have any stack trace "depth" to worry about.) Otherwise, we use the index. If it's greater than or equal to the length of the file, we know we've uploaded all the bytes: break out here, and start encoding.

The final way is through cancelation, which is one of the big features the Uploader. I know this isn't anything amazing, but it's another example of something that's pretty easy in Silverlight and probably pretty tough in HTML. As someone who's been in and around SharePoint for years, I've seen a lot of large file uploads quietly timeout after watching the page spin for ten minutes. That sort of behavior is not good enough; we need a big red self-destruct button to make sure we can cleanly stop an upload.

So as all this asynchronous uploading is happening on background threads, how do we cancel it from the click event of a cancel button on the UI thread? It turns out that it just works. Silverlight will automatically fire the completed event for a service call on the correct thread, alleviating the need for any dispatching. Since we don't have to worry about any cross threading, we can jump right in with the logic.

The Uploader cancel button click does two things. First, it simply sets the aforementioned index to -1, which basically throws a wrench in the recursive gears. Since all of our calls are on the same thread, we can check this index, see that we've been cancelled, and, well, stop making calls. This is all the housekeeping we need on the client. But what about the server?

The second cancellation task is to make one more call that tells the server that this upload has been cancelled so it can clean up the file. This is one of the reasons for the intermediate "upload" folder on the server: we never had to worry about IIS serving fragments of files. Other than cancellation, dropped connections will also leave broken files on the server. If the upload connections die, then we obviously won't be able to make another call to tell the server to clean up this file. Here is where the cleanup job finishes up for us.

This is a good transition to start looking at server code. We'll begin with the CancelFile method:



	[WebMethod] public string CancelFile(string path) { //initialization string result = string.Empty; path = Path.Combine(this.GetTempUploadPath(), path); //impersonation SPSecurity.RunWithElevatedPrivileges(() => { try { //delete if (File.Exists(path)) File.Delete(path); } catch (Exception ex) { //(error code omitted) } }); //return return result; }

The interesting thing going on here is in Line #8 where I elevate to run as the SharePoint app pool account. This is important for two reasons (neither of which, of course, are what the RunWithElevatedPrivileges delegate is designed to do). First of all, we don't have to assign "Everyone" permissions on our folders. Second, it gets us around a potential IIS double hop issue, in case the GetTempUploadPath method (which is a wrapper around a config file call) returns a UNC path. (Kerberos is the right way to deal with IIS double hops, but that seems to be more configuration than most people - including me - are willing to deal with).

Next we have the method that accepts a chunk from the client and builds a file on the destination server:



	[WebMethod] public string UploadFileChunk(string path, byte[] data, bool isFirstChunk) { //initialization string result = string.Empty; Action<object> uploadCode = null; path = Path.Combine(this.GetTempUploadPath(), path); //impersonation SPSecurity.RunWithElevatedPrivileges(() => { try { //determine if this is the first request if (isFirstChunk) { //delete if (File.Exists(path)) File.Delete(path); } //determine if file exits if (File.Exists(path)) { //add chunk to existing file uploadCode = (o) => { //open file using (FileStream fs = File.Open(path, FileMode.Open)) { //write chunk this.WriteChunk(fs, data); } }; } else { //create new file uploadCode = (o) => { //open file using (FileStream fs = File.Create(path)) { //write chunk this.WriteChunk(fs, data); } }; } //upload Utils.ForceRetryFunction<object, Exception>(() => { uploadCode(null); return null; }, "MediaService.UploadFileChunk", string.Concat("The following error occured while uploading ", path)); } catch (Exception ex) { //(error code omitted) } }); //return return result; }

There are a couple of things to note here. First of all, you'll notice that I use an Action delegate to pass the blocks of code that do the file writing (WriteChunk will be displayed shortly) to a method in Line #48 called ForceRetryFunction. This method takes in a Func (that is passed via an anonymous method in the invocation) which is basically processed in a while loop until it doesn't throw the type of exception (that is generically passed in as well). There are few other operations in the system that spawned SUESS, so I refactored it into ForceRetryMethod.

But WHY? Simply because certain operations need to be kicked in the ass to work. In this example, with I/O happening on several threads really fast, .NET can step on itself and open the file before it's properly closed (just like on the client). I'll put the code here for fun because it's a pretty cool algorithm, but the details are outside the scope of SUESS.



	public static T ForceRetryFunction<T, E>(Func<T> code, string sender, string description) where E : Exception { //initialization int sleep = 500; bool worked = false; T result = default(T); DateTime now = DateTime.UtcNow; //keep trying while (!worked) { try { //run the code result = code(); //code successful worked = true; } catch (E ex) { //only try for one minute if (DateTime.UtcNow.Subtract(now).TotalMinutes > 1) { //unable to save //(error code omitted) worked = true; } else { //method blew up: sleep and try again lock (Utils._random) sleep *= Convert.ToInt32((1.5 + Utils._random.NextDouble())); //sleep exponentially Thread.Sleep(sleep); } } } //return return result; }

After all the trying, retrying, locking, and checking, the actual work that the server performs can be boiled down the simplest method in this section: WriteChunk. Here's the little guy:



	private void WriteChunk(FileStream fs, byte[] buffer) { //seek to end of the file fs.Seek(0, SeekOrigin.End); //write chunk fs.Write(buffer, 0, buffer.Length); }

Very straight forward, and unfortunately, a rather anticlimactic way to end our discussion of the SUESS Uploader. Once the file is up on the server, the Uploader's only remaining task is to kick off the Encoder stage. This is where all the really cool stuff happens, so stay tuned for the next post!

Have fun!

Enterprise’s Internal Communications can Transform itself into a Social Business

2010-07-09T20:54:00Z

The most successful examples of social businesses include those who are already using social processes and tools internally. Those business that systematically encourage openness inside the organization are the most likely to empower employees to engage with the outside world. SharePoint tends to be that glue.

These are ways an enterprise’s internal communications can transform itself into a social business:

• A process with social guidelines is already in place. (For example, Microsoft co-created their guidelines, with employees.)

• Employees use social tools to collaborate internally, before opening up external gates. (Examples: employee networks on Facebook, Yammer, Newsgator, Jive, and Social Text.)

• Companies reconsider the role of individuals in the company, with greater value of and incentives for extra market forces and nonfinancial drivers, including an individual’s sense of meaning and purpose.

Getting Silverlight 4 Drag And Drop Working With The SharePoint 2010 Silverlight Web Part

2010-07-05T18:52:00Z

I'm working on some Silverlight 4 drag and drop functionality for a SharePoint 2010 site, and ran into the old situation where it worked fine locally, but not fine in SharePoint. What would happen is the browser, in SharePoint, actually opened the image instead of tunneling the drop event to my Silverlight control. I actually knew it wasn't going to work immediately when I noticed that the cursor was different between the two browsers: the one spawned by Visual Studio had the correct "drag" cursor, while SharePoint sported the "shortcut" one.

This was one of those problems that seemed impossible. How can I control the browser's behavior toward dragging and dropping files from a different process (such as Windows Explorer)? How could it possibly work on one site and not another? Environmental problems are much harder to solve, in my opinion, than logical problems. I can always take my code apart line by line to exterminate some bug. But when it comes to IE (in this case) being flakey, what can you do?

So I peeked behind the scenes at both markups, and found one difference between the two. "If this isn't the problem," I thought, "well, I'm going home." The difference turned out to be the Silverlight Windowless setting. This is an optional parameter that can be nestled into the object tag and takes a Boolean value.

Setting this to "true" means the Silverlight control is, well, windowless; it literally embeds itself in the browser's window instead of having the plugin define its bounds. Although there is a performance hit, this embedding allows the control to be truly transparent, and have HTML overlay or underlay it. If Windowless is "false," it sort of floats "above" the browser. Now, Silverlight is always still in the same physical window (as it's in IE's process) of course; the difference is that, if not Windowless, Silverlight acts a bit more autonomously from the browser.

The other consideration, and the one that got me here, is that setting Windowless to true precludes some of the mouse events. Since Silverlight is "in line" with the browser, then the browser will handle them. However, when it floats above (not Windowless), Silverlight can intercept these mouse events, including, of course, drag and drop!

Visual Studio, by default, does not include this parameter, and therefore Windowless defaults to false in Silverlight. The problem is that the SilverightWebPart that comes OOTB in SharePoint 2010 automatically adds this parameter, and sets it to true. And in classic SharePoint fashion, although there is Boolean .NET property that can be set programmatically, the ToolPart does not expose it on the UI.

So how do we fix this to get drag and drop working? You can always add some jQueryto the master page that blindly sets the parameter to false, but this is a little sloppy. Instead, I came up with the following code that correctly sets the WindowlessMode property on the web part, and persists it:



	using System; using System.Web.UI; using Microsoft.SharePoint; using System.Web.UI.WebControls.WebParts; using SPWP = Microsoft.SharePoint.WebPartPages; ... //get this page using (SPWP.SPLimitedWebPartManager mgr = SPContext.Current.Web.GetLimitedWebPartManager(this.Page.Request.Url.AbsolutePath, PersonalizationScope.Shared)) { //get all web parts foreach (WebPart wp in mgr.WebParts) { //look for silverlight web parts if (wp is SPWP.SilverlightWebPart) { //disable windowless mode ((SPWP.SilverlightWebPart)wp).WindowlessMode = false; mgr.SaveChanges(wp); } } //clean mgr.Web.Close(); mgr.Web.Dispose(); }

This code could be a web part, a feature, or code in the master page. Run it once, and you'll be able to drag and drop files into a Silverlight 4 web part living inside of SharePoint 2010! Then reference the Client Object Model DLL in your control, and you've got the makings of a killer SharePoint 2010 uploader control, using one of the coolest new features of Silverlight.

Have fun!

Using Sharepoint 2007 Search via custom code

2010-06-29T13:48:01Z

Recently, I’ve been working on a Sharepoint 2007 farm that has 500+ site collections, each representing a project. The plan is to potentially have several GB of (scanned) documents in each of these projects, so they were set up as separate site collections to allow them to be split across different content databases, as well as be able to be backed up and restored independently if needed.

I’ve been tasked with modifying a custom webpart that rolls up some information (tasks) from these individual site collections. The original version of this webpart iterated through every site collection on the web application, found the task list, and loaded the tasks. It worked with 20-30 site collections (but was slow), but would timeout with 500+. A few weeks ago, I made a couple of quick tweaks to reduce the amount of list-scanning used and properly dispose objects after their use and got it down to a 50s load-time on those 500 site collections, but could get no further. Creating 500+ SPSite objects just isn’t fast, and SPSiteDataQuery doesn’t work across site collections. So I’ve been tasked with finding an alternate way to do it, and we’ve settled on using MOSS Search.

After a few false-starts (initially using WSS search instead of MOSS search), and some issues around dates (use ISO8601 format), my query ran like I expected and pulled back all the tasks. I switched over to FullTextSqlQuery (to get the range comparison operators) and the core functionality of my custom search piece was done.

Quick-hit list of lessons from this:

Having 500+ separate site collections makes doing anything to all sites rather painful (and rather slow). Now that 2010 is out, consider whether RBS can let you achieve the scale you’re looking for without death-by-a-million-site-collections.
When writing code against search, make sure you know whether you want to use WSS search (Microsoft.Sharepoint.Search) or MOSS search (Microsoft.Office.Server.Search). Their APIs may look similar, but WSS search is less capable. For one, WSS search doesn’t work with custom managed properties (it’ll throw an “InvalidPropertyException: Property doesn't exist or is used in a manner inconsistent with schema settings”).
KeywordQuery does simple queries well. If you need something more complicated (like greater-than/less-than), you have to go to FullTextSqlQuery.
‘Contains’ clauses (ie Contains(“value”) or Contains(field, “value”)) don’t support full wildcards – ie. “*value*” won’t match what you want it to – use ‘like’ instead (though that only works for a single field)
Dates for FullTextSqlQuery must be in ISO8601 format.
When exposing a new field to search, the procecedure is: Add field to list (if needed), incremental crawl (automatically adds crawled property), add managed property, full crawl. Keep this in mind when scheduling a migration to a new environment, as that full crawl can take some time (4-8 hours in my 500+ site collection setup on dev hardware).
AssignedTo behaves oddly when it comes back in a search result. If it has a single user, it comes back with “Joe Smith”. If it has multiple, it comes back with “Joe Smith;#41;#Jane Smith;#42;#Roger Brown”. I had to add logic for this field to remove the ;#ID;# chunks from this (split it up, keep only the 0th, 2nd, etc. items). This works for my scenario because I don’t actually want those to be links anyway (hence I don’t need the IDs):
var assignedTo = Convert.ToString(row["AssignedTo"]);
var assignedTokens = assignedTo.Split(new string[] { ";#" }, StringSplitOptions.None);
var assignedToNames = assignedTokens.Where((s, i) => i % 2 == 0).ToArray();
row["AssignedTo"] = string.Join(", ", assignedToNames);
When your managed property has the ‘Include values from all crawled properties mapped’ flag set, you may get an array for that column instead of a single value (one farm gave me an array, the other didn’t). None of my search results had multiple values, so I’m guessing the array is used if *any* item in the index has multiple values – if your managed properties are defined that way, you’ll need to fix it up – I have a previous blog post that covers dealing with multi-valued managed properties in Sharepoint Search.
If you’re seeing ‘odd’ values in some default fields, check the managed property definitions. OOTB (and on my local dev environment), the definition of the managed property ‘Path’ – was such that non-document-library items had a value like DispForm.aspx?ID=x, while on our shared test/prod farms, it was ListName/X._000. Turns out, the managed property definition was modified to try to fix an issue with a third-party library. Since it ended up not helping that library, we just reverted the change back to the OOTB managed property definition, and all was well again.

Sure, using search for things that aren’t-quite-search has a few challenges, but when it’s all done and working together, it’s a solid solution. In this case, it changed a feature that took so long to run that it’d time out into a feature that can do sub-second searches, and doesn’t rely on any custom code in event handlers to keep track of everything.

SharePoint Designer 2010 – Quick Tips

2010-06-22T19:20:00Z

For the uninitiated, SharePoint Designer 2010 (SPD) has been revamped alongside the rest of Office 2010. Not only does SPD get the ribbon interface now, but it is also a much better tool for interacting and managing SharePoint 2010. Recently, I was using SPD 2010 for authoring some Page Layouts and editing some other supporting pages in SharePoint and I came across a couple of differences between the 2010 and 2007 versions. More specifically:

SPD 2010 tries to protect you from doing dumb things
SPD 2010 tries to guess what you’re thinking (with mixed results)

SPD 2010 tries to protect you from doing dumb things

Consider the following scenario: You want to edit a page layout that has already been customized by a coworker of yours. In SPD 2010, this is relatively straight forward. I click on the ‘Page Layouts’ link on the left-hand toolbox, and then double click on the page layout I’d like to edit. This takes me to that layout’s “dashboard”, which displays information about the file itself (i.e. permissions, versions, etc.). Now, if a user were to click on the ‘Edit File’ link, they open the Page Layout in ‘standard editing mode’. This mode is designed to prevent users from making changes to pages that could cause SharePoint to error out at render time. It accomplishes this by marking parts of the file as ‘read-only’, indicated by yellow shading. However, if I want to make any major change, I would need to close out from the standard editing experience, return to the file’s dashboard page, and then navigate to the ribbon and select the Edit File –>Edit File in Advanced Mode. This would open a fully editable page in SPD 2010.

Reader Beware: You can easily break things in the Advanced Editor; if you’re not sure if you should be using the Advanced Editor, chances are you shouldn’t. :-)

So now that I have a file all opened up in my Advanced Editor, I’d like to move a web part that was previously stored in a Web Part Zone and make it so that it’s a part of the page layout (effectively, not within a web part zone). The advantage of this approach is that I can ensure my content authors can’t edit/delete the web part, so the web part will always display. However, if I ever need to edit/delete the web part, I’ll have to do so in the page layout (which will change all page layouts based on it) or I’d have to detach a page from it’s layout and delete the code. Regardless, this scenario bring me to my next point:

SPD 2010 tries to guess what you’re thinking (with mixed results)

Consider this scenario. I’ve opened up the page layout my coworker started in the Advanced Editor, and I now want to add another web part below the existing web part which is outside of any web part zone. So I click my cursor in just after the closing tags for the first we web part; navigate to the ‘Insert’ menu, Web Part, and select your web part. Now, the problem is illustrated below with the before and after shots. As you can see, by inserting a web part outside of a zone, I have (effectively) deleted the existing web part, which is certainly not what I want. To get around this, you simply need to insert your web part in another area of the document (anywhere will do, just make sure if doesn’t overwrite existing code…This is why I paste in large whitespace areas); then cut the generated code, and paste it right below your existing web part. You’ll happily notice that SharePoint will now allow both web parts to exist outside of a web part zone!

Before:

After:

Stuff-Before:

Stuff-After:

Bonus Tip: If you’re ever in Split View of SPD, and your cursor is in the code view window, and you’re trying to insert a SharePoint Web Part, but the menu item grayed out; here the fix. Click into the Design (preview) view below your code view, click back to code view, and you’ll see that you can once again insert web parts.