Miscellaneous Debris

Avner Kashtan's Frustrations and Exultations

February 2007 - Posts

Sharepoint Extensions for Visual Studio 2005

Any news on when a new release of the extensions are due? The state of the current tools is downright abyssmal. Even ignoring the requirement to run VS on the Sharepoint server machine, half the things don't work or are horribly slow. The Sharepoint Solution Generator doesn't support the most important sites I want to create a definition of (Portals, Publishing sites) and crashes randomly throughout, the WSP generator scripts take almost 5 minutes for a simple list definition, and the Sharepoint Workflow Designer is simply a mess, hard to understand what's going on and how to match a correlationToken between tasks and workflows.

I'm doing a short Sharepoint training week here in Belfast, and half the time I'm forced to show them nice tools and explain why they can't use them yet. :(

Even if the RTM release is still far off and there's nothing stable enough to release as a beta or CTP, I'd appreciate hearing about any progress made. Does the extension team have a blog that I've missed where they release status updates, or haven't they converted to the new, transparent Microsoft way? :)

Word 2007 and Sharepoint Workflows

I've got a couple of questions about Word 2007 integration with Sharepoint 2007, and several problems that occur because of it:

The Mysterious Checked-Out Error

Let's say I have a workflow attached to a document library which creates a data collection task, and when that task is completed updates the document metadata with the task data (say, "Ask for Comments"). For some reason if I leave the document open in Word and complete the task, I get an error in the workflow claiming the document is checked out and can't be updated.

Needless to say, the document isn't. Word only checks out the document before the actual save operation, not whenever it's open. If my workflow updates the metadata directly, without a data collection task, it does work. If Word is closed - it does work.

Even more strangely - if instead of updating the metadata I try to delete the item, it works without a hitch. Update - no. Delete - no problem.

I'm pretty much stumped here, and I'd appreciate any idea.

 

Automatically Closing Word's Connection

Now we have a different workflow - once I've saved my document to the library, a workflow evaluates the metadata and moves it to a new folder depending on the context. Copied aside and then erased, or possibly renamed based on some bit of metadata. The workflow works fine and the document vanishes from the library, but Word is still open and still points to the original location. If the user corrects a single word and presses Ctrl-S, the document will be resaved to the original location, the workflow restarted an a new copy made.

Is there a way to force Word to update the folder or file it's pointing to? Alternately, a way to cause Word to close the document after saving?

"Trial Expired" errors in unexpected places.

I've installed MOSS 2007 RTM on a couple of test VPCs here, using the 180-day trial version. Everything worked fine until I tried to create a new page in my Publishing Portal - suddenly received a "The trial period for this product has expired" message and it won't let me create it. This is strange, since I got this key from Microsoft Downloads 3 days ago. Switching the server to an MSDN key didn't help either, so it wasn't a licensing issue.

Strangely enough, most MOSS features did work - only a handful, like creating pages and associating a custom VS2005-build Workflow with a document library - caused this error. Other distinctly MOSS-based features like publishing and search worked like a charm.

The first suspect was the fact my server is running on a Domain Controller. Seems there's a well-known problem with running MOSS on a DC, and an official workaround by Microsoft that sets some registry keys and reconfigures the server. This problem, however, should have prevented any site from loading, not only that specific error. And anyway, it didn't help.

What several furious minutes of googling revealed is that this is caused by a server in a farm scenario (even a single-server farm) whose application pools are using non-admin accounts. In my case, it was the default NetworkService and LocalService accounts for the DefaultAppPool, MSSharepointAppPool and OfficeServerApplicationPool pools. When I switched them all to using a domain account with admin rights on the server, everything started working.

So in summary:

1) This error still happens on the RTM release, not just the B2TR release as mentioned in the forum post.

2) I can only assume that this doesn't always happen, since I'm sure testing involved creating a single-server farm with all default settings. I have no idea why it happened./

3) The fix mentioned in the link works perfectly, and is heartily recommended.

MOSS Workflows are versioned

I was asked today about MOSS's behavior when workflows are changed midstream. Say I have a document library with a Workflow attached to it, start a few long-running (non-immediate) workflows, then change the workflow before they're completed - will they keep running? Will they use the new workflow or the old, from that point on?

I had hoped for the former, but expected the latter. You can't switch flow in midstream (if you'll pardon my mishmash of similar metaphors), since a newer activity might rely on a variable created by a previous action - one that never took place.

Armed with a burning scientific curiosity and a lack of something to do while the motorway was jammed due to an accident, I set out to check my hypothesis:

 

1) Create a document library with three fields - two text fields and a Yes/No field. The two text fields represent actions taken before and after the change, while the yes/no field is to simulate a long-running workflow that requires other user's interaction:

 

2) Create a simple workflow that updates the Step1 field and then waits around until the Waiting field is set to No:

 

