I'd not reccommend doing so, better is stick with some nlog or something like this. But if you really really need to, use the MessageBox.Show overload that allows you to specify the:
The message box is displayed on the active desktop.
The caller is a service notifying the user of an event. The function displays a message box on the current active desktop, even if there is no user logged on to the computer.
But generally it is considered a bad practice of displaying messagebox directly from the service. I'd stick with some logging solution.
You are correct regarding the 32 bit/64 bit issue. The keys would be stored in separate points in the registry, however this should not be a problem generaly. The only issue is if you create registry keys as part of your installer (which is always 32 bit) then they will not be available to the appliction running in 64 bit. However if your app just generated the keys if missing then there is no problem.
As the other poster said, use of the registry makes you application non-portable, but that may not be an issue.
The main question should be, do you need secure storage of this information? If the answer is yes, then encrypt it and store it in the registry. If the answer is no then xml is the easier, quicker and more simply manageable route to take.
Personally I hate Windows registry. I would stick with XML. Issues could arise from different machines but if you are accessing the registry locally then it shouldn't be a problem. What I am saying is if you develop a x86 application it will read from the x86 (wow6432node) on a x64 system.
Also I noticed you are trying to keep it away from the user. Just because it is in the registry doesn't mean it is secure. I would stick with XML and just encrypt your values and decrypt them in your application. This way a user cannot read it.
You could also run into permission problems using the registry. I've seen problems where people were running McAfee and it did some weird stuff with not letting values in the registry being edited/removed.
It was repeated on the forum several times. Registry is bad. You don't know if your application's user will be able to access registry. Only administrators can do it (I don't remember how it was on Windows XP, but I'm sure that's true for Vista and 7). Another thing is that when your user wants to check, what you store, he can also check registry. It's not hidden from users. I would recommend (as people answered here) encrypting your XML configuration and store it somewhere in user profile directory. This way checking what you store will be difficult (but not impossible).
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
Btw, you probably know this, but you can't really keep anything from the user. Normal users aren't going to mess around with the registry or even XML files. Users like me will still mess around with encrypted data, and you can't do anything about it, the way to decrypt it will be in the application.
I've recently tried implementing single sign-on using a desktop application and gmail. I failed after numerous attempts. So I've got another question to ask before I go on a wild search on the Internet again. Do you think it would be possible to link a Gmail account with MS Outlook, and then integrate Outlook into a desktop C# application and access the Gmail account like that? Or maybe even using some other provider such as Hotmail? I need to have some sort of single sign on up and running using a desktop application soon and I'm quickly starting to run out of ideas
Somehow the lenght of my file stream is 0.
Anyone could point me out why, please?
StringBuilder sb = new StringBuilder();
char temp = new char;
Boolean munching = true;
if (txtFilePath.Text != "" && txtFilePath.Text != null)
path = txtFilePath.Text;
FileStream fs = new FileStream(@"C:\test.pdf", FileMode.Open);
BinaryReader br = new BinaryReader(fs);
while (munching == true)
br.Read(temp, 0, 10);
c = temp;
// tell the user to wake up
// tell the user to wake up
you have a something (probably a TextBox) that holds a path, yet you do not use its content. Instead you open a fixed file.
If txtFilePath really is a TextBox, no need to test for Text==null as TextBox.Text never holds null, it always holds a real string ("" if no data is present).
your while loop is bizarre.
what makes you think the FileStream has length zero? there is nothing in the code to indicate that.
BTW: as you have been trying to extract text from a PDF file, which isn't necessarily all text, the whole approach is wrong. You should read the entire file as binary bytes, why not use File.ReadAllBytes()?