如何写入应用程序内部的文本文件答案

【问题标题】：How to write to a text file inside of the application如何写入应用程序内部的文本文件
【发布时间】：2013-03-07 09:22:18
【问题描述】：

基本上，我的应用程序中有一个文本文件（在应用程序属性的资源选项卡中）。

现在我正在尝试读取和写入该文件，读取工作正常，这是给我带来问题的写入部分。

我正在使用dim str as string = my.resources.textfile，它有效。

现在我正在尝试使用my.resources.textfile = str2，这给了我一个错误，指出该文件是只读的。

我该如何解决这个问题？

注意：我不喜欢将文件写入用户的 PC，因为需要写入的数据并不多，而且看起来有点不专业（在我看来），所以我更喜欢这样做的方法无需将文件写入用户的 PC。

【问题讨论】：

这并不容易（当然有可能），即使您可以轻松地将文件存储在可执行文件中，您仍然会写入用户磁盘并占用空间。应用程序将数据存储在磁盘上并非不专业。
好点，但是当它只是一个包含 1 行文本的小文本文件时，将其写入另一个文件是一种浪费。它基本上只是包含需要保存的登录凭据的 1 行文本。
你想太多了。我可以通过您正在使用 vb.net 的事实告诉您，您并没有在一个受限制的系统上运行，以至于将单行写入文件将是一种负担 - 请记住，写入可执行文件的解决方案本身会占用代码空间！
非常正确。但我必须问，为什么 VB.net 没有得到充分利用？您可以使用 vb 做与（大多数）其他语言几乎相同的事情，而且使用/学习起来要容易 100 倍。
我不同意它比它更容易学习 100 倍，但这个讨论不适合 StackOverflow。

标签： vb.net resources text-files overwrite

【解决方案1】：

如果它只是登录凭据，为什么不使用 My.Settings？获取您的项目属性，然后到设置选项卡，添加您的设置，例如。 “用户名”等并像这样使用：My.Settings.username =“Yorrick” 我的.settings.save

【讨论】：

【解决方案2】：

当它只是一个包含 1 行文本的小文本文件时，将其写入另一个文件是一种浪费。

为什么会是“浪费”？这是一种奇怪的看待它的方式。如果一开始就写入文件是值得的，那么将其写入单独的文件也是值得的。

就像 Jacob 在评论中所说，修改可执行文件本身是一项非常重要的任务。让代码工作来实现这一点将是真正的浪费。并且假设您可以通过病毒扫描程序、公司政策或基本代码审查获得类似的代码。

我不喜欢将文件写入用户的 PC，因为需要写入的数据并不多，而且它看起来有点不专业（在我看来），所以我更喜欢不写入的方式一个文件到用户的 PC。

你有正确的直觉来担心这个问题，但在这种特殊情况下的担心是错误的。将文件写入用户的桌面，或者文档文件夹，甚至是硬盘的根目录，确实是不专业的。这些位置要么完全属于用户，要么属于系统，即使你可以成功地写入它们（UAC 会一直在磁盘的根级别上与你抗衡），你也不应该这样做。 ^{_{(Blah blah blah, I've ranted about this before.)}}

相反，请使用专门用于此目的的应用程序数据文件夹。保证您对该位置具有读/写权限，并且没有普通用户会查看那里，因此他们不会看到您扔进去的任何东西。查看那里的异常用户期望看到这种东西存放在那里。

您唯一可能犯的错误是硬编码此类文件夹的路径。不要那样做——它会将位置从一台机器更改到另一台机器。相反，使用Environment.GetFolderPath 方法检索其位置。该函数采用Environment.SpecialFolder 值之一，其中有一个疯狂的数字。您对此感兴趣的三个是：

ApplicationData，用于存储应漫游用户帐户的应用程序数据（即，当他们使用不同的机器登录时使用该帐户）
LocalApplicationData，用于存储不应随用户帐户漫游的应用程序数据（即，仅在当前机器上保持本地）
CommonApplicationData，用于存储所有用户通用的应用程序数据（即非用户特定的）。

【讨论】：

你在那里提出了一些很好的论点，我不能说我不同意你。虽然我没有将文件写入 %appdata%，而是使用 System.IO.Directory.CreateDirectory(Mid(My.Application.Info.DirectoryPath, 1, 1) & ":\ProgramData\DayZAdminPanel") 并在那里创建文件。虽然现在我似乎被卡住了，但不断收到异常说我无法写入文件，因为它已经被另一个进程使用...
@Yorrick 您不能仅仅假设存在这样的随机路径。可能没有ProgramData 目录。即使您没有对驱动器号进行硬编码，您仍在对路径进行硬编码。我不确定以正确的方式做这件事有什么问题。它不会产生任何异常。
除非我大错特错，ProgramData 现在不是 Windows 的默认文件夹吗？你是对的，用正确的方式做事并没有错，我想我有时只是有点固执，这是我的许多缺点之一。
@Yorrick 当然是——在 Windows 7 上。不过，Microsoft 可以随时更改此设置。回想一下，Windows XP 的做法完全不同，并且没有 ProgramData 文件夹。我不认为他们将名称 ProgramData 本地化，但他们可能会，你永远不知道。当有一种简单的、记录在案的方法可以检索正确的路径时，我只是不明白做出这些类型的假设有什么意义。