Custom UITypeEditor debugging for TGS build definitions
-
Donnerstag, 19. Juli 2012 11:45
Hi,
As usual I'll start with custom "I'm a newbee...".
I'm trying to implement my own custom type editor for user input data in the build definitions.
I'm having a couple of problems, but foremost, how can I debug my code?
How do I dispatch a Custom UITypeEditor from the TFS definitions screen?
And in addition, when ever I make a change to my custom UITypeEditor, in order to see it I have to close and reopen VS?! what am I doing wrong?
Why doesn't the TFS definition screen get the updated UITypeEditor from the DLL? how can I make it reload it?
Thanks,
Oren M.
- Verschoben Forrest GuoMicrosoft Employee, Moderator Montag, 23. Juli 2012 09:27 build automation question. (From:Team Foundation Server - General)
Alle Antworten
-
Montag, 23. Juli 2012 08:32Moderator
Hi Oren,
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.Best Regards,
Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
-
Montag, 23. Juli 2012 09:26Moderator
Oren,
There's a good tutorial about how to implement a UI Type Editor, see here
To debug your code, there're two steps:
- Add code to your custome UI Type Editor project: System.Diagnostics.Debugger.Break()
- Start two VS instance. One for custom UI Type editor runtime, you play with the editor, the other for custom UI Type editor design time project. When the above breakpoint hit, you attach to first instance of VS from second.
When you make change to custome UI Type Editor, I think restarting VS is necessary. Also refers to this article. It's about create custom work flow activity.
Hope this helps.
Thanks.
Forrest Guo | MSDN Community Support | Feedback to manager
- Bearbeitet Forrest GuoMicrosoft Employee, Moderator Montag, 23. Juli 2012 09:27 fix typo
-
Montag, 23. Juli 2012 12:13
Starting a second VS instance is indeed the best way to go. You can even set it as startup command for your assembly for whenever you press F5.
http://msdn.microsoft.com/en-us/library/44t4z67c.aspx
It might be wise to use an Experimental Hyve for that second instance, that way, whenever you break somethign inside Visual Studio, your main instance will remain working:
http://msdn.microsoft.com/en-us/library/bb166560.aspx
My blog: blog.jessehouwing.nl
- Bearbeitet Jesse HouwingMicrosoft Community Contributor Montag, 23. Juli 2012 12:13
-
Mittwoch, 25. Juli 2012 05:28Moderator
Hi Jesse,
Is the issue solved?
Best Regards,
Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
-
Mittwoch, 25. Juli 2012 09:48No clue, it's Oren's issue :)
My blog: blog.jessehouwing.nl