This worked fine, of course - a new document would start the workflow and get its field set to Step1, then wait until I unchecked the Waiting field and then completed. I created another document and left it in the Waiting state.

3) Update the workflow and add another action after waiting - simply setting a value to the post-wait Step2:

 

4) Try it out. I created a new document and verified that Step1 was set before waiting, and Step2 set after waiting. Then I unchecked the Waiting flag on the old document, created with the original workflow.

As expected, Step2 did not get assigned for that document. Despite the fact that the latest version of the workflow had a new action after the Wait, the document was attached to the older version of the workflow, and not the newer. This was also true when I added the second action in a different Workflow Step, rather than a second Action in the same step.

This can be easily seen inside Sharepoint Designer, where we can see that the Workflow's XOML file is just another file stored in just another document library - and like any other document library, it supports file versioning:

 

 

This is a potential cause for confusion - if we have many workflows active and are then required to make a change to it, it's hard to know which workflow is running for which document. The ideal solution would be to complete or terminate all workflows before making a change, but that's hardly a realistic solution for modifying production systems.

Screencasts vs. Whitepapers

A few weeks ago, Lawrence Liu (a senior technical PM and community lead for Sharepoint at Microsoft) linked to a few screencasts for learning how to use various features in MOSS2007. In that entry, he mentioned how screecasts are more effective and efficient in training and learning to use a new piece of software. Me, I'm a bit divided about them:

1) Screencasts are great for getting a hands-on view of the system, that's true. A picture is worth a thousand words, and a movie is worth about 30 frames per second. I know software authors that have replaced the help file completely with a small Camtasia screencast. This, of course, only works for simple programs with few use-cases.

2) As Lawrence mentions, most screencasts are way, way too long. It's understandable - when speaking you want to be as clear and understandable as possible. Too often it turns into a slow, repetitive lecture. To illustrate: last month Microsoft Israel held a Developer Academy conference to give lectures on new Vista dev topics. I squeezed in one Office 2007 talk. Because I was too worried about being clear and understood, I ended up repeating myself. Even a completely non-technical listener who just came in to hear me speak (yes, indeed, it was my mother) said she got the point already and that I should get on with it.

My point? Too many screencasts are way too long. Jan Tielens' SmartPart (and sons) is a wonderful web-part to use and to learn from, but the screencast takes 16 minutes to describe what the 2-page readme.txt contains.

3) Screencasts are mostly a solution to learn the how, not the why. I can use Lawrence's screencasts to learn how to add a library to the Records Center, but I would have found that out myself with little effort. What I would really want right now is a good set of whitepapers to understand the goals of the Records Center and how to use, not abuse it in my solutions.

4) A final tip for screencasts and webcasts - when using Windows Media Player you can speed up playback without affecting the pitch. This is to mitigate slow lecturers and needless repetition. It might require downloading the video locally first. Speeding it up to 140% is usually perfectly understandable.
On my Media Player 9, it's under View -> Enhancements -> Play Speed. Enjoy.

Bad naming - Sharepoint Features

Gaaah! Who, in the name of all that is holy, thought that naming a feature in Sharepoint "Features" would be a good idea? Sure, it describes it, but it also describes practically everything else. It's impossible to find on Google and makes conversation sound more like a Marx Brothers sketch then a technical conversation.

Why? Why? Why?

Outlook Calendar as your Windows Desktop

In a Channel 9 conversation, user Dr. Herbie expressed his long-standing desire to see his Outlook calendar as a desktop wallpaper. This, I admit, has never once occured to me. The nice thing about it is that it's so amazingly simple to implement.

Ever since Windows 98 and the Active Desktop, you could use HTML as the desktop wallpaper and embed anything you want in it. For the last 4 versions at least, Outlook comes with an ActiveX control that lets you display the contents of any Outlook folder in your application. Mix the two - and you have an HTML page that embeds the Outlook View Control maximized to fullscreen, defaulting to today's date, and add two simple Javascript buttons to move back and forward in the days.

A less lazy developer can make this much nicer, with a monthly date-picker and less ugly buttons. Considered as as Proof of Concept, it works with some caveats:

1) Due to the whole Eolas/ActiveX lawsuit fiasco, you need to click on the desktop once to enable interaction with the ActiveX control.

2) You can click on desktop icons, but you can't drag them around (well, without dragging them into an appointment. :). This can be fixed by resizing the control to allow some free desktop space, I suppose.

 

3) This keeps an instance of Outlook permanently in memory. Probably isn't a problem, but good to know.

4) As it stands, the control will mirror the view current selected in your Outlook calendar.

Here's a screenshot of my desktop right now. Thanks for the idea, Herbie!

 

TO INSTALL:

Download the specified attachment (CalendarWallpaper.zip) and unzip into any convenient place. My Documents, for instance.

Then, Go to your desktop properties -> Desktop -> Browse and choose the unzipped file (CalendarWallpaper.htm). Et voila!

More Posts