Using WCF with InfoPath and MOSS 2007

On my current project at Improving we are building custom workflows in Windows Workflow Foundation (WF) to be hosted in MOSS 2007.  Each workflow is kicked off by submitting an InfoPath form, hosted in Form Server.  Some of our application data manipulated by the workflow must be accessible to the forms for drop-down selections and the like.  So, we chose to use Windows Communication Foundation (WCF) as the service mechanism to provide information and services to the workflow and forms.  Here are some issues and solutions I came across while making InfoPath forms work with WCF and developing in Visual Studio 2008.

1. To start off, pick the proper WCF project type.  In VS 2008 you have several different WCF projects to choose from.  I mistakenly chose the WCF Service Library under the WCF project template group instead of the WCF Service Application under the Web template group.  One creates a class library referencing all the WCF assemblies for service development while the other creates a website with a .SVC file, contract files, and service code.  In the end I used a hybrid model with the .SVC file hosted by a website but bound to the service class in a separate assembly.  So I actually used them both!
2. Next, IIS didn't recognize my .SVC file, so I used this article on registering .SVC files with IIS.  Once the .SVC file is properly registered, you can browse to the service with a browser much like you can to ASMX services.
3. With my service built and accessible through IIS, I was ready to configure data sources in InfoPath to submit and retrieve information.  While creating a datasource to populate a list, I realized that InfoPath can't see all web services equally.  WCF had created a WsHttpBinding by default, and it wasn't working.  This article helped me change the bindings to BasicHttpBinding for InfoPath consumption. 
4. At last, with form that bound properly to WCF services and worked completely in preview mode, I was ready to publish.  Publishing wasn't a problem, but I immediately hit another two snags: (1) InfoPath doesn't like webservices accessed via "localhost", not even for testing; and (2) hosting the service on a port other than 80 is considered another site and causes a "cross-domain" connection error from InfoPath and FormServer.  This is a well-known problem for ASMX services, too, but thought I'd provide a link here to InfoPath blog post on Managing Trusted Connections for InfoPath.  I don't like services hosted on port 80 because they become accessible to end-users who hack the URL.  Putting services on another port makes them easier to secure.