问题标签 [legacy]

我的公司有大量用 VB6 编写的遗留应用程序。

我们正在从将 VB6 应用程序迁移到 .NET（特别是 3.5）。

将 VB6 迁移到 .NET 的最佳策略是什么？

注意：以下更新应转到“项目管理”，与主要问题无关。

[更新]：感谢您到目前为止的反馈
现在有更多问题弹出

1. 您将如何分配开发人员来开发新的应用程序？
2. 是否应该有一个特殊的一次性升级部门将旧应用程序转换为新应用程序？还是每个开发人员都应该参与转换过程？
3. 只有高级开发人员才能参与转换吗？初级开发者？还是混合的？

似乎，我对这个问题思考得越多，就会出现更多的问题。

我有一个客户有一个旧的不存在的应用程序；他与提出申请的公司有问题，他们不会透露他的数据库密码。他意识到他（当时）签署了一份合同，其中说他是在“租用”该应用程序，他们无权透露任何内容。这位客户发现他并不是唯一一个与该公司有同样问题的人。他是一名牙医，使用相同旧应用程序的其他牙医在尝试购买新软件并试图将他们的患者迁移到新系统时遇到了同样的问题。

无论哪种情况，他都想打开他的小火鸟数据库，这样我们至少可以将一些数据提取到我们的 SQL Server 中。我尝试使用默认的“masterkey”（实际上，由于 8 个字符的限制，“masterke”）无济于事。

现在我知道他可以合法化并试图强迫公司发布他的信息，但我想用捷径做。有人知道可以暴力破解/破解旧版 Firebird 密码的应用程序吗？

谢谢。

编辑：旧版软件是“STOMA-W”，我什至在互联网上都找不到。他们位于西班牙的阿斯图里亚斯。

出于某种不正当的原因，我想尝试 Python 1.0。我将如何编译它，或者更确切地说，可以使用当前编译器干净编译的早期版本是什么？

我使用的是 Mac OS X 10.5，虽然只是出于好奇（关于语言如何变化），所以在 Linux 虚拟机中编译也是可能的。

有没有人有将 FxCop 引入遗留代码的经验？如果有人引入违反规则的代码，我们希望我们的构建失败。但就目前而言，这是不可能的，因为遗留代码有超过 9000 次违规。

我所知道的抑制错误的唯一方法是通过 SuppressMessage 属性，但这仅适用于方法和 GeneratedCodeAttribute。最后一个可以用于类和命名空间（如果我没记错的话），但不应该用于非生成代码（参见此处）。

现在，我们每天都会花一些时间来消除违规行为，但会不断引入新的违规行为，因为我们的构建不会失败。

有任何想法吗？

我们使用将整数值保存到 varchar 列的遗留数据库。我们需要将此列映射到 Int32 属性，如果数据库列中的数据是数字或 NULL，它会很好地工作。

但是，如果列包含空字符串而不是 null，我们就会遇到问题 - nhibernate 会抛出无法将其转换为整数的错误。

是否可以配置类映射以自动将异常引发的所有值转换为某个默认值（在这种情况下为零）？

我们有一个用 C 编写的大型多平台应用程序。（使用少量但不断增长的 C++）它经过多年发展，具有许多您期望在大型 C/C++ 应用程序中具有的特性：

• #ifdef地狱
• 难以隔离可测试代码的大文件
• 过于复杂而无法轻松测试的功能

由于此代码是针对嵌入式设备的，因此在实际目标上运行它会产生很多开销。因此，我们希望在本地系统上以快速的周期进行更多的开发和测试。但我们想避免“复制/粘贴到系统上的 .c 文件、修复错误、复制/粘贴回去”的经典策略。如果开发人员要不厌其烦地这样做，我们希望以后能够重新创建相同的测试，并以自动化的方式运行。

这是我们的问题：为了将代码重构为更加模块化，我们需要它更具可测试性。但是为了引入自动化单元测试，我们需要它更加模块化。

一个问题是，由于我们的文件太大，我们可能在一个文件中有一个函数，该函数调用同一个文件中的一个函数，我们需要将其存根以进行良好的单元测试。随着我们的代码变得更加模块化，这似乎不再是一个问题，但这还有很长的路要走。

我们想做的一件事是用注释标记“已知可测试”的源代码。然后我们可以为可测试代码编写脚本扫描源文件，将其编译到单独的文件中，并将其与单元测试链接。当我们修复缺陷并添加更多功能时，我们可以慢慢引入单元测试。

但是，有人担心维护这个方案（以及所有必需的存根函数）会变得太麻烦，并且开发人员将停止维护单元测试。所以另一种方法是使用一个工具，自动为所有代码生成存根，并将文件与它链接起来。（我们发现可以做到这一点的唯一工具是昂贵的商业产品）但是这种方法似乎要求我们所有的代码在开始之前都更加模块化，因为只有外部调用可以被存根。

