Skip to content

September 20, 2005

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.)

Recent Posts

Public Speaking