FitzBlog : Developers

The RTM SDKs Will Be Downloadable on November 28th, 2006

MikeFitz — Fri, 17 Nov 2006 21:31:00 GMT

I jumped the gun in yesterday's second post when I said the SDKs were ready along with the downloadable trials. They are indeed finished being written, but there are more hoops than you can imagine getting things staged, approved, tested, etc. for distribution on MSDN. The date of availability is the 28th of this month (November 2006).

While we're on the subject of SDKs and particular and developer information in general, I wanted to make a couple of quick comments. You may have seen them elsewhere, but maybe you haven't.

Our strategy this time has been to make the SDKs as good as possible rather than get something out the door and backfill it for two years with whitepapers. We had a really good team spend a lot of time on this for the 2007 releases, and the situation is markedly different from the 2003-era offerings. I hope you'll notice the difference.
There *will* be whitepapers, but they'll be focused on best practices, recommendations, case studies with code, big picture advice coupled with tactical advice, that sort of thing. But there will be a multi-month gap before the first one comes out, because:

<tirade>You can't define best practices without observing several practices and choosing the best; offering "best practices" on Day 1 would mean we already know every way people will use our handiwork (naive at best) or we're just making stuff up.</tirade>

We'll publish opinions on recommended practices in the team blog, my blog, and plenty of other blogs, but until we can see them validated out in the wild, we'll continue to call them best practices.

The November 28 drop of the SDK won't be the last. We'll do incremental drops as needed or wanted, and sometimes we'll fold whitepaper content directly into the SDK where it makes sense. The goal is always going to be that the SDK is the ultimate authoriative reference.

We're at work on training and certification for developers (we're also working on training/certificaiton for IT Pros, but that's for Joel Oleson to discuss):

We're opting to deliver these as e-learning rather than as instructor-led classroom content. We can reach more people and offer it when you need it, where you need it this way.
You'll still need to go through the SDK once you're done with this content, mind you. Nothing ever absolves you from knowing the SDK :-)
We'll release WSS 3.0-targeted content in early 2007; MOSS 2007 content will follow a few months later. All of the WSS content applies equally to MOSS; the MOSS courseware will solely cover features unique to MOSS, so the WSS course, or equivalent knowledge, will be a prerequisite. The exams will surface shortly after the elearning courses surface.

Couple this with the number of books under development, the third-party courseware offerings, the wide variety of content you can find on the Web in general and the blogosphere in particular, etc., you're not going to have trouble finding out what you need to know this time.

Early Xmas Present from the Search and BDC Teams: Custom Security Trimming

MikeFitz — Fri, 17 Nov 2006 03:32:00 GMT

While we generally lock down features many months before we get to RTM and spend all of the remaining time on performance and stability, there are a few – very few – number of times when we find we really have to squeeze in one more feature at the last minute. It happened with the RTM release of Microsoft Office SharePoint Server, and it required the cooperation of both the Search team and the team that works on the Business Data Catalog. The feature? Support for custom query time trimming of search results.

You know how we can trim search results so users only see links to items they can actually open? That works great today as long as the content source being indexed could serialize the Access Control Lists for each item we'd index. When that works, we actually record the ACL in the index at index gather (a.k.a., crawl) time. And since we know who you are when you execute a search, we'd just compare your userid/group memberships to those in the ACL and either display or not display the search result accordingly.

But what do you do when the content source in question can't serialize its ACLs (e.g., a normal Web site), has a completely different approach to security (LOB systems), or can't serialize ACLs in a way we'd be able to make sense of them (some third-party content repository with its own user/group management)?

I'll tell you what you do. You create a component that implements the ISecurityTrimmer interface. We'll call its Initialize() function once and then hit it with one or more calls to the CheckAccess() function, passing you URLs and context info. Your job is to call whatever code you have to call for each of these URLs and return to us a bitarray that tell us which URLs can be viewed by this user. We'll keep calling CheckAccess() until we build up enough results to fill a page (or until you set a flag that tells us you want us to stop).

This is all documented in the SDK that became available for download today at http://msdn.microsoft.com/office/sharepoint. Search for "Custom Security Trimming" and it will all fall into place.

Now, this would be great by itself, but the BDC gang did their part as well. There's a BDC Custom Security Trimmer in the box. As long as the application definition XML file has an Entity with a Method with a MethodInstance of type "AccessChecker", we'll use it for custom trimming purposes.

Before someone says it in comments, of course this can have an impact on query-time performance. How much will depend on your LOB system's API performance and the ration of results to authorized results. But the alternatives are (a) don't search repositories that don't provide ACLs at index gathering time, (b) don't worry about security on search results of such data, or (c) create a custom protocol handler for searching such sources and have it incorporate a security mapping layer of some kind that translates the back-end system's security model into something that looks like NTFS ACLs. Me, I'd take the tiny hit and reap the massive benefits J.

I'll work on getting an example of both a custom trimming component and a BDC application definition that references an AccessChecker method posted to GotDotNet, and when I do, I'll post links here.

More postings on integration topics to follow. Yes, I'm back and blogging up a storm for a while…

Using ASP.NET for AJAX in SharePoint Sites: Tread Gently for Now

MikeFitz — Fri, 17 Nov 2006 02:23:00 GMT

We get asked about what we're doing about AJAX quite a lot these days, especially about ASP.NET for AJAX (the technology formerly known as "Atlas"). We *love* AJAX. We actually use AJAX (albeit not ASP.NET for AJAX) all over the place in SharePoint sites. Dropdown menus when clicking on Edit Control Buttom (ECB) menus? AJAX. The Settings menu on a site's home page? AJAX.

As for ASP.NET for AJAX, we love it (we're ASP.NET developers ourselves – how could we not? J), we're excited to see Beta 2 emerge, but given that we started working on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 in late 2003, it wasn't possible to engineer those products to ensure 100% compatibility at RTM.

We've been investigating this issue very carefully. We've been working directly with the ASP.NET team to come up with the nicest possible way of giving you the ability to make all of this work. But we're not ready yet. We know some things work fine, other things will work fine once one or both of our teams have done some extra work, and a few (hopefully very few) things won't be supportable in SharePoint sites.

Until we're ready, though, we'd truly appreciate it if you let us work it out rather than trying to hack a solution of your own. It will take some time, but whatever we're able to work out will be something we can support.

Here's what we can say with confidence today:

We will, when we release Service Pack 1 for Windows SharePoint Services 3.0, officially support some – but probably not all – uses of ASP.NET in SharePoint site application pages, site pages, and Web Parts. Note that we just shipped WSS 3.0, and no, we don't yet have a target date for SP1. But when it comes out, it will include any work we believe we have to do for this (along with the usual bug fixes, etc.). We'll specifically tell you which ASP.NET for AJAX techniques are supported and which aren't. We'll have tested those scenarios and we'll know what happens with the techniques we wind up supporting.
Until we release Service Pack 1 for Windows SharePoint Services 3.0, ASP.NET for AJAX is not supported. You're welcome to experiment with it, but we cannot endorse you using ASP.NET for AJAX on a production deployment of WSS 3.0, MOSS 2007, etc. If you do so anyway, you're in the support business for that kind of thing and/or you'll have to depend on the community for assistance. I, and the team, doesn't wish to be mean about this, but when we say we support something, it's because we've tested it under many, many use cases, know what to expect, etc. We can't say that today.

Besides, you're going to have enough to get done with SharePoint Products and Technologies given that you can download WSS 3.0 on the 16th of this month, aren't you?