Skip to content

Doing the impossible: Maurice Prather clarifies AppDomain Usage

Maurice Prather’s original post on AppDomains to get around some issues with impersonation and the object model was great.  It was an approach that works to allow most applications to do what they need within the SharePoint world — even if SharePoint doesn’t allow the user to directly perform the action.  His update fills in some small holes in the original article — including one or two that I must admit I fell into. Maurice was kind enough to help track down the issue (the second call to impersonate that I wasn’t doing but he was)  and get things straightened out.  My problem was the one exposed by Mike Donovan on IRuntimefilter getting roles for a user.He worked around it with a web service call, but that’s not an option in my environment since performance will definitely be an issue.

I can also say that a SharePoint architect that I placed with another client has used the AppDomain technique to get by a wide variety of issues.  So in short, if you need to do impersonation, this is the way to do it…


Article: Five questions to ask before buying a new tool

Before buying a tool, make sure that you understand the problem, all of the alternative solutions to the problem, what else you’ll need to implement the solution, and whether it’s a problem you should even try to solve on your own. Developing a routine before buying tools will help to prevent purchasing tools that you’ll never use.

My father is a tool guy. He has more tools than any sane person should have. I learned that there are a dozen different saws—each for a different purpose. I’ve inherited this love for tools, although I get more crazy about gadgets than power tools. I realize that I’m not alone. Often times I recognize an automatic instinct in clients towards buying a software package to solve a problem — and occasionally even a hardware purchase. Unfortunately, the tool—whatever it is—is just a tool. It can’t solve the problem by itself. It needs to be wrapped in a solution to solve any problem. Here are five questions to ask before you buy a tool to try to solve a problem.

Do you understand the problem?

Most of the time IT professionals are so pressed for time that they don’t make sure that they fully understand a problem before they try to solve it. We talk about requirements for big projects but we often forget that the same principles apply to smaller purchases.

For instance, a recent client was confronted with a group that needed Act!. Of course, that was a solution, not the problem. The problem was a basic contact management problem. They needed to keep basic details of contacts for a group of people. The client already had Exchange — but ended up purchasing Act! because the requirements weren’t understood. The group that Act! was purchased for is slowly moving back to an Outlook and Exchange public folder solution. (To be clear, there are some problems for which Act! is the right solution — it just wasn’t a good fit for this organization.)

Useless SharePoint Error Messages

I have been promising for a while to get some of my favorite error messages up … here are a few.  I couldn’t find my all time favorite — Catastrophic error.

When you do and don’t want Shelfware

No matter the size of your organization, you can be sure you have old software sitting on a shelf somewhere. Robert Bogue talks about how to reduce the shelfware in your company.

Every organization has “shelfware” (software that has been put on a shelf). Whether an organization has 100,000 people or only one person, you can be sure there’s software sitting on a shelf somewhere in the building. In some ways, shelfware is like cholesterol. There’s a good kind of shelfware and a bad kind of shelfware. The trick is to increase the good shelfware and reduce the bad shelfware.

How does shelfware become shelfware?

There are actually a few different kinds of shelfware, some shelfware was never used or never returned the value that was intended. Other shelfware was retired to its position only after it had performed its service and was no longer needed.

For example, I once licensed a program called LinkBot Pro from Watchfire that validates web references. This tool was invaluable in helping me validate links in older versions of Que Publishing’s Official Internet Yellow Pages. I bought the license, used it for the project, and then it became shelfware. This is a good form of shelfware —software that more than provids its value and is then peacefully put out to pasture.

Preventing users from using the UI to manage web parts

There has been a fair amount of talk lately about how any web part page in SharePoint — including many pages like list pages that people don’t think are web part pages — can have the web parts manipulated by simply adding parameters to the query string.  Those parameters cause the ToolPartPane to appear even if there was no administrative control on the page to cause it to appear.

This is true of the existing pages, but you can create your own site definition that doesn’t allow users to use the user interface to modify the web part placement or even add new items to the web part zone.  The WebPartZone class (and consequently the WebPartZone tag) support three interesting attributes/properties…

  • AllowCustomization – Indicates whether customization is allowed or not.
  • AllowPersonalization – Indicates whether personalization is allowed or not
  • LockLayout – Indicates whether the layout of the zone is fixed — and can not be edited.

Quick testing shows that AllowCustomization must be set to true and LockLayout must be set to false for SharePoint to even show the web part zone in design mode.  Further investigation has shown that using the web services calls to modify web parts in the web part zone still seems to work — and editing the page in front page including web part placement still seems to work as well.  In other words, it’s possible to prevent users from modifying web parts in special zones, like navigation, while retaining the ability to control web parts in these special zones via code.

Folder Taxonomy, Path Limitations, and Meta Data

I was searching out some things and ran across an old blog entry from Bil Simser talking about the limitations of using folders because of path length limitations.  Here are a few observations from a recent client experience.