就个人而言，我宁愿让开发人员考虑他们的外部依赖关系并智能地编写他们自己的存根。但是，对于一个 10,000 行的文件来说，这可能是为了消除所有依赖关系而难以承受的。可能很难说服开发人员他们需要为所有外部依赖项维护存根，但这是正确的方法吗？（我听到的另一个论点是子系统的维护者应该为他们的子系统维护存根。但我想知道“强迫”开发人员编写他们自己的存根是否会导致更好的单元测试？）

#ifdefs当然，这个问题又增加了一个完整的维度。

我们已经查看了几个基于 C/C++ 的单元测试框架，并且有很多看起来不错的选项。但是我们还没有找到任何东西来缓解从“没有单元测试的毛球代码”到“可单元测试的代码”的过渡。

所以这是我对其他经历过这个的人的问题：

• 什么是好的起点？我们是在朝着正确的方向前进，还是我们错过了一些明显的东西？
• 哪些工具可能有助于过渡？（最好是免费/开源，因为我们现在的预算大约是“零”）

请注意，我们的构建环境是基于 Linux/UNIX 的，因此我们不能使用任何仅限 Windows 的工具。

我为最初针对 MSDOS 的程序继承了一个相当古老的大而复杂的代码库。事实证明，该程序的某些部分是用 x86 汇编程序的一种晦涩方言编写的，称为“Phar Lap assembler”，以生产该汇编程序的公司和产品命名。我已经进行了相当深入的谷歌搜索，但我找不到原始的汇编程序或任何有关它的信息或文档。（尽管我在专家交流中发现了一些相当令人沮丧的页面，人们提出了类似的问题）。

所以基本上，在我找到 PharLap Assembler (386asm.exe) 的副本，或者找到足够的有关方言的信息将其翻译成更“标准”的 MASM 之前，我将无法编译这个东西。 . 要么，要么尝试通过阅读来弄清楚它。

或者，如果这都不可能，那么我只需要一些帮助来解决这个问题，我至少应该能够编译程序的一部分。

.c 文件中有一个结构声明，如下所示：

然后有一些看起来像这样的汇编器，它可能试图做出相同的类型声明，以便一些汇编器代码可以使用相同的类型：

这在最后一行编译时出现错误，如下所示（watcom 汇编器）：

所以基本上，我认为这是说这个结构的汇编版本与这个结构的 C 版本不匹配。我已经在汇编器中尝试了多种 WORD 和 DWORD 的不同组合来代替 dd，但我无法克服这个小问题。也许如果我能找到一种方法让这两个声明完美匹配，我对 pharlap 信息的需求就会减少。

另外，如果有人能为这个庞大的问题想出一个更好的标题，我愿意接受。

编辑：好吧，事实证明我浏览了一些重要信息。这是一个最初为 Phar Lap 汇编器（我没有）编写的文件，我正在尝试使用 watcom 汇编器（wasm）进行汇编。事实证明，该特定错误的问题在于 Phar Lap 似乎区分大小写，而 watcom 不区分大小写。所以它认为 bhashctl 与 BhashCtl 相同。在我姐夫的帮助下解决了这个问题。我永远不会想到不区分大小写是导致该问题的原因。

我们正在使用基于 gcc 2.6.0 的旧版编译器来交叉编译我们仍在使用的旧嵌入式处理器（是的，它自 1994 年以来仍在使用！）。为这个芯片做 gcc 端口的工程师早就离开了。虽然我们可能能够从网络上的某个地方恢复 gcc 2.6.0 源，但该芯片的更改集已经在公司历史的大厅中消失了。直到最近，我们一直在糊涂，因为编译器仍在运行并生成可运行的可执行文件，但从 linux 内核 2.6.25（以及 2.6.26）开始，它会失败并显示消息gcc: virtual memory exhausted... 即使在没有参数或仅使用-v. 我已经使用 2.6.24 内核重新启动了我的开发系统（从 2.6.26 开始）并且编译器再次工作（使用 2.6.25 重新启动不会）。

我们有一个系统保持在 2.6.24，只是为了构建这个芯片，但是感觉有点暴露，以防 linux 世界发展到我们不能再重建一个可以运行的系统编译器（即我们的 2.6.24 系统死掉了，我们无法在新系统上安装和运行 2.6.24，因为某些软件部分不再可用）。

有没有人知道我们可以对更现代的安装做些什么来让这个遗留编译器运行？

编辑：

回答一些评论...

可悲的是，丢失了特定于我们芯片的源代码更改。这种损失发生在两个主要的公司重组和几个系统管理员（其中几个确实留下了一个烂摊子）。我们现在使用配置控制，但这对于这个问题来说太迟了。

使用虚拟机是一个好主意，并且可能是我们最终要做的事情。谢谢你的想法。

