I haven’t been working in the SharePoint Server space for the last few months as I was needed on an ASP.NET web site project. Currently I’m working in the Geneva (now Windows Identity Foundation) stack and will be doing other work in the WinFx (mostly WCF) space for a while. 

This is a good thing, as using Geneva Server (ADFS 2.0) to implement SSO in SharePoint 2007 and 2010 (unless it’s OOTB) projects will be far more sane, and successful, than with previous approaches.

Depending on how long I’m working on .NET 3.5/4.0 plumbing, the time I spend reverse engineering SharePoint 2010 (and Blogging about it) will vary. The list of features for the 2010 release is impressive, but being the skeptic I am, I’ll be focusing on whatever new issues appear in the platform, VS 2010 support and SharePoint Designer 2010.

This official preview site is actually pretty good.

At least they have the new technology highlights listed like Linq to SharePoint (yeah!).

It seems like I am running into an ever increasing number of usability issues in web sites/applications these days.

It has me wondering what the root cause of this is. Is it a race-to-market issue, or are designers missing these annoyances altogether?

For example, when you search for Accelerators on the ieaddons site, the page you are currently on is used to navigate to this Microsoft site rather than opening a new tab, as I have IE8 configured. Then when you search for a phrase like package tracking without quotes, you get a listing that includes The Gadget Toolbar, which has nothing to do with tracking packages. If you search for “package tracking”, then your search is treated like a phrase which produces zero results. When you search for UPS, you get accelerators like Facebook.

I also like how just clicking in the search box completely clears its contents. I’m sure some user panel decided that was better than having you use backspace…

I would love a chance to sit down and talk to the wingbolts that designed this site. Do they not understand the notion of familiarity? Like with the way Google works? Or is it because the team lives in Mumbai?

Speaking of Browsers, it amazes me that the standard in that space is not an Open Source application.

I am no big fan of Open Source, but this is one place where it would make complete sense. Since every Browser we have to choose from is just a clone of every other Browser (I have been following this from the beginning), there might as well be 1. Why do we need choice? Choice is doing ZIPPO for the consumer!

In fact, maybe I don’t want a browser that allows kids to delete their browsing history! DUH…

While I don’t blame our educational system for this, and it would not be the fault of one country’s system anyway, I do blame experienced programmers for not passing the hard-earned experience along to new programmers entering the field. I also blame the general state of Management in the Software industry, which has never been a model of success and will never get it right.

Since WE can do something about this, I ask that every experienced programmer out there please just try to take some interest in mentoring less experienced folks. These acts will go much farther than reducing your friggin carbon footprint!

A month ago or so, I was at a client doing some work involving an application that required a fast way to JOIN two SharePoint lists. Let me explain.

Sometimes you have a need to store data in 2 or more lists because the data in list ‘A’ represents real world entities that are unique instances, while data in lists ‘B’, ‘C’, etc hold data that is non-unique and reusable by its nature and for our purposes also possesses a 1-to-Many relationship to the data in list ‘A’.

Relational Database Applications 101.

Of course in some cases a data-driven ASP.NET application might be the best course to take; but that might not be an option. So in a SharePoint world, we will use lists and have to find a way to make the relations between lists work in our code in an efficient way.

It is very easy to take a simple approach that leads to performance/scale issues in applications of this type because the WSS Object Model does such a nice job of putting SP objects in collections, and iterating over these collections seems like a natural extension. Except that iterating through list item collections, especially when nested, is quite costly.

In the interest of stating the obvious, of course you will reduce the number of list items you need to iterate over with the appropriate CAML query filtering so that when you form the SPListItemCollection from a list.GetItems(query), it is already minimal in size.

However, in the context of this post, imagine nesting foreach loops to iterate over our ’A’ list, while also iterating over an inner collection of items from our 1-to-Many ‘B’ list. You will start to get close to an N squared situation in terms of Big O notation and computational complexity.

