1

Basically, I have a text file inside of my application (in the resources tab of the application's properties).

Now I'm trying to read & write to that file, reading works just fine, it's the writing part that's giving me issues.

I'm using dim str as string = my.resources.textfile, which works.

Now I'm trying to use my.resources.textfile = str2, which gives me an error stating the file is Read only.

How do I work around this?

Note: I don't like writing the file to the user's PC as it's not a lot of data which needs to be written and because it looks a tad unprofessional (in my eyes), so I prefer a way to do this without writing a file to the user's PC.

Yorrick
  • 377
  • 2
  • 8
  • 28
  • 2
    This is not easily possible (it is of course possible, though) and you would still be writing to the users disk and consuming space even if you could easily store files in the executable. It is not unprofessional for an application to store data on the disk. – Jacob Parker Mar 18 '13 at 21:12
  • Good point, but when it's just a tiny little text file containing 1 line of text, it's kind of a waste to write it into a different file. It's basically just 1 line of text containing login credentials that need to be saved. – Yorrick Mar 18 '13 at 21:43
  • You are over thinking the problem. I can tell by the fact that you are using vb.net that you aren't running on a system that is so constrained that writing a single line to a file will be a burden - keep in mind that the solution to writing to your executable is itself going to take up space in the code! – Jacob Parker Mar 18 '13 at 21:47
  • Very true. I must ask though, why is VB.net so underused? You can do pretty much the same things with vb as you can with (most) other languages & it's 100x easier to use/learn. – Yorrick Mar 18 '13 at 22:08
  • I disagree that it is 100x easier to learn but this discussion is not suitable for StackOverflow. – Jacob Parker Mar 18 '13 at 22:10
  • ^ Very true. Anyway, I just updated my question with a new problem created after deciding to go with a file created on the user system now. – Yorrick Mar 18 '13 at 22:14
  • On StackOverflow you should open a new question instead of replacing an old one with edits (this is also much more likely to get you an answer.) Please consider reverting to the previous question text and opening a new question, linking to this one if its relevant. – Jacob Parker Mar 18 '13 at 22:17
  • Click the link on "edited X units of time ago" to see the revision history and get the previous version and edit it into the question. Thanks. – Jacob Parker Mar 18 '13 at 22:32

2 Answers2

3

when it's just a tiny little text file containing 1 line of text, it's kind of a waste to write it into a different file.

Why would that be a "waste"? That's a strange way of looking at it. If it's worth it to write the file in the first place, it's worth it to write it to a separate file.

Like Jacob says in a comment, modifying the executable itself is an utterly non-trivial task. Getting the code working to make that happen would be the real waste. And that assumes you can get code like that past a virus scanner, corporate policy, or basic code review.

I don't like writing the file to the user's PC as it's not a lot of data which needs to be written and because it looks a tad unprofessional (in my eyes), so I prefer a way to do this without writing a file to the user's PC.

You have the right instincts in worrying about this, but the worry in this particular case is misplaced. It would indeed be unprofessional to write files to the user's desktop, or documents folder, or even the root level of the hard disk. These locations either belong exclusively to the user or the system, and even if you could successfully write to them (UAC will fight you all the way on the root level of the disk), you shouldn't. (Blah blah blah, I've ranted about this before.)

Instead, use the Application Data folder that is intended for exactly this purpose. You're guaranteed to have read/write privileges to this location, and no normal user ever looks there so they won't see any of the stuff you toss in. Abnormal users who look there expect to see this kind of stuff stored there.

The only possible mistake that you could make would be to hard-code the path to such a folder. Don't do that—it changes location from one machine to the next. Instead, use the Environment.GetFolderPath method to retrieve its location. That function takes one of the Environment.SpecialFolder values, of which there are an insane number. The three you're interested in for this purpose are:

  • ApplicationData, which is used to store application data that should roam with the user's account (i.e., go with the account when they log on using a different machine)
  • LocalApplicationData, which is used to store application data that should not roam with the user's account (i.e., stay locally only on the current machine)
  • CommonApplicationData, which is used to store application data that is common to all users (i.e., non-user-specific).
Community
  • 1
  • 1
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • You make some good arguments there and I can't say I disagree with you. Although instead of writing the file to %appdata%, I just went with `System.IO.Directory.CreateDirectory(Mid(My.Application.Info.DirectoryPath, 1, 1) & ":\ProgramData\DayZAdminPanel")` & I then create the file there. Although now I seem to be stuck, keep getting an exception saying I can't write to the file because it's already being used by another process... – Yorrick Mar 18 '13 at 22:07
  • @Yorrick You can't just assume that random paths like that exist. There may not *be* a `ProgramData` directory. You're still hard-coding a path, even if you don't hard-code the drive letter. I'm not sure what's wrong with doing it the right way. It doesn't generate any exceptions. – Cody Gray - on strike Mar 18 '13 at 22:39
  • Unless I'm terribly mistaken, isn't ProgramData a default folder nowadays for Windows? And you're right, there's nothing wrong with doing it the right way, I guess I'm just a bit stubborn sometimes, it's one of my many flaws. – Yorrick Mar 18 '13 at 23:07
  • @Yorrick Sure it is--on Windows 7. Microsoft is free to change this at any time, though. Recall that Windows XP did things completely differently and had no ProgramData folder. I don't *think* that they localize the name ProgramData, but they might, you never know. I just don't see the point in making these types of assumptions when there's a simple, documented way of retrieving the correct path. – Cody Gray - on strike Mar 19 '13 at 03:00
0

if its just login credentials why not use My.Settings? Got your project properties and then to the settings tab, add your settings Eg. "username" etc and use that like: My.Settings.username = "Yorrick" My.settings.save

okThen
  • 11
  • 1