基本上，我的应用程序内部有一个文本文件（位于应用程序属性的资源选项卡中）。如何写入应用程序内部的文本文件
现在我试图读取&写入该文件，阅读工作很好，这是写作部分，给我的问题。
我正在使用dim str as string = my.resources.textfile，它工作。
现在我试图使用my.resources.textfile = str2，它给了我一个错误，指出文件是只读的。
我该如何解决这个问题？
注意：我不喜欢将文件写入用户的个人电脑，因为它不是很多需要写入的数据，因为它看起来有点不专业（在我眼里），所以我更喜欢一种方式来做这不需要将文件写入用户的PC。
当它只是一个包含1行文本的小文本文件时，将它写入不同的文件是有点浪费的。
为什么这会是一种“浪费”？这是一种奇怪的看待它的方式。如果首先写这个文件是值得的，那么将它写入一个单独的文件是值得的。
就像雅各布在评论中所说的那样，修改可执行文件本身是一项完全不重要的任务。让代码工作来实现这一点将是真正的浪费。假设你可以通过病毒扫描程序，企业策略或基本代码审查获得类似的代码。
我不喜欢将文件写入用户的个人电脑，因为它不是很多数据需要写入，因为它看起来有点不专业（在我眼里），所以我更喜欢一种方式来做这不需要将文件写入用户的PC。
你有这种担心的正确本能，但在这种特殊情况下的担心是错位的。将文件写入用户的桌面或文档文件夹，甚至是硬盘的根级别确实是不专业的。这些位置只属于用户或系统，即使您可以成功写入（UAC将在磁盘的根级别上一直与您对抗），您也不应该这样做。 （Blah blah blah, I've ranted about this before.）
相反，使用的目的是出于这样的目的Application Data文件夹。你保证有这个位置的读/写权限，并且没有普通用户曾经在那里看过，所以他们看不到任何你投入的东西。看那里的异常用户期望看到存储这种东西那里。
您可能犯的唯一可能的错误是将路径硬编码到这样的文件夹。不要这样做 - 它会将位置从一台机器更改为另一台机器。而应使用Environment.GetFolderPath方法检索其位置。该函数采用Environment.SpecialFolder值之一，其中有一个疯狂的数字。你感兴趣的用于此目的的三个是：
ApplicationData，用于存储应用程序数据应该漫游与用户的账户（即去的帐户登录时使用不同的机）LocalApplicationData，用于存储应用程序数据应该不漫游用户的账户（即本地只停留在当前机器上）CommonApplicationData，这是用来存储的通用应用程序数据给所有用户（即非用户特定的） 。你在那里提出了一些很好的论点，我不能说我不同意你。虽然不是将文件写入％appdata％，但我只是使用System.IO.Directory.CreateDirectory（Mid（My.Application.Info.DirectoryPath，1，1）＆“：\ ProgramData \ DayZAdminPanel”）＆I然后在那里创建文件。虽然现在我似乎被卡住了，不断地收到一个异常说我不能写入文件，因为它已经被另一个进程使用了...... – Yorrick 2013-03-18 22:07:20
@Yorrick你不能只是假设存在这样的随机路径。有可能不是* ProgramData目录。即使您没有对驱动器盘符进行硬编码，您仍然对某个路径进行硬编码。我不确定以正确的方式做这件事有什么问题。它不会产生任何例外。 – 2013-03-18 22:39:47
除非我非常错误，现在Windows不是ProgramData的默认文件夹吗？你说得对，正确的做法没有错，我想我有时会有点固执，这是我的许多缺陷之一。 – Yorrick 2013-03-18 23:07:46
如果它只是登录凭证，为什么不使用My.Settings？得到你的项目属性，然后到设置选项卡，添加你的设置例如。 “用户名”等，并使用如下：My.Settings.username =“Yorrick” My.settings.save
这是不容易的（虽然这当然是可能的），你仍然会写信给用户磁盘和消耗空间，即使您可以轻松地将文件存储在可执行文件中。应用程序将数据存储在磁盘上并不是不专业。 – 2013-03-18 21:12:54
好点，但是当它只是一个包含1行文本的小文本文件时，将它写入不同的文件是有点浪费的。 基本上只有1行文本包含需要保存的登录凭证。 – Yorrick 2013-03-18 21:43:35
你在想这个问题。我可以告诉你，你正在使用vb.net，你没有运行在一个受限制的系统上，写一行文件将是一个负担 - 请记住写入你的可执行文件的解决方案本身会占用代码中的空间！ – 2013-03-18 21:47:06