Hence the need for a relational solution with a JOIN.

The solution is rather simple with WSS 3.0, and there are at least 2 versions of an approach you can take that involve placing your SPListItems in DataTable objects as part of a DataSet object.

For reduced footprint and added speed, I like defining the DataTable explicitly in code using just the DataColumns (list columns) I need. This reduces the footprint used over this approach:

DataTable table = list.GetItems(query).GetDataTable();

which returns the items with all column values present, and uses more memory.

Quite a few folks favor the minimalist code approach, and I am no different, but when it matters, performance should be paramount over a few extra lines of code. I tend to make fun of ASP.NET programmers for this same reason, as they tend to fall in love with the “look what I can do with 1 line of code” mantra.

Now you need to define a DataRelation object to represent what you are trying to accomplish with a JOIN and add that to your DataSet. This can transform a (slow) nested iteration over multiple sets of SharePoint list items into a single result set formed in a few milliseconds. Then you do your really meaningful operations on this result set now that the data is aligned.

One comment on this approach with respect to server round-trips.

Since you are working in the realm of a disconnected data set, you are in effect getting all the pertinent list items once. In my specific case, the list queries simply needed to run one time, but there is a caching benefit here that can make a big difference in other application situations.

Lastly, the one way to improve on this further is for the SharePoint Development Team to leverage LINQ in WSS 4.0.

That would be way cool.

In our last episode, there was confusion over the term Office in the name Microsoft Office SharePoint Server 2007.

http://blogs.msdn.com/sharepoint/archive/2009/04/14/microsoft-sharepoint-14-is-now-microsoft-sharepoint-2010.aspx

SharePoint will no longer be showcased at the ODC like it was in 2006 when MOSS 2007 was unveiled. Now SharePoint Server 2010 will be showcased at SharePoint Conference 2009, but it will include Office 2010 developer tracks.

http://blogs.msdn.com/sharepoint/archive/2009/06/01/office-developer-conference-moving-to-sharepoint-conference-2009.aspx

Apparently, the Borg have taken over the SharePoint team and now they have assimilated Office.

Clever diversion – the Office 2010 development team never suspected a thing!

I discovered yesterday that the problem I described in the original post is avoided anytime the document template you are using is a regular document type. In my case, I was using an Excel template rather than an empty Excel document (formatted of course). So it was just a matter of doing a SaveAs in the open template and saving it as a workbook, then replacing the .XLT file being used by the content type I define with its .XLS mate.

I realized that the document type of the “template” was forcing the SaveAs functionality to shift from the default of XLS to XLT because that was actually the file being used.

The key insight that I was forgetting, is that files are opened from SharePoint as-is; SharePoint is blind to Office document templates.

I guess it really is better that MS has decided to drop the Office moniker from SharePoint 2010. Unless MS truly integrated SharePoint with Office, they were no better off than any other document collaboration/management system where Office documents are concerned.

This is old news at this point

http://blogs.msdn.com/sharepoint/archive/2009/04/14/microsoft-sharepoint-14-is-now-microsoft-sharepoint-2010.aspx

but I think it’s an odd Blog post.

Removing Office from MOSS was done because “lots of folks associate the name Office with the Office client“.

Huh?

So a new group of managers and developers comes along, every 2-3 years apparently, and decides that the Office Server concept is what, confusing? I wonder who they asked?

Well, I imagine some survey showed that SharePoint was the real brand and that Office moniker just didn’t mean anything. Usually companies like IBM and Microsoft try to stick a hot brand on everything, ad nauseum. Of course we have not given Redmond a chance to stamp SharePoint on everything yet, so we’ll see.

I also liked this line about WSS 4.0.

“It’s too early to drill into any of the details but WSS is getting a lot of new features and will be a great release.“

I just had to copy that over here so it’s preserved for posterity. Will WSS 4.0 be “a great release” because they finally decided to fix all those pesky bugs? Or, like WSS 3.0, does great mean “great big”. I’m betting on the latter.

