0

我正在使用 Visual Studio 2008 开发一个面向 Windows Mobile 6 的应用程序。开发本身非常简单，但我意识到当我进行常规开发时，我对 VB.NET 中的 Edit-And-Continue 有多么依赖。移动设备模拟器（和设备本身）似乎不支持编辑并继续，这意味着我必须编译我的应用程序，将其部署到模拟器，启动它并到达我正在使用的点（有时需要一两分钟），然后单步执行代码以查看发生了什么。虽然我可以即时更改变量值，但我无法更新任何代码 - 为此，我必须停止执行，更改代码，然后重复该过程。

它导致开发非常缓慢（我可以听到老前辈说“这就是我们那个时代的一切！在编译之前阅读！），我想知道是否有办法让它不那么痛苦。我我试图一次开发更大的代码，所以调试只是痛苦的爆发，但是当我调用错误的属性或附加到不正确的事件时，这仍然是一个非常令人沮丧的经历，然后我必须在制作一个之后重新开始换行。

我曾考虑同时开发一个 Windows 窗体应用程序，将所有窗体对象命名相同，然后在两者之间共享后端代码。这样，我就可以在 Winforms 应用程序上编译、解决错误、编辑并继续，然后在经过审查后将代码复制到我的移动应用程序中。有更好的主意吗？

4

2 回答 2

0

部署到模拟器，而不是设备。

不过，在分发应用程序之前，请在设备上进行测试！

模拟器将允许您逐步执行代码，编辑内存中运行的值，并在执行过程中将更改写入代码。

请注意，在您停止调试器并重新编译之前，您对代码所做的任何更改都不会执行，就像真实设备一样。但是，这些更改将在您下次运行代码时出现。

很多断点。

如果你有很多线程，断点会很烦人。

于 2013-02-06T14:21:02.267 回答
0

这正是我使用大量界面、良好的视图/模型分离和依赖软件服务的原因。我的大部分开发工作要么在桌面单元测试中完成，要么在设备上运行的小型“shim”应用程序中完成，而无需部署和启动整个应用程序。

基本上我的大部分项目都有桌面项目和设备项目，我在桌面上完成大部分功能性工作。我只在需要连接 UI 之类的东西时才使用设备。我不会（或很少）创建桌面 UI 来模拟设备 UI - 如果您这样做，则表明 UI 与业务逻辑过于耦合。

于 2013-02-06T01:01:23.210 回答