I get it whenever I debug my workflow! Let me explain. After making changes to my workflow code, I want to see what they do, so I build the solution, upgrade via the WSPBuilder context menu (available by right clicking the project), then Attach to Process, select w3wp.exe (attached to Workflow code) and bam it works.

After I stop the debug and for some reason I want to debug again (having made no changes to code, no rebuild, etc), I Attach to Process and get the above message! Whaaat???

SOLUTION (or what works for me):

Simply Copy to GAC from the WSPBuilder context menu, then Attach to Process and it should work!

Again, I am using WSPBuilder so the solution to this problem may be different if you aren’t using it.

http://www.michaelbowersox.com/2009/01/18/intro-to-wspbuilder/

Something to note: The build and deployment of my first WSP through the program resulted in a feature with a monkey icon as the feature icon, in Site Collection Features, with a title of “A Sample Feature”. After editing some C# code in the project (unrelated to this issue) then customizing the feature and element xml files (I don’t want a monkey as the icon to my workflow feature!), I tried upgrading the wsp through the WSPBuilder context menu. This produced an error messages saying the wsp was tied to another feature of ID ‘GUID here’. The solution was to remove this feature, then remove the solution from the solution store in Central Administration. Then I deployed the new .wsp and all was good.

The “Microsoft.Build.Tasks.Delete” task could not be loaded from the assembly C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll. Could not load file or assembly ‘file:///C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll’ or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, and that the assembly and all its dependencies are available. Platform.StagingAnalysis.Workflow

The “Microsoft.Build.Tasks.Delete” task could not be loaded from the assembly C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll. Could not load file or assembly ‘file:///C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll’ or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, and that the assembly and all its dependencies are available. Platform.StagingAnalysis.Workflow.Services

The “Microsoft.Build.Tasks.Delete” task could not be loaded from the assembly C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll. Could not load file or assembly ‘file:///C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll’ or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, and that the assembly and all its dependencies are available. Platform.StagingAnalysis.Workflow.ConsoleHost

PROBLEM:

The .NET version in the <Import Project /> node in your .csproj file does not match up with the version of the project.

SOLUTION:

 Make sure your <Import Project /> line looks like this:

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets” />

Or if the project is not 3.5, replace with the correct version.

“System.Workflow.ComponentModel.Design.IIdentifierCreationService must be installed for this operation to succeed. Ensure that this service is available.”

1) CLOSE the project and Visual Studio. Open the .csproj file in Notepad and make sure your <ProjectTypeGuids></ProjectTypeGuids> section looks like this:

<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

The project file will have one of them already. These specific GUIDs say the project is a workflow and C# project.

2) Add the following line just inside the <Project> node:

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\<Latest .NET framework version>\Workflow.Targets” />

So the real thing would be (in my case of .NET 3.5; You will get an error if the .NET version of the project doesn’t match up with the version you specify in this line!):

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets” />

And that should do the trick! You will now be able to open the workflow in design mode.

This workflow needs to access the form’s data then insert it into CRM. While debugging, it errored out and I was getting an “HTTP 401: Unauthorized” error when stepping through the section of code which inserts form data into CRM. Hmmm…the user under which the workflow is running has permissions to CRM…which user is it running as? Oh what is this? I assumed it would be running under the host app pool’s identity, but while debugging, I noticed it was running as SHAREPOINT\SYSTEM! WTF? After some hunting around, I found this post which made everything clear:

http://sansanwal.blogspot.com/2009/04/mystery-of-sharepointsystem-account.html

So I guess my port 80′s app pool identity must not have permissions to CRM afterall! Easy fix.

Way to be clear about SHAREPOINT\SYSTEM, Microsoft.

Thanks to the lazy people at Microsoft, I can’t use VSTO to develop WF apps on my 64 bit MOSS setup. Nice.

John Durant, a Visual Studio Program Manager, said, “In any case, we really wanted to support 64-bit in the VS 2008 release, but the effort required more resources than we had. Admittedly, the exception is not terribly graceful, and we have targeted to rectify this in a future release.” I say yeah right. You have billions of dollars and yet you didn’t have enough resources?

Wait, it gets better:

Another VS Program Manager says “The plan for Visual Studio 2010 is to still not support SharePoint 2007 Workflow projects on a 64bit workstation. VS 2010 will avoid the problem of throwing exceptions by hiding the Project Templates for those two project types: SharePoint 2007 Sequential Workflow or SharePoint 2007 State Machine Workflow. However Visual Studio 2010 will support 64bit development of the future version of SharePoint.”

WTF.

I went over Nick Grattan’s tutorial on how to host an InfoPath form in a webpart, again, to see if I missed anything (it’s been a couple months since I first used the XmlFormView webpart):

http://www.nickgrattan.net/Publications/How%20to%20Host%20Microsoft%20InfoPath%20Forms%20in%20SharePoint%20Pages.pdf

All I did to resolve this was reenter the XsnLocation and SaveLocation parameters, and change the SaveLocation URL from /COB%20Inquiry%20Form%20Repository/ to /COB Inquiry Form Repository/.

Yesterday I tried re adding XmlFormView, reentering the XsnLocation and SaveLocation, and redeploying the form from InfoPath, so I don’t know what was actually responsible for it working now – the reentering of XsnLocation and SaveLocation or the changing of the URL in SaveLocation.

Note: if you are following Nick Grattan’s tutorial, remember that you may be using/set up a different form library for storing the form template and saving filled out forms. In my case, the form was deployed to the default location for form templates – http://<yourserver>/FormServerTemplates/. In his case, they were the same libraries (TestInfoPathTemplate).

BACKGROUND: I am migrating this form from one server to another. It works just fine on the old one.

I am able to open the form just fine with the desktop program through the Form Templates form library, but InfoPath form services is giving me “The form has been closed.”

I’ve redeployed the form but to no avail. About to read some tutorials/posts on the web and will come back with my solution, in a bit.