1) The path limitation is indeed 255 (or 256 characters).  It’s documented in some of the planning documents (and in a KB article as well if memory serves.)

2) The idea of using meta data to categorize information instead of folders has at least two limitations …

a) WebDAV doesn’t natively support the assignment of meta-data during a save operation.  Therefore saving with applications which are not fully SharePoint aware is a bad experience.  The documents end up in the “root” of the view since they have no data to categorize them.

b) Retreiving files without context from a SharePoint document library can be very difficult without the property information.  Since the WebDAV File-Open dialog doesn’t understand the meta data it can be frustrating to find the right document to email to someone when the file name doesn’t contain all of the useful information.  One solution around this particular problem is to use the free Outlook Power Tool for SharePoint from Winapp Technology.  Of course, that doesn’t solve the problem when you’re trying to use a file from another application.

In general… Use meta data if you need the ability to reorganize the data in multiple hierarchies.  Use folders to make it easy to use within non-SharePoint enabled applications.

As a sidebar, the experience on SharePoint with WebDAV is much better in Windows XP vs. Windows 2000.  Every application I’ve tested has been able to save to SharePoint via WebDAV in Windows XP.  The same applications have trouble with Windows 2000’s support for WebDAV.  XP also allows files to be dragged from one WebDAV folder to another where Windows 2000 does not.

No PDC for me

For those of you who have been asking … I’m not going to the PDC.  I had a decision to make — admittedly a tough one.  The MVP Summit is at the end of the month.  I don’t have enough slack in my schedule to do two events in one month.  So, as much as I wanted to hear about SharePoint V3 as soon as possible … I had to decide to go to the Redmond campus at the end of the month.  It gives me a lot more opportunities to talk with the program managers — in a slightly more intimate setting.

So, keep the blog entries about the PDC coming, I’ll be reading them intently.

XML Namespaces and Bad Exception Propigation

Two quick things …

1) If you’re trying to use XPath on XML you get back from SharePoint… don’t forget you’re going to need the XmlNamespaceManager object to use with SelectSingleNode or SelectNodes to get back what you’re looking for.  I repeatedly forget that SharePoint uses XML Namespaces extensively… and that using SelectSingleNode and SelectNodes does require namespaces in the XPath.  (Today was lesson #3.)

2) Bad error handling.  You may find it interesting to note that the WebPartPages web services’ GetWebPartProperties method doesn’t seem to throw soap exceptions.  I ran into my favorite “Cannot complete…” error again.  However, it didn’t show up immediately because rather than throwing a soap exception this particular method returns the error as a comment node — rather than throwing an error.  So you’ll have to look for comments one level down from the root.  (Sidebar: It doesn’t look like this web service even works against SharePoint Portal Server areas.  At least – I keep getting an error about XML namespaces — back as a comment.)

SharePoint: An update on IRuntimeFilter

A few weeks ago I posted on the IRuntimeFilter interface in SharePoint. Here are a few updates…

1) I’ve validated that IRuntimeFilter’s CheckRuntimeRender() method is only called when the IsIncludedFilter property of a web part is non-null.

2) By default, Windows SharePoint Services will put administrators and web designers into a shared page view rather than in a my page view.  The net effect is that the shared page isn’t a personalized view and therefore IRuntimeFilter’s CheckRuntimeRender() method isn’t called.  To fix this create a new site definition and add the following tag into the <HEAD> tag.  <META name=”WebPartPageDefaultViewPersonal”>  Then make sure you do an IISReset so it can take effect.  (You’ll have to create a new site to see this.)

3) ValidateRuntimeFilter() is called everytime the web part is serialized — which is often.  So keep the code that you write in this method very simple.

4) If you decide to do post backs in the chooser form that you create, you’ll need to add a tag to the <HEAD> tag.  That tag is <base target=”_self”>  If you don’t do this then the form will cause a new window to open.

My next step is to fix some impersonation issues with roles (the ones that Michael Donovan mentioned to in his post.  From there, I’ll be writing a IRuntimeFilter chain to allow the Portal audiences IRuntimeFilter to run side-by-site with our own IRuntimeFilter.

How to Gather Windows SharePoint Services Requirements

Getting good requirements for a SharePoint project is in some ways more critical than for a project that’s based on more widely understood technologies. The fact that SharePoint isn’t widely understood by clients — whether internal or external — means the potential for misunderstandings is much greater. For this reason, it’s more critical to discuss each feature of SharePoint to understand of how the feature works out-of-the-box and to understand how the organization envisions those features. Whether you choose to design and architect your SharePoint technologies solution yourself or decide to work with an outside partner to perform the architecture and design steps, you’ll find that having a foundation in solid requirements makes the development process run smoother and results in a better solution for your business needs. [Article removed from the website]

Recent Posts

Public Speaking