Develop Reference

extracting a file without letting the user access it

I was always pretty impressed by those programs that you could install by executing one installer file, which would then extract all the other required files to run the actual program.
And even now im still wondering how you would code a program that extracts files that are literally still inside the program ( so not in some kind of zip) , i've seen tons of installers for games who have this. I need this cause I want to extract a file on the right moment without giving the person who uses the program the ability to delete the file before its extracted, this may seem vague, but I hope i've informed you enough.

I'm just going to say that building an installer is difficult.
I'd recommend using NSIS: http://nsis.sourceforge.net/Main_Page
As for creating a file the user can't access, create a temp file with the correct read/write permissions, extract the data to the temp file, then copy the file where it needs to go.
Extract happens without the user interfering, and copy protection is handled by the OS.

What about changing the build action for the file you want to hide to Embedded Resource, or something like that that compiles the file inside the dll/exe?

Executable program is just file, So you can append any data at you executables. (works for my c++ compiled program)
$ cat executables some_blob_data > new_executables
Since argv[0] of main() is name of your file, you can use this to acess data in this file itself (works for c or c++ and likley for other languages to)

A really simple way to do this is to use your archive tool or one of the dozens of already made installers. WinRar, WinZip and most others allow the creation of self extracting exe files. I know you've said that is not what you want but if you make sure to make it auto exec your installer app and remove all of the temporary files when you're done it really can be very fool proof and professional looking. Obviously, the various installer applications are able to do what you're wanting.
If you really want to do this yourself the easy solution is going to most likely be dependant on your IDE software and language. The generic answer is that you'll need a compression library which can accept a stream as input. Then you'll want to make your actual files into resources inside your installer app. At that point it's just a matter of telling the compression library to read from a stream which is pointed at the resource. How that is done varies greatly from language to language.

Create a Directory using Directory.CreateDirectory( ) that gives a warning message when trying to delete or rename

My application creates several text files that contain important data for its working. I am grouping up all these files in a folder. In Form_load() I gave Directory.CreateDirectory("C:\\xyz"), so that a folder is created in a drive which will later include text files, when the application will be delivered to clients. I want to see that the user does not delete or rename the folder. A dialog box that shows some warning message will be helpful. Is it possible with Directory.CreateDirectory()?

I think you should just warn the user about the importance of this directory. However, you can recreate the directory by performing this kind of check :
if(!Directory.Exists(path))
Directory.CreateDirectory(path);
From this point, you can imagine a mecanism that save the important files in a temporary way, and if the directory is deleted, you recreate it and put the previously saved files in it.

First of all, you might find reading this helpful.
Second: If I understand your needs correctly, what you want is much more painful than you think.
You should really consider doing what Damien_The_Unbeliever told you.
However, if you insist: You will need to use C++ (C# will give you and your users a lot of pain) for it, and you will need to "hook" SHFileOperation through something like ICopyHook. Start by taking a look at ICopyHook. It will be a lot of work and a lot of learning, and I don't think it's worth it, but there's the info. Good luck.

c# save directory between sessions

Not really done this before so I wanted a few pointers.
In my app, users are able to pick a folder that the application looks in when it is started to pick up some input files.
What is the best way to save this information between sessions.
the old fashion way I would have done in the past would be to have a config.ini file and read and write to that the path. However I am sure there are better ways now.
I don't want to have to write to the registary as I want a app that can be installed and uninstalled simple by copying a folder or deleating the folder.
Is there any way to save configuration settings that the uesr can update and remian constant between sessions?
Cheers
Aaron

AFAIK, the way is done now, is by writing these values to the Application.Settings file; however, that's not too different than writing to any XML file and reading it on startup. Either alternative is almost equally simple.

As Icarus said, you need a .settings file. You can specify that settings be Scoped to the User.

You can also look into using IsolatedStorage ( http://msdn.microsoft.com/en-us/library/x7dzh4ws.aspx ).

how to save user registration in the exe... (C#)

Is this even possible?
I realize that asking them to enter data when the program runs and saving it in the executable file itself is out. (Or is it?)
Right now I'm considering trying to build the program server-side with php and have it incorporate a separate text file which would contain the information. This seems marginally feasible, though I would have quite a bit of learning to accomplish it.
I was hoping for some other ideas of how I might accomplish this.
I am not interested in separate configuration or text files or putting data in windows registry. I am only looking for solutions where it can be quite-solidly a part of the executable.
Does anybody have any experience with this?
Thank you.

Its perfectly possible, that's how self-extracting zip files work.
Basically, you can add as much stuff to the end of the executable file as you want. Your program can then open its own file up on disk and read it back.

How about using Settings within your app? It depends on what you mean by "storing the user registration" as to how you would best achieve this, though. If you could give some more information about what you actually want to store, that would be useful.
An example would be to save a username, or an authentication token, and use that each time you need to check a "registration". As I say, though, the details of what to store would depend entirely on what you want to do it that data...

You could use it to embed in the unmanaged resources.

how to store settings for deployable c# application?

I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.

Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.

I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.

The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].

If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.

The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).