7

关于拥有 USB 闪存设备,我最喜欢的事情之一就是随身携带一堆有用的工具。我想写一些工具,让它们在这种环境下运行良好。我最了解 C#,而且我的工作效率很高,所以我可以用这种方式立即启动一个 Windows 窗体应用程序。

但是在制作便携式应用程序时我应该考虑哪些因素?我能想到的一些,但不知道答案:

1) 语言可移植性 - 好的,我知道我使用它的任何机器都需要安装 .NET 运行时。但是由于我只经常使用一些 Windows 机器,所以这应该不是问题。我可以使用另一种语言对其进行编码,但随后我会失去生产力,尤其是在简单的表单设计器方面。从闪存驱动器运行 .NET 应用程序是否还有其他问题?

2) 读/写周期 - 在 C# 中,我如何确保我的应用程序没有不必要地写入驱动器?我是否总是可以控制写入,或者是否有任何“隐藏的写入”需要考虑?

3)悬而未决的问题:是否还有其他与可移植应用程序相关的问题我应该注意,或者可能对具有良好 IDE 的其他语言的建议可以让我获得类似水平的生产力但更好的可移植性?

4

5 回答 5

11
  • 1) 从闪存驱动器运行 .NET 应用程序应该没有任何问题。
  • 2)您应该可以控制大多数写入。确保写入临时或硬盘驱动器上的其他位置,而不是闪存驱动器。但是写入周期应该不是问题——即使是中度到重度使用,大多数闪存驱动器的使用寿命也长达数年。
  • 3) 就像任何具有 xcopy 样式部署的应用程序一样对待它,如果某些依赖项不在盒子上,请尝试考虑您的应用程序优雅地失败。
于 2009-04-22T16:41:45.347 回答
2

如果您想使用 com 对象,请使用 reg-free com 并将 com 对象包含在您的程序中。

于 2009-04-22T16:53:31.123 回答
2

您应该始终控制您的写入。应用程序应在启动时加载到 RAM 中,然后在 RAM 中分配内存,因此不会将任何内容写入闪存驱动器。

对于可移植应用程序而言,最重要的是您的应用程序基本上不需要安装。您尤其不想依赖注册表值,因为您的应用程序不会“安装”在其他计算机上。

您可能会考虑的可移植应用程序的问题之一是数据持久性。通常,您写入用户的应用程序数据文件夹以保存数据。如果是这种情况,则保存的任何数据将仅适用于该计算机上的用户。如果您想要一些本地应用程序数据,您可能希望为您的设置创建一个 Seralized XML 文件并将其本地存储在您的应用程序目录中。然后,此文件写入可能是您需要担心的唯一写入操作。

对于您的 .NET 可移植性问题,您还可以用 C++ 编写一个小型入口程序,用于检查计算机是否安装了 .NET。.NET 具有注册表值,您可以检查以查看安装的版本,因此如果安装了 .NET,请运行您的应用程序,否则会显示一条消息,说明需要首先安装 .NET。

编辑:我想补充一点,我在 C# 3.0 中使用 XAML 为超声波机器进行应用程序开发。我编写的应用程序可以通过 USB 闪存驱动器完美运行,而所有用户设置都存储在本地 AppData 基础上,因此没有任何内容写入 USB。虽然可以通过 .exe 安装程序安装应用程序,但安装程序不会写入应用程序所依赖的任何注册表值。

于 2009-04-22T17:15:09.853 回答
0

我实际上没有这方面的任何经验,所以最好用一点盐来接受我所说的。但这是我的看法:

你不需要做任何特别的事情。

应用程序开发人员并没有真正考虑如何以及何时对驱动器进行写入,这是由操作系统更好地控制的事情。我知道 Windows 会缓存对 USB 驱动器的写入,所以我相信它会处理这个问题。

您唯一需要考虑的是不会安装您的应用程序。因此,您需要确保将其设计为在其部署到的目录中完全独立运行。您还可以选择对用户主目录进行一些写入,但这需要通过适当的环境变量来完成。

我会开始写作,看看操作系统无法处理的闪存驱动器是否有什么特别之处。

于 2009-04-22T16:40:35.270 回答
0

对于#1 或#3,我真的没有答案。但对于#2,.NET CLR 不应写入应用程序的“安装”文件夹(即闪存驱动器),除非您的代码明确告诉它或正在使用和修改基于文件的设置(ini、xml 等)与应用程序一起生活。

如果您不只是为个人使用而写东西,那么第 1 号确实是最重要的。显然,在 U 盘上托管完整 CLR 的便携式副本是不可能的。但是有一些工具可以扫描程序集的依赖项并将它们打包成一个独立的 .exe,这样 CLR 就不必安装在目标系统上。

于 2009-04-22T16:41:25.020 回答