Develop Reference

Protect the SQLite format 3 to my application only

Database File and Application that reads the db. The application has a registration component added. If the user doesn't want to register they can simply download the open source application, copy the database to the new folder, run a batch file and the database opens in the application, completely eliminating the registration and whatever extra features were added.
I want to keep the database file inhouse, even if it means adding the db file into the resources of the main application. The file does require data to be written to that file.
I've gone as far as converting the batch file to an exe file and loading the database file or even renaming the database file to something obscure like abc.exe (Even though its a db file it can be renamed to anything)
Database file is renamed to an exe file for the time being, I would prefer to either have it encrypted somehow or somehow placed into the resources of my main application and accessed that way, I am just trying to limit the way the software can be pirated.

Encryption:
You can encrypt SQLite databases using extensions such as SQLite Encryption Extension. The usefulness of such encryption depends on what you are trying to do. If your application can read the keys to decrypt it, so can a hacker that can run your application. You can use Windows Data Protection API to manage the keys so that if someone copied the database from one windows machine to another, the database would be unreadable; but again, if the hacker can access the source machine, they can obtain the keys just like your application (but it would protect against a "dumb" user from just copying the files over).
Putting it in your "main application resources": If you mean embedding the database within the EXE, you are out of luck if you have a requirement to write the data. Generally speaking, an EXE cannot modify itself (though depending on OS/version/user permission/absense of antimalware agents, etc, you might theoretically accomplish a self-modifying EXE; but, if you want your app to work most of the time in the wild, this strategy won't succeed). Even if you did succeed in an EXE that read itself, loaded the embedded blob as a database, modified that database in memory, then rewrote the entire EXE with database exported as a new blob (of different size than the original, wreaking havoc on the assembly), it wouldn't help. The attacker can do what your app does and access the data. Do yourself a favor and follow the operating system's guidelines for writing user data. For Windows, this is generally reading and writing files to your Local App Data folder.
Renaming a SQLite database to have an EXE extension. What are you trying to accomplish? Obscurity? Renaming it to EXE might fool some users (certainly not the motivated user I've described above), but it also might accidentally fool anti-malware / anti-virus software running on your legitimate user's operating systems into thinking your application is writing malformed executables (which would be suspicious) and shut your application down, or at least prevent it from working correctly. This will cause your users to not use your application or a mountain of support for you. What does it gain? It stops a "dumb" user from trying to open it in a SQLite query tool?
All that said, if you want to limit your user's abilities to read the data stored on their own storage devices, you really can't stop a determined user. You can stop the less savvy users. The majority of users cannot run a reflector on a C# assembly and figure out what it is doing, but many can. If you want to stop the less savvy users, encryption of the data will stop most of them, and it will be the least likely approach you've discussed to prevent your application from working "in the wild".

How can I create a drive in Windows backed by a custom storage?

I have a use-case where I need to make a block of storage (think any cloud based storage provider or a Database) available as a Windows drive.
I am happy to do the coding but haven't got a clue where to start.

you have to work with Windows Drivers SDK, there are some samples online about this, something "similar" but not 100% saem as what you need is teh RAM drive implementation whcih creates a new drive which uses RAM memory as storage,
have a look here for some source code you can compile in Visual Studio and to see how you have to setup/prepare your machine for Windows drivers development.
https://github.com/Microsoft/Windows-driver-samples/tree/master/storage/ramdisk

See this question:
creating virtual hard Drive
You would need to create a folder location, probably somewhere in the user's folder tree and map the drive as in the answer in the above link. Then use that folder to sync files with your cloud storage. I doubt you'd want to have the files in memory as you may end up with a drive containing gigabytes of data.

Prevent EXE being copied to another PC - keep some info inside EXE file (e.g. some flag)

I want to prevent executable being copied to another PC and thus i need to somehow save information inside my EXE file about that it was already used somewhere else on another PC.
Can i embed small piece of information like user's hard drive number into my EXE file so this information would be available when this EXE is copied to another PC?
I thought maybe there is a way to read and write to some resource file embedded in an EXE file but i presume that resource file is read only and if so is there is a place inside EXE file where i could keep information which i need?

You're fighting an uphill battle this way. It's possible to create a home-grown licensing scheme but be prepared to do a lot of work (I did it, so I speak from first-hand experience). Just some problems to solve:
If the hard drive fails and needs to be replaced, your user won't be able to use the program. Every time this happens, you'll get a support call with an angry user.
If the user runs your program inside a virtual machine, the hard drive serial number won't be unique - anyone can clone the virtual machine and now your program can be run on another machine.
Hard drive serial numbers can be changed - they don't come directly from the hardware.
What if the hard drive is a removable drive? Your user can run your program from a removable drive and then keep moving it to different machines.
Even if you get it done, how do you protect the license information from being modified?
If you really want to license your product, look at existing licensing products - they're not cheap but they already did the (considerable amount of) work that's necessary to have any kind of reliability.
Even if you only want to have minimal protection, consider this: you'll have to do a lot of work to get even minimal security of your secret token (whatever that is). If its security is minimal, then what's the point of you even doing all that work? If all you do is force people to put in a meaningless serial number, you'll just annoy your honest customers. If anyone wants to steal something that's not well protected, they will steal it. All a 'simple' protection scheme does is annoys your users and gives you a false sense of protection.
I ended up using Reprise RLM - I'm not associated with this company but I had a good experience with their sales and support people and their product worked well in the testing scenarios.

Ok, I analyzed all the variants that were proposed and decided that in my case it will be better to develop my own copy-protection system, due to the reason that I am an indie developer and not going to work with extra large applications.
Just in case, somebody faces to the same issue - here is the algorithm (well, one of them):
User starts APP1.EXE
APP1.EXE reads itself to some variable and adds HDD serial number to the end of it, e.g. HDD serial number - when you add something to the end it does not break EXE file and you do not have to worry about PE headers
Unfortunately, EXE cannot save itself in runtime so it saves its copy called APP2.EXE with the information about HDD
When APP2.EXE is saved APP1.EXE starts it as a separate process via Process.Start() and terminates itself
Now APP2.EXE is running and has the same content as APP1.EXE + HDD serial number so we simply write all bytes from APP2.EXE back to APP1.EXE, close current process and start APP1.EXE again
From now on APP1.EXE is running and have all needed information about current HDD so each time user starts APP1.EXE it compares HDD number at the end of its content with the actual one on user's PC, if they differ - terminate the process
Delete APP2.EXE so that user would not realize how these files exchange information about his HDD.
Useful info about self-deleting EXE can be found here :
http://www.catch22.net/tuts/self-deleting-executables
http://buffernow.com/selfdelete-executable-in-c/
P. S. I know that it is like a huge hole of security (I will not mention all of them) but implementation of this algorithm took just 20 lines of code in C# and was moved to a separate DLL which I can use everywhere and it works. There is NO any registration in the algorithm above and user can simply take this app and use it and I am sure that ~ 80% of them will not realize how this app is protected from copying.
Link to implementation : https://bitbucket.org/artemiusgreat/examples/src/ef7b60142277?at=master

Virtual Drive Mapped to Program

Would it be possible to create a program (.NET preferably) to create a virtual drive letter, but when it is read, written to, or browsed an independent program deals with what is returned?
Although you could do it by mapping a drive to a TCP server, webDAV or something like that, I'm wondering if it could be done with internal links.
This would be used for protected storage. The program does stream encryption and decryption of all the files in the drive (as they're read by all kinds of programs) if the program has had a password put into it.

What you're talking about is a storage device driver, which is how programs such as Daemon Tools and TrueCrypt accomplish such "virtual" drives.
You may not have to delve into the kernel to accomplish this, though. Microsoft supply a Windows User-Mode Driver Framework, which is designed to simplify the development of certain common Windows driver types. From what I can tell, you should be able to develop a virtual storage driver using the user-mode driver framework. As long as you're not directly interacting with hardware (like a kernel-mode device driver does), you should be fine. However, you won't be able to do this in C#. You'd probably have to use C, though you might get away with C++.

PowerShell already supports something like this with its Provider model. Certificate store, Active Directory, IIS configuration, SharePoint, ... are all made to look file system like, using the same commands to query and update.
This is at the heart of PowerShell. $foo is the value of variable foo, ${c:\foo.txt} is the content of file C:\foo.txt but used just like a variable. Equally dir HKLM:\Software lists the child keys of that registry key.
You can write you own providers.

There is an open source program, WinCDEmu that can mount an ISO image to a virtual drive. I suppose you'll be able to examine the sources to figure out how to provide a virtual drive that does what you want. The project is written in C++.
It is based on BazisLib, which is a framework for simplifying windows driver development.

Can I write an Extension for External Harddisk

I want to secure my external hard disk by writing sort of ShellExtension. But Shell extension is Workstation Specific.
Is there a way I can write an application that will show a authentication or an extension encrypt my drive data so user will get a failure message when double click on my drive.

You can't secure an external harddrive by the use of a shell extension, period.
If you want to keep your data safe, there's only one thing you can do: encrypt it. NTFS has built-in encryption, but I wouldn't recommend using that for an external drive, because of the way the encryption keys are handled.
There's a nice pre-cooked solution for you, though: TrueCrypt. It works, is available for multiple operating systems, has decent speed, and good security. Use it.

1) You should not write a shellextension in .net
This causes lots of trouble since then the .net runtime is injected into every application displaying a shell window (like the file open dialog) and if it already uses a different version of the runtime it will likely break.
2) I don't really understand what you are trying to do. But I encrypt my external harddisk with TrueCrypt. That's secure and easy to use.

This is only possible if you change the drive. Otherwise just using on a system without your software would bypass it.
Using NTFS with permissions for the drive's file system would be bypassed by anyone with applicable Window's privileges.
Using an encryption tool may be best: a single public file which contains a complete drive only accessible with the right software and authentication—there are a number around.