Part 1

To change Propertie fields that are not plain text fields there are some problems in addign specific data to these columns.

for example:
You want to add a user to the assigned to field from an item in a TaskList

This won't work!
oNewTask["Assigned To"] = "DOMAIN\\Tom.VanGaever";

Instead you should use

when you are in a WorkFlow you can use
m_selectItem = WorkflowProperties.Item;
newTask["Assigned To"] = m_selectedItem.Web.AllUsers["DOMAIN\\Tom.VanGaever"];

Otherwise use the SPWeb object of your sharepointsite
SPWeb oWebsite = collWebsites["Site_Name"];
newTask["Assigned To"] = oWebsite.AllUsers["DOMAIN\\Tom.VanGaever"];

Why?
A User field contains a string in the form ID;#User_Display_Name, where ID is the member ID of the associated user. The following example parses the value of an Assigned To field to return an SPUser object.

string strUserValue = oList["Assigned To"];
int intIndex = strUserValue.IndexOf(';');
int intID = Int32.Parse(strUserValue.Substring(0, intIndex));
SPUser oUser = oWebsite.SiteUsers.GetByID(intID);

The development of SharePoint Workflows is not so complicated as you might think.

But you need the right tools:

Visual Studio 2008 and VSTO Power tool: SharePoint Workflow package generator combined enables you to debug realtime on your development server and everytime you build your workflow the SharePoint Workflow package generator creates a wsp file that you can install on the productionserver...fantastic!

The combination between the powertool and VS2008 is not out of the box, you need to add a few XML code lines to your csproj/vbproj file to get a wsp file after every build.

What do you need:

Visual studio 2008
VSTO Powertools

Start Visual Studio on your development server for debug purposes. Create your workflow and hit F5! :)

If you want to create a wsp (solution) file every time you build at the following code at the end of your csproj/vbproj file,

First of all instal the Powertools from the site above.

Secondly enter these lines of code

<Target Name="AfterBuild">
<Exec Command="&quot;C:\Program Files\Microsoft VSTO Power Tools 1.0\Workflow Package Generator\workflowpackagegen.exe&quot; /featureManifest:feature.xml" ContinueOnError="true">
</Exec>
</Target>
</Project>


Finally hit Ctrl+b

Now you see that there is an [solutionname].wsp in your project directory.

If you're an Office 2007 user, the image above probably looks pretty familiar. But look close, and you'll see some Save-As options you've not seen before here: OpenDocument, and (unless you have the existing add-in) PDF & XPS.

This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2.

read More here

This will allow you do develop on your workstation with all the power of a non virtualized environment. You still need VPC and VMWare so don’t feel sorry.

http://community.bamboosolutions.com/bl ... 4-x86.aspx

There are some funny things going on inside SharePoint, and this is one of the funniest…

We have a list, with two fields:

<Field
  Type="Text"
  DisplayName="Category"
  MaxLength="255"
  Name="Category0"
  ColName="nvarchar17"
/>
<Field
  Name="Category"
  FromBaseType="TRUE"
  Type="Choice"
  DisplayName="Category (deprecated)"
  Format="Dropdown"
  FillInChoice="FALSE"
  ColName="nvarchar2"
><!-- CHOICES --></Field>

Note that one has the DisplayName of ‘Category’ and the other has the Name of ‘Category’.

The one with the Name ‘Category’ is deprecated, and we actually want to populate the field with the DisplayName ‘Category’.

You’d expect this would be fine… so consider that we have an empty list and that we create a new item and try and populate the item:

SPListItem newListItem = spList.Items.Add();
newListItem["Title"] = "The title";
newListItem["Category"] = "Category 1";
newListItem.Update();

That should work right? I mean MSDN very plainly states that on a SPListItem that you access a field using the DisplayName of the SPField that you want to set the value against.

It tries to populate the wrong field.

Why? Because it seems that if a SPField exists that has an InternalName the same as a DisplayName, then that SPField takes priority. As the Name property of a SPField *is* the InternalName, we’ve actually just attempted to assign the string “Category 1″ to the Choice Field that is “Category (deprecated)”.

A very subtle but pain in the arse thing that.

So how to get around it? Well, instead of passing in the DisplayName you can use the overloaded version of spListItem[] to pass in the int32 index of the SPField in the spList.Fields collection.

So if you loop the spList.Fields collection, work out where the real “Category” field is that we want to update, and grab the index… you’d expect to be able to update the list item right?

Right, but… not if the item you are creating is the first item to ever go into the list. It will work for every subsequent item, but never the first item.

For some reason the index based accessors only work after an item exists, so if we go back to that original piece of code and update it with the Field index:

SPListItem newListItem = spList.Items.Add();
newListItem["Title"] = "The title";
newListItem[2] = "Category 1";
newListItem.Update();

That won’t work.

Instead you have to save the item, and then grab a fresh instance of the item and save that:

SPListItem newListItem = spList.Items.Add();
newListItem["Title"] = "The title";
newListItem.Update();

SPListItem existingListItem = spList.GetItemByID(newListItem.ID);
existingListItem[2] = "Category 1";
existingListItem.Update();

And that piece of code works.

The rules here:

• You can’t set a value to a field using the DisplayName if another field exists with a matching Name / InternalName.
• You can’t use the index based accessors until an item exists within the SharePoint list.