有没有人在开发控件时找到了解决DesignMode问题的有用方法？
问题是,如果嵌套控件,则DesignMode仅适用于第一级.第二级和更低级别的DesignMode将始终返回FALSE.
标准的hack一直在查看正在运行的进程的名称,如果它是"DevEnv.EXE"那么它必须是studio,因此DesignMode真的是真的.
问题是寻找ProcessName通过注册表和其他奇怪的部分工作,最终结果是用户可能没有查看进程名称所需的权限.另外这条奇怪的路线很慢.所以我们不得不堆积额外的黑客来使用单例,如果在请求进程名称时抛出错误,则假设DesignMode为FALSE.
确定DesignMode的一个很好的干净方法是有序的.让微软在框架内部修复它会更好!
我有一个程序,Process.Start()另一个程序,它在N秒后关闭它.
有时我选择将调试器附加到已启动的程序.在这些情况下,我不希望在N秒后关闭进程.
我希望主机程序检测是否附加了调试器,因此它可以选择不关闭它.
澄清:我不想检测调试器是否附加到我的进程,我想检测调试器是否附加到我生成的进程.
今天我遇到了一个问题,我需要远程调试一个程序.该程序是从另一个系统启动的,所以我真的没有机会在命令行上与它进行交互.我可以轻松改变它的来源.
我需要做的是让程序正常启动,然后等待我用调试器连接它.我无法想出办法让我开心.我找到了错误,但没有调试器的帮助.
while(true) { }
保持进程活着,然后我可以用调试器"设置下一个语句",但它看起来很尴尬和粗鲁.
Console.ReadLine();
看起来很奇怪,因为实际上没有一个控制台供我输入.(它也没有用.设置下一个语句然后运行会带你回到ReadLine()等待.)
那么我可以在.NET/CLR/C#程序中插入什么样的代码来说"在这里等到我可以用调试器附加"？
当我在Visual Studio的设计器中打开Windows窗体表单时,我的代码中出现了一些错误.我希望在我的代码中进行分支,如果表单由设计者打开,则执行不同的初始化,而不是实际运行.
如何在运行时确定代码是否作为设计人员打开表单的一部分执行？