CAML.NET assembly - write your queries in C# - and you can find it on Codeplex.

Queries are now as simple as:
string s = CAML.Query(
CAML.Where(
CAML.Eg(
CAML.FieldRef("SomeField"),
CAML.Value(someValue)
)
)
)
This is such a blatantly good idea that I’m giving it a

Comments from my old blog:

Now that *is* a good idea…

By Jonathan at 17:11:14 Sunday 13th May 2007

What he was doing way using the same SPWorkflowTaskProperties for the OnTaskUpdated.AfterProperties, and the UpdateTask.Taskproperties. This seems natural enough - he wanted all the updated task data (in AfterProperties) in the task properties, so why not use the same object for them both?

Naturally, this doesn’t work . The result was that the task didn’t update, and he was getting the error “Task update was not accepted“. Why, I don’t know - what Maxim was doing seems perfectly reasonable. Instead what you’ve got to do is write code to copy across all the properties you want. Crazy.

To be sure (i.e. to confirm what he told me) I was going to create a test workflow as he’d described - but I’d a vague feeling that I’d seen this before - and looking though my notes (yes, I keep notes. Rough ones. With doodles) I find that yes, this was the first thing I discovered when trying to use the UpdateTask activity. I’d just forgotten (and probably hoped it was a Beta thing). I wonder how many other folks have been caught out by the same problem?

It also explains why I wasn’t doing things in the way Maxim was describing - ‘cos it did seem reasonable, and a good way to reduce the number of SPWorkflowTaskProperties objects in your workflow…

(Note to self - remember this, and tell others)

Comments from my old blog:

Bless… it works, thanks!

By Sharepointer at 12:12:31 Wednesday 18th April 2007

Hi, Read your article and its useful.
I have a scenerio where i have to use the update Task Activity in a State Machine Workflow.
If you have an Example, i will be highly greatful to you.

Thanks in Advance

-Manoj Iyer
Globaltech India.
manoj@thegt.com

By Manoj Iyer at 07:31:05 Monday 4th June 2007

My problems are that we have master pages - which is great. And we’ve got seperate master pages for standard pages, and administration pages. Okay, I’m happy with that. However, there is a mechanism for changing the master page for normal pages - but nothing for administration pages. ‘Cos nobody will ever look at them, right?

Then there is the question of master pages and themes. I really like some of the themes that come OOB, much more so than the default ‘blue’ (I like ‘Simple’). But they can only be applied on a site by site basis; there is no inheritance mechanism. And if you use a master page, it’ll probably override the theme anyway. So why have themes? Why not just use master pages?

1. The (potential) customer always wants to see 90% of the functionality in the demo - no matter how custom that development is. (This is a case of managing expectations)
2. The complexity of the demo is inversely proportionate to the time available to build it. (Beat the salesman until he understands, then cut all the complex bits and proceed as above)
3. The customer will want to see all logins for all the different users in a process used - and will then yawn as you switch between accounts (and yes, I know about ‘Run As…’. Even so, they’ll yawn). (Don’t show it. Or do it once, and then explain that you’re going to stop switching for the sake of sanity/getting to lunch on time)
4. The bit that you spend ages on getting working because it “must be shown” won’t be shown. (Try to find out how important these hard parts really are)
5. The bit that you spend 5 minutes on, doesn’t do anything, but looks pretty will get them really excited. (This is good! Make sure you show them the exciting stuff)
6. The customer will be utterly confident that they know their business process - and then through the course of the demo show that they don’t. (Try to help them see this, and consider re-engineering/redfining the process. If they won’t, steer clear or work on a T&M basis…)