最后，我按照ehemient的建议尝试了strace，发现最后一个系统调用是brk()，在新系统（2.6.26内核）上返回错误，在旧系统（2.6.24内核）上返回成功。这表明我的虚拟内存真的用完了，除了 tcsh "limit" 在旧系统和新系统上返回相同的值，并且 /proc/meminfo 显示新系统有更多的内存和更多的交换空间。也许是碎片问题或程序加载的位置？

我做了一些进一步的研究，并在内核 2.6.25 中添加了“brk 随机化”，但CONFIG_COMPAT_BRK据说默认启用（禁用 brk 随机化）。

编辑：

好的，更多信息：看起来 brk 随机化确实是罪魁祸首，旧版 gcc 正在调用 brk() 来更改数据段的结尾，现在失败了，导致旧版 gcc 报告“虚拟内存耗尽”。有一些记录在案的方法可以禁用 brk 随机化：

• sudo echo 0 > /proc/sys/kernel/randomize_va_space

• sudo sysctl -w kernel.randomize_va_space=0

• setarch i386 -R tcsh用（或“-R -L”）开始一个新的shell

我已经尝试过它们，它们似乎确实有效果，因为 brk() 返回值与没有它们时不同（并且始终相同）（在内核 2.6.25 和 2.6.26 上都尝试过），但是 brk()仍然失败，所以旧版 gcc 仍然失败:-(。

此外，我已经设置vm.legacy_va_layout=1并且vm.overcommit_memory=2没有任何更改，并且我已经使用/etc/sysctl.conf 中保存的设置vm.legacy_va_layout=1重新启动。kernel.randomize_va_space=0还是没有变化。

编辑：

在内核 2.6.26（和 2.6.25）上使用kernel.randomize_va_space=0会导致以下 brk() 调用被报告strace legacy-gcc：

brk(0x80556d4) = 0x8056000

这表明 brk() 失败，但看起来它失败了，因为数据段已经超出了请求的范围。使用 objdump，我可以看到数据段应该在 0x805518c 结束，而失败的 brk() 表明数据段当前在 0x8056000 结束：

编辑：

在下面回应 ehemient 的评论：“将 GCC 视为没有源代码的二进制文件真是太奇怪了”！

因此，使用 strace、objdump、gdb 以及我对 386 汇编器和体系结构的有限理解，我将问题追溯到遗留代码中的第一个 malloc 调用。旧版 gcc 调用 malloc，它返回 NULL，这会导致 stderr 上出现“虚拟内存耗尽”消息。这个 malloc 在 libc.so.5 中，它多次调用 getenv 并最终调用 brk()...我想增加堆...失败了。

由此我只能推测问题不仅仅是 brk 随机化，或者我没有完全禁用 brk 随机化，尽管 randomize_va_space=0 和 legacy_va_layout=1 sysctl 设置。

我们有一个使用 libc5 的旧版链接器，由于多种因素，我们只有二进制文件而不是源代码。是的，版本控制可以让我们摆脱当前的问题......现在我们的完整工具链和产品线都在使用它，但是这匹特别的马早已不复存在。

此链接器适用于 linux 内核 2.6.24，但在 2.6.25（和 2.6.26）上失败并显示消息

我们在使用相应的旧版编译器时遇到了类似的问题，但是通过一些 stackoverflow.com的答案和大量研究发现，编译器问题是由 linux 内核 2.6.25 中的“brk 随机化”引起的。解决方法是设置 sysctl vars 和 environment var：

但是，这对链接器没有帮助。

我通过使用“ldd”发现链接器具有更多的共享库依赖项（编译器只有 libc.so.5）：

而且我已经读到我可能必须安装 libg++.so.27 的 libc5 版本。我犹豫是否这样做，因为我不知道这是否会覆盖最新的 libg++.so.27 并导致非 libc5 应用程序出现问题。

那么，我是否找到并安装了 libc5 版本的 libg++.so.27，或者是否有更好的方法来禁用 brk 随机化，或者内核 2.6.24 和 2.6.25 之间是否存在导致链接器问题的另一个区别？

编辑

有关此搜索的所有详细信息以及我的最终解决方案，请参阅此内容。

我正在将 MVC 添加到具有许多旧版 Web 表单页面的项目中。这工作正常。但是，我目前有一个单独的 MVC 和 web 表单的母版页。两个母版页产生基本相同的输出。我真的很想杀死网络表单，只使用 MVC 母版页和我的所有页面并保持干燥。

当我忘记改变两者时，不干燥已经咬了我几次。

我尝试采用明显的方式，并将 Web 表单内容页面的 MasterPage 属性指向 MVC 母版页。这会引发一个错误，指出 MVC 主控仅适用于 MVC 视图。

这似乎是混合 MVC 和 webform 项目的一个非常常见的问题。我的 MVC 大师没有对 ViewData 做任何事情，所以我看不出 webforms 不能使用它们的任何原因。