基本上，我的应用程序中有一个文本文件（在应用程序属性的资源选项卡中）。
现在我正在尝试读写该文件，阅读效果很好，这是给我带来问题的写作部分。
我正在使用dim str as string = my.resources.textfile，它有效。
现在我正在尝试使用my.resources.textfile = str2，这给了我一个错误，说明文件是只读的。
我该如何解决这个问题？
注意：我不喜欢将文件写入用户的 PC，因为需要写入的数据并不多，而且它看起来有点不专业（在我看来），所以我更喜欢一种不写的方法文件到用户的 PC。
当它只是一个包含 1 行文本的小文本文件时，将其写入另一个文件是一种浪费。
为什么会是“浪费”？这是一种奇怪的看待它的方式。如果首先写入文件是值得的，那么将其写入单独的文件也是值得的。
正如 Jacob 在评论中所说，修改可执行文件本身是一项非常重要的任务。让代码工作来实现这一点将是真正的浪费。这假设您可以通过病毒扫描程序、公司政策或基本代码审查获得类似的代码。
我不喜欢将文件写入用户的 PC，因为它不需要写入很多数据，而且因为它看起来有点不专业（在我看来），所以我更喜欢一种不写文件的方法用户的电脑。
你有正确的直觉来担心这一点，但在这种特殊情况下的担心是错误的。将文件写入用户的桌面，或者文档文件夹，甚至是硬盘的根目录，确实是不专业的。这些位置要么完全属于用户，要么属于系统，即使你可以成功地写入它们（UAC 会一直在磁盘的根级别上与你抗衡），你也不应该这样做。（等等等等，我以前对此大不了不安。）
相反，请使用专门用于此目的的 Application Data 文件夹。保证您对该位置具有读/写权限，并且没有普通用户会查看那里，因此他们不会看到您扔进去的任何东西。查看那里的异常用户希望看到存储在那里的这种东西。
您唯一可能犯的错误是硬编码此类文件夹的路径。不要那样做——它会将位置从一台机器更改到另一台机器。相反，使用该Environment.GetFolderPath方法检索其位置。该函数采用其中一个Environment.SpecialFolder值，其中有一个疯狂的数字。您对此感兴趣的三个是：
ApplicationData，用于存储应与用户帐户一起漫游的应用程序数据（即，当他们使用不同的机器登录时使用该帐户）LocalApplicationData，用于存储不应随用户帐户漫游的应用程序数据（即，仅在当前机器上保持本地）CommonApplicationData，用于存储所有用户通用的应用程序数据（即非用户特定的）。如果它只是登录凭据，为什么不使用 My.Settings？获取您的项目属性，然后到设置选项卡，添加您的设置，例如。“用户名”等并像这样使用： My.Settings.username = “Yorrick” My.settings.save