But my current problem is that my web service doesn't act the same when hosted under MOSS as it does in a stand-alone site on the same server. In fact, it's broken. Here's the situation:

I created a web service with several web methods in .NET. I test the execution of the methods from VS2005 using the browser. All is well.

I publish the web service to a site hosted in IIS. I setup the site to use my MOSS application pool, to execute scripts, and to allow browsing. Now I can browse the site and get the handy web service test page. I click on an operation, enter the parms, and invoke it. All is well.

Now, if I connect an InfoPath form to that web service and publish it to a form library in MOSS, upon creation the form fails to connect to the web service because the web service is in a "different domain" (not really....but that's what it says).

So, we avoid the "different domain" problem by publishing the web service under the MOSS application. Do this by creating a Virtual Directory under the MOSS application's web site. Like with a stand alone web service site, go to the properties on the vdir, create an application, and set the permissions to run scripts. Publish the web service to this new location (only accessible to VS2005 by the file system, not via local IIS) and test it out. Initially, all *seems* fine - but some of the operations don't work. After entering parms and clicking "invoke", the operations result in a 500 server error.

Oddly, I have the service hosted in the stand-alone site and the vdir under MOSS at the same time and it behaves differently depending on the URL used to access it. Stand alone it works, and managed by MOSS it fails....on some operations but not others.

I think the solution may have to do with the "Web Service Proxy" page found at the bottom of the Application Management page in Central Administration. It would be nice if the help files mentioned it or if the search in the help files could find anything remotely similar to my search criteria.

2006.08.31

In Windows Workflow Foundation, there is a built-in activity called InvokeWorkflow that asynchronously launches another workflow. But then you have to wait for it to complete. I've heard a couple of people complain about no built-in support for synchronous invocation and am at a point where I need it myself. I came across this post from Jon Flanders where he has already solved the problem by writing a synchronous CallWorkflowActivity and made it available for download.

2006.08.29

I'm writing custom workflows and workflow activities using Windows Workflow Foundation. To be used in SharePoint v3/2007, the assemblies have to be installed in the Global Assembly Cache. And as with any assembly installed in the GAC, they must be strongly signed.

Here's a nice little article walking you through most of the steps to sign an assembly in Visual Studio 2005. One step they left out is creating the GUID with the Tools > Create GUID... menu item in the IDE. First, create a GUID in registry format and copy it to the clipboard with the Copy button. Then paste it into the Assembly Info dialog as shown (but not explained) in the article. You probably have to manually remove the { and }, so I did.

So, we have an RTM'ed CS2007, which supposedly integrates beautifully with MOSS, but no guidance on how to do it. Nice.

However, I did read in Ryan's earlier post on CS and content management (where he told us SharePoint and CS would work together so beautifully) that "the Starter Site's runtime controls can be easily repurposed to be deployed in a next-generation SharePoint portal site." So I'm going to give it a try. Of course, I do realize that it's way too early to be mucking around with CS and MOSS. Sadly, I'll probably have to change direction to some lame InfoPath product order form. But after the hell we went through figuring out custom workflow in MOSS, we can't really afford much more exploration on my current project. I'll let you know how it goes.