This is a just a short post to remind myself (and you, frustrated googlers/bingers) about the different ways resources are defined and accessed within SharePoint. While some .NET applications use embedded resources or satellite assemblies, SharePoint has a preference for raw RESX files. These resx files are dumped in one of two places:

12\CONFIG\RESOURCES

- application-level "global" resources
- propagated at site definition instantiation
- later modifications require stsadm -o copyappbincontent
- they live in <approot>\App_GlobalAppResources
- accessed via HttpContext.GetGlobalResourceObject / TemplateControl.GetGlobalResourceObject
- http://msdn.microsoft.com/en-us/library/system.web.httpcontext.getglobalresourceobject.aspx
- declaratively accessible <asp:foo runat="server" text="<%$ Resources: myapp.core, ResKeyName %>" />
   (where myapp.core represents myapp.core.resx)

12\RESOURCES
- farm-level global resources
- available to all applications
- remain in 12\RESOURCEs, not copied anywhere
- typically used programatically via SPUtility.GetLocalizedString  ( Microsoft.SharePoint.Utilities )
- http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.utilities.sputility.getlocalizedstring.aspx

Now this is cool. I’ve always wanted to try out TDD, but as I’m primarily a SharePoint developer, a lot of the time my code is written on my laptop running XP, so I can’t actually test anything since SharePoint won’t install there. The folks at Bamboo Solutions came up with some clever hacks to get WSS 3.0 and MOSS running on Vista, but it’s a bit of a heavyweight solution, especially when you consider this:

Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here.

The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

Unfortunately the competition is actually over, but it’s still worth a peek!

I’ve been performing the “resolution” listed in this article since I first discovered the problem, but never ever did I think it was a “feature?” I was sure that I was just the unluckiest person alive and was always working with some dodgy permissions configuration of the 12 hive, but lo and behold, no. This is just the way it’s meant to be.

Anyone else think this is just pure madness? By default any forms you create in Visual Studio have a managed component. Hitting F5 to run deploy/debug won’t ever do the work for you either. Why isn’t this mentioned anywhere in any sort of official capacity? Anybody?

Managed code may not be executed if an InfoPath 2007 workflow form is deployed as a feature for a workflow

SYMPTOMS

Consider the following scenario. A Microsoft Office InfoPath 2007 workflow form contains managed code. The form is deployed as a feature for a workflow. In this scenario, the managed code may not be executed.

CAUSE

This issue occurs because a compiled DLL becomes part of the InfoPath form template (XSN) file when you create managed code behind an InfoPath form. Microsoft Office Forms Services does not extract a DLL by expanding the XSN file when the XSN file is installed by using the features functionality.

RESOLUTION

To resolve this issue, copy the compiled DLL to the same folder to which your feature XSN file was deployed.

http://support.microsoft.com/kb/930894/en-us

One thing I’ve noticed about the SharePoint callback-based Activities in Workflow is that they are extremely flakey if you try to reference the member variable reference for the owning Activity directly instead of casting the “sender” argument in the event handler itself. You have a SharePoint SetState Activity, for exmaple, along with the corresponding MethodInvoking hook and I don’t mean the State Machine transition Activity, but rather the SharePoint-specific Activity that lets you override the Workflow’s overall state string using the <ExtendedStatusColumnValues> metadata in Workflow.xml. In my case, I use the MySetState_MethodInvoking hook to set the state at runtime depending on several conditions. If I try to set properties on the workflow's MySetState member variable directly like this:

private void MySetState_MethodInvoking(object sender, EventArgs e) {

    this.MySetState.State = SPWorkflowStatus.Max + 2;

}

This just plainly doesn’t work reliably. It doesn’t throw any exceptions, in fact it looks to work just fine, except the state is not changed. The same seems to go for any other of the SharePoint interfaces that involve callbacks. In my experience, they just don’t work most of the time especially if the workflow dehydrates before the callback is invoked. This leads me to think that there are some quirky interactions going on internally that somehow cause the workflow to ignore your attempts to change anything, perhaps due to the workflow getting rehydrated after you have made the changes, or who knows. All I know is that if you want this stuff to work reliably, ALWAYS CAST THE SENDER to your target Activity before attempting to manipulate the owning Activity. Using the member variable is just flakey. If anyone has any information on this, let me know. This works reliably:

private vid MySetState_MethodInvoking(object sender, EventArgs e) {
    ((SetState)sender).State = SPWorkflowStatus.Max + 2;
}

Anyway, have fun.