Obviously this is a security risk but at the moment it might be the best way to debug a BizTalk issue I am having.
If you don't know how BizTalk works basically you use a WYSIWYG to generate an assembly. You can't just put your own debug code into the assembly because the code that goes into the assembly is built by the WYSIWYG. What I've discovered is you can take the dll that gets output by the WYSIWYG and edit it with dnSpy, then sign it, and then deploy it. Boom, you can hack any code you like right into BizTalk.
I have it print the callstack near the error and that gives me some idea of what's going on. But the easiest way to figure out this problem might be to just put a try/catch further down the callstack in one of these Microsoft assemblies:
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
at Microsoft.XLANGs.Core.SegmentScheduler._RunSomeSegments(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunSomeSegments(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunMore(Object t)
at Microsoft.XLANGs.BizTalk.CrossProcess.WorkItem.Execute()
at Microsoft.XLANGs.BizTalk.CrossProcess.GlobalThreadPool._workerWithContext(Object workItemObj)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
but of course you can't do that because you can't sign the assembly after you modify it. So you can't put it in the GAC. Can't run it. It's as good as nothing.
Right? Is there any way I can tell windows to be cool for a minute and let me use this unsigned dll to get some work done?
In a word. No.
In fact with the exception of Pipeline components, all BizTalk DLLs have to be signed, otherwise you can't even Import them into BizTalk.
I think you need to post a question with the actual issue you are having, and then someone may be able to point you in the right direction to find the issue.