Considering the aquisitions MS has made in this space, SharePoint 2010 as a whole is quite likely to be a great big release. I suppose there is a chance that MS may decide not to pile all that social networking code they bought into SharePoint.

Here’s a thought, maybe there will be a dedicated version of SharePoint called SharePoint Server 2010 for Lonely Geeks.

Oh, now I’ve gone and offended someone.

Seriously though, any bets on how many SKUs SharePoint 2010 will actually have?

When creating an Excel 2003 document using the OM, the SaveAs dialog is displayed with the document type of the template (.xlt) instead of the default type (.xls).

If I create the document from the document library ListViewWebPart toolbar, selecting my custom Content Type, the SaveAs works as it always does defaulting to the .xls file extension. 

Under the circumstances at the client I am working for, I cannot try this with Excel 2007, but I suspect it is an Excel issue rather than WSS 3.0. Unfortunately, unlike a number of other warts in Excel, I cannot patch around this with VBA code in the template. When the problem occurs, clicking Tools > Options > Transition tab shows me that the default document type on Save is the default of MS Office Excel Document, or .xls that is.

Strange.

I was working on a small, single page/single web part, application the other day and solving an old problem was essential to making the application usable.

How does one do multiple file uploads with a single file technology?

With out-of-the-box, ASP.NET applications (up to FX 3.5), you pretty quickly realize that the state-less world of web application pages is going to make solving a problem like this considerably more difficult. There are of course many 3rd party controls to choose from that solve this problem, and a few of them are visually beautiful, intuitive to use, and elegant in the way in which page developers make use of them. There are also several core ASP.NET features that have come along to help you and this is all good.

However, when SharePoint is your platform layer, you have the advantage of built-in persistence at your disposal. One might even argue that SharePoint applications are not, or need not be, state-less at all. For example, how would Workflow fare without persistence?

So a solution to a problem like this is pretty easy in our realm. You simply need two things; a postback handler and a document library dedicated to caching uploaded files.

The document library is nothing special. In fact, each time I have implemented this part of an overall solution, I have used the default document library settings to create my “file cache”.

The postback handler is something I almost always use. In WSS 2.0, event handlers were less than reliable, and our team avoided them completely in practice. In WSS 3.0, the situation improved quite a bit. However, postback handling code has several advantages during debug.

To be clear, what I am calling a postback handler, is a nothing more than a dedicated helper method in your web part class that performs parsing and inspection of the HTTP response header. Specifically, the form variables returned on postback.

This postback handler will do at least one thing for you; it will know each time the FileUpload control has been used to upload a client file through the MIME multipart/form-data option (RFC 1867) of an HTTP Post and therefore it can store that file (byte[] or Stream) in your cache doclib.

You will also need a way to keep track of your “list” of uploaded files that are now sitting in your file cache along with every other file that’s ever passed through your web part. There are three pretty easy solutions to this part of the implementation. One approach is to define a column in your file cache that serves as a way to “label” files so they can be associated with one another. Another option, and one I often use, is to define a Hidden control and render it on your page. If you do a View Source on any SharePoint page, you will notice that Microsoft has used this approach a number of times. Lastly, you can also add a folder to your file cache for every “group” of uploads your users do. This folder can be named using a GUID or just text, but obviously it will need to be something meaningful in the context of your application.

Now, the reasons you need  multiple file uploading at all are going to vary. For example, if you are going to compress these files into a gzip archive, wrap the archive with properties and store it in a document library dedicated to such a purpose, you will want an easy way for users to accomplish this.

Placing several FileUpload controls on the page is hardly elegant and completely unneccesary in a SharePoint web part application.

Not that the 3 people who follow this Blog probably care much :-) but I’ll be expanding the scope of this Blog just a bit to include topics that may seem, or will be,  unrelated to SharePoint.