我正在开发一个使用Visual Studio 2008定位Windows Mobile 6的应用程序。开发本身非常简单，但我知道在我做的时候我依赖VB.NET中的编辑和继续定期发展。移动设备模拟器（和设备本身）似乎不支持编辑和继续，这意味着我必须编译我的应用程序，将其部署到模拟器，启动它并达到我正在使用的点。 （有时需要一两分钟），然后单步执行代码以查看正在发生的事情。虽然我可以动态更改变量值，但我无法更新任何代码 - 为此，我必须停止执行，更改代码并重复此过程。
导致发展非常缓慢（我可以听到老人们说“这就是我们今天的一切！在你编译之前阅读！”，我想知道是否有办法让它变得不那么痛苦我正在尝试一次开发更大的代码片段，所以调试只是在痛苦的喷射中进行，但是当我调用错误的属性或附加到不正确的事件时，它仍然是一个非常令人沮丧的经历，然后我必须重新开始做出一线改变。
我考虑过同时开发一个Windows窗体应用程序，命名所有窗体对象，然后在两者之间共享后端代码。这样，我可以在Winforms应用程序上编译，解决bug，编辑并继续，然后在审查后将代码复制到我的移动应用程序。有更好的主意吗？
答案 0 :(得分：0)
这正是我使用大量接口，良好的视图/模型分离以及对软件服务的依赖的原因。我的大部分开发工作都是在桌面单元测试中完成的，或者是在设备上运行的小型“垫片”应用程序中完成的，而无需部署和启动整个应用程序。
基本上我的大多数项目都有桌面和设备项目，我在桌面上做了大部分功能。当我需要连接UI和那种东西时，我只移动到设备。我没有（或者很少很少）创建桌面UI来模拟设备UI - 如果你这样做，则表明UI过于与业务逻辑耦合。
答案 1 :(得分：0)
部署到模拟器，而不是设备。
在分发应用程序之前，请在设备上进行测试！
模拟器将允许您逐步执行代码，编辑在内存中运行的值，并在您前进时将更改写入代码。
请注意，在停止调试器并重新编译之前，您对代码所做的任何更改都不会执行，就像真实设备一样。但是，下次运行代码时，这些更改将会存在。
很多断点。
如果你有很多线程，断点就会很烦人。