Have you ever gotten this error while debugging a VS workflow by way of attach to process?

Unabletoattachtoprocess

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!

CopytoGAC

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


Here is a good introduction/tutorial to WSPBuilder, an open source “addition” to VSeWSS. Initially I found it to be frustrating, but I think I have a good idea of how to use it properly now.

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.


When building a Visual Studio sequential workflow created from a C# class library project, you may get one or all of these errors:

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.


When creating a sequential workflow in VS, from a C# class library, haven’t modified the .csproj file yet, and try to open the workflow designer, you may get this error:

“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.


So I’ve been working on a workflow to accompany an InfoPath form and ran into a situation:

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.


WTF MICROSOFT?

05Jun09

http://sharepointsharpener.wordpress.com/2009/01/12/developing-workflows-not-possible-on-64-bit-sharepoint/

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.


Solution to: https://sharepointwtfmoments.wordpress.com/2009/06/05/welcome/

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).