基本上，我的應用程序內部有一個文本文件（位於應用程序屬性的資源選項卡中）。如何寫入應用程序內部的文本文件
現在我試圖讀取&寫入該文件，閱讀工作很好，這是寫作部分，給我的問題。
我正在使用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