locked
Isolated shell and workflow debugging RRS feed

  • Question

  • Hi,

    A while back, I asked whether it would be possible to debug a workflow (of the new, .NET 4 variety) from an isolated shell application.  I asked the question in this forum:

    http://social.msdn.microsoft.com/Forums/en/vsxprerelease/thread/ff45a92d-0320-4a72-8d5f-96fbeb038c22

     

    This was the pre-release of VS 2010 extensibility, and it seems like the entire forum is now deleted.  I can still see the forum question in "My Threads" and a snippet of the topic.  The answer I got back from MS was "yes" this will be possible.

     

    However, now that I have the isolated shell setup, it's been RTM'd, and I want to debug a workflow, when I attempt to attach to a process with workflow, and I select a code type, Workflow is not one of the code types listed!

     

    How can I debug workflow from the isolated shell?  Please tell me this is supported!!

    Thanks,

    Notre

    Wednesday, June 1, 2011 7:57 PM

All replies

  • Who answered this would be supported (for context)?  Do you have to explicitly include some kind of packages?  I don't know (haven't looked into) how the workflow debugging works but I imagine they must contribute a special package/dll to integrate with the debugger, perhaps you haven't included that in your isolated shell?

    Ryan

    Thursday, June 2, 2011 7:29 PM
  • Hi Ryan,

     

    I posted the question in the "Visual Studio Extensibility Release Candidate" forum, and Gearard Boland answered that it would be supported.

     

    Unfortunately, since the forum post (actually the entire forum, from what I can tell) has been deleted, I can't review the exact question I asked nor the answer any longer.  I know the answer didn't go into details as to what would be required to make it work.

     

    Thanks,

    Notre

    Thursday, June 2, 2011 8:13 PM
  • I can ping Gerard and see if he investigated it at the time or if the 'yes it will be supported' was just more of a stock answer (since most things should be supported in ISO shell apps, at least as far as I know :))

    Ryan

    Thursday, June 2, 2011 11:23 PM
  • Thanks Ryan - please let me know what Gearard says.

     

    Notre

    Friday, June 3, 2011 3:57 PM
  • Hi Ryan,

     

    Did you get an opportunity to speak with Gearard?

     

    Thanks,

    Notre

    Thursday, June 9, 2011 8:27 PM
  • I did, he said as near as he can recollect it was deemed to be 'possible' if not 'easy'.  He mentioned something about having to chain in some custom MSI to get the bits isntalled or something.  Not sure of the details there.  What have you tried thus far?

    Ryan

    Thursday, June 9, 2011 11:10 PM
  • Oh good, that sounds promising.  I don't mind jumping through some hoops, if I can get some guidance.  At this point I haven't tried anything as I don't know where to start.

     

    Thanks,

    Notre

    Friday, June 10, 2011 3:42 PM
  • I pinged some people internally, and they pinged someone from China who apparently has some experience with this integration, but they have not yet responded, I assume it is already late night there, so maybe tomorrow? Sorry for the delay, hopefully SOMEONE that has done this before will surface :)

    Ryan

    Friday, June 10, 2011 11:19 PM
  • We know its been done before, so hopefully it can be done in the isolated shell and there isn't any artificial constraints around the isolated shell.  I really appreciate your effort on this question.

     

    Thanks,

    Notre

    Monday, June 13, 2011 4:29 PM
  • So, are we talking about v1 Workflows or v2?  Apparently the v1 workflow stuff has a custom debug engine, the v2 stuff simply has an expression evaluator that plugs into the managed debugging framework.

    Ryan

    Wednesday, June 15, 2011 2:32 AM
  • I'm interested in V2 workflows - what they usually refer to as Workflow Foundation 4.

     

    Thanks,

    Notre

    Wednesday, June 15, 2011 4:44 PM
  • This may be the beginning of a long painful process :)  I don't see any sort of merge-module/chainable MSI (though I am far from an setup expert).  It looks like the necessary bits are part of VS setup, which of course doesn't help you. 

    We can try writing out the same registry entries and deploying the same dll's that it does...if we manage to get them all it should work :)

    Start here, the following keys (and all their subkeys/values) would need to be written at the very least (possibly, or likely, more):

    HKLM\Software\Microsoft\VisualStudio\<version>\AD7Metrics\ExpressionEvaluator\{6B9901A8-0102-419D-BC08-56481B08D0ED}
    HKLM\Software\Microsoft\VisualStudio\<version>\AD7Metrics\Engine\{6589AE11-3B51-494A-AC77-91DA1B53F35A}
    HKLM\Software\Microsoft\VisualStudio\<version>\CLSID\{57DC98F7-71BC-4003-97DD-F63527CFBF6F}
    HKLM\Software\Microsoft\VisualStudio\<version>\CLSID\{51B807A8-F98B-4445-A1BE-BB1842A418A8}

    HKCR\CLSID\{3FF9B9E8-85C4-4d99-95B0-345D0742F34C}

    Ryan

    Wednesday, June 15, 2011 8:01 PM
  • Hi Ryan,

     

    It does sound like Pain (purposefully capitalized) and I imagine it will take some time.  So it sounds like, at least to start with, I would need to copy some registry keys and deploy some DLLs.  The first question that comes to mind is, am I "allowed" from a licensing perspective to deploy these MS DLLs with my isolated shell application, if my customer doesn't purchase a copy of VS 2010?

     

    Thanks for your continued help,

    Notre

    Wednesday, June 15, 2011 9:03 PM
  • Doing some more digging (sorry I have been rather slammed with 'other things' lately :() it appears the expression evaluator is in wde.dll, which doesn't appear to be included in the isolated shell redist bits :(  It appears to me the initial 'this is supported' was incorrect, it also sounds like it was based on an internal team having 'rolled this' into their isolated shell app, though obviously internal teams have different rules around bit redistribution.

    How vital is this functionality to your shell?  I have gotten the following information from a PM internally:

    "If the files/dlls are missing, we may have workarounds available (such as installing express, SSMS, or some of our other free products SxS), and if they are in our partner programs, we have, on occasion, allowed 1-off redist agreements to be crafted.

    Ryan

    Tuesday, June 21, 2011 10:20 PM
  • Hi Ryan,

    I can certainly believe you've been busy, and I appreciate you getting back to me. I've been looking at the registry keys you pointed me to earlier. I can see that HKLM\Software\Microsoft\VisualStudio\<version>\AD7Metrics\ExpressionEvaluator\{6B9901A8-0102-419D-BC08-56481B08D0ED} does indeed refer to wde.dll. That DLL looks like's native code, so I'm not up to the task of pulling that one apart into assembly language to reverse engineering it.


    I did notice a second expression evaluator:


    HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\AD7Metrics\ExpressionEvaluator\{1F1149BB-9732-4eb8-9ED4-FA738768919C} which refers to the ExpressionEvaluator class in Microsoft.VisualStudio.Activities.dll. This DLL is managed code, and I can see the class implements IDebugExpressionEvaluator2 and IDebugExpressionEvaluator. I'm confused as to why there appears to be two expression evaluators for workflow. This second one I'm quite sure is for workflow 'v2', but as noted I can't confirm anything regarding wde.dll (even if it is meant for v2 workflows).


    One thing which I may not have made clear in the earlier forum post (the one I linked to originally) and I don't think I made clear at all in this forum post is that I'm trying to do something a little different than just vanilla workflow debugging. What I mean is, I do want exactly the same debugging experience for workflow but I'm rehosting the v2 MS workflow designer WPF control (which is part of .NET Framework 4) inside my own custom VS editor. That is, I'm not trying to use the VS editor that's part of the Microsoft.VisualStudio.Activities.dll assembly, and that is redistributed as part of VS. Instead I have my own editor, in my own package, that hosts the MS workflow designer control. I apologize for the confusion I likely caused, and any of your time I have wasted.

    The original issue I reported in this forum post still applies - I don't see the Workflow code type when I try to attach to a process, from my isolated shell application. But maybe the solution is different - maybe I don't need to redistribute any MS DLLs, maybe I need to write everything myself, including the expression evaluater, etc? I did ask about workflow debugging in the workflow forum and I ironically was clearer there about what I was doing - rehosting the workflow designer control in a custom VS editor:

    http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/6e69566f-5b46-4d17-80b8-c2e73e5207a2

    I got an answer back saying that debugging support is not available for designer rehosting scenarios, that workflow debugging depends on the VS debugging engine. But, I'm not sure that the answerer was clear on what I'm trying to do -- still be in VS (in this case, I didn't mention the isolated shell) where the VS debugging engine is available.

    As to how important this functionality is to my shell, it's quite important for my product. Based on this additional information I provided, do you think the comments you got back from the PM are still applicable, or is it more likely I need to create more debugging related code on my own (rather find a supported way to redistribute certain MS DLLs)?


    Thanks,
    Notre

    Wednesday, June 22, 2011 10:13 PM
  • Hi Ryan,

     

    I got further information back here:

     

    http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/6e69566f-5b46-4d17-80b8-c2e73e5207a2

     

    It sounds like it is theoretically possible to debug workflows, when the workflow designer is rehosted in my own custom VS editor.  Now it's just a question of how to do it :)

     

    Thank you for moving two other recent threads (how to troubleshoot DTE breakpoint errors and getting a sample expression evaluator) to the VS debugging forum.  I'm sure that will help me.

     

    Now my question for you is, and I'm not sure if you can answer it, does it seem likely that the comments you got back from the PM are still applicable, or is it more likely I need to create more debugging related code (presumably an expression evaluator) on my own, rather find a supported way to redistribute certain MS DLLs?

     

    Thanks again,

    Notre

    Monday, June 27, 2011 4:59 PM
  • It has always been theoretically possible, I just don't think it is actually possible as the dll's that contain the workflow debug bits do not appear to be part of the normal redist package for isolated shell.  I don't know if this was a purposeful choice or simply an oversight, though it doesn't matter in the sense that either way they are not there currently.  Andrew may have more context on what the redistribution story is around wde.dll but as far as I can see that is the key piece of the debugging story.  If you have permission to redist that then the rest should just be adding some registry entries, but since it does not appear to be part of the isolated shell redist you don't have automatic redist rights on it.  As the PM said you could have users install Express or you could try talking with people in our partner program about getting a 'one off' redist agreement, that kind of thing is far outside my area of expertise, but I could perhaps point some PM folks at this thread to have that conversation if you wanted.

    Ryan

    Saturday, July 2, 2011 6:03 PM
  • Hi Ryan,

     

    Yes, if you could please point some PM folks at this thread, that would be appreciated.

     

    Thanks again for all your help!

     

    Notre

    Monday, July 4, 2011 10:09 PM