We Keep Coding

represent Memory Stream as a physical file

I've ran into a bit of a stupid problem today:
In my project I have to use a library (that I can't replace), he problem is that I'm using MemoryStream instead of frequently saving to the HDD (because there are many files, and they are small in size, so it's perfect for MemoryStream). The problem is that the library API is built around filesystem access - and one of the functions accepts only direct path to file.
How can I still send a string (path) to the method, which makes a new FileStream without actually touch the hard-drive?
For example "\MEMORY\myfile.bin"?

Well - that's thought.
Basically, you have three possible solutions:
You can use a reflector to modify the library given.
You can inspect the appropriate method, and then, by using some reflection magic you might be able to modify the object at runtime (very un-recommended)
You can play around with system calls and API - and by going into low-level ring0 assembly modify kernal.dll to referrer I/O queries from your path to the memory. (maybe that's possible without ring0 access - I am not sure).
Obviously, the most recommended is to use a reflector to modify the library given. otherwise, I can't see a solution for you.
In respond to the first comment, you can:
use RAMDrive (a program which allocates small chunks of the system memory and show it as partition)

If the file must exist on the disk (and only disk paths are accepted), then the main option is a virtual filesystem which lets you expose custom data as a filesystem. There exist several options, such as now-dead Dokan, our Solid File System OS Edition and Callback File System (see description of our Virtual Storage product line) and maybe Pismo File Mount would work (never looked at it closely).

It all depends on how the library is constructed.
If it's a 100% managed library that uses a FileStream, you are probably stuck.
If it takes the provided filename and call a native WIN32 CreateFile function, it's possible to give it something else than a file such as a named pipe.
To test quickly if it's possible, pass #"\\.\pipe\random_name" to the method: if it responds by saying explicitely that it can't open pipes and filenames begining with \\.\, well, sorry. ON the other hand, if it says it can't find the file, you have a chance to make it work.
You can then create a NamedPipeServerStream and use the same name for your library method call prepended with \\.\pipe\.

You can't "represent" it as a file, but you could "convert" it to a file using a StreamWriter class.

Constant Data between executions

I have a C# app that uses a DLL I made and I have to store 3 variables inside the DLL that have to be constant so I can get them later even after the user closes the program (I need to get them every execution after I write the data to the DLL). I want to store them inside the DLL because I don't want to use the registry or use any external files so I was thinking of using a Resource file within the DLL to read/write my static data to.
Can anyone give me an example of how to use the resource data like this or suggest another way to do this without declaring hardcoded variables (which I cannot do), or using the registry/external data files to store the information.

I would suggest using Isolated storage to write your data. You can have a quick start here.

Use a regular memory mapped file. Writing to binary executables is bad practice and many (if not all) OS-es will prohibit that in all but the most promiscuous security policy settings.
PS. The popular term for this kind of storage is 'database' (or program database). This should help you get a few google hits.
Also, depending on your preferred method of implementation you can use memory-mapping to overlay your data-segment (so you can have your cake and eat it: keep you global static data where it is and easily commit them to disk). However, this is more in the C/C++ spirit.
In .NET you'd have to use a giant custom-layout struct (meaning, all reference types are out of the question - this is more unnatural in C# than it is in, say, C++)
So your best bet is probably to use an UnmanagedMemoryStream, serialize your data using builtin .NET System.Runtime.Serialization (of which the XML flavour is by far the more popular and easily copied from blogs and other sources).
Cheers

What library to use for CSV import in c#

I've looked at FileHelpers v2.0 but there is a serious problem woth that. I cannot define a class that maps to the record in the source/detination file.
The reason is I don't know what file I'm going to get. A big part of my program is mapping the file's fields to the database's fields... I don't know how many fields there wil be, nor wich will need to be imported.
I have no intention on rolling my own lib, especially since I have no control over the files that are going to be fed to my program.
Any solutions tot his?
Dennis

Check out the Fast CSV reader on the CodeProject. It helped me with my project a while ago. Its really easy to use, and is quite good.

You can use ADO.NET to directly read the .CSV file into a DataTable. If you don't know how many fields will exist in advance, this can be a useful means of working with the data. This also has the advantage of not requiring any external libraries.
For details, please see Deborah Kurata's article on the subject.

StreamReader has been fast enough for me for pretty much every text file, though you are pretty screwed if you cant even guarantee value ordering.

How do I store a rating in a song?

I want to be able to store information about a song that has been opened using my application. I would like for the user to be able to give the song a rating and this rating be loaded every time the users opens that file using my application.
I also need to know whether I should store the ratings in a database or an xml file.

C# ID3 Library is a .Net class library for editing id3 tags (v1-2.4). I would store the ratings directly into the comments section of the mp3 since id3v1 does not have many of the storage features that id3v2 does. If you want to store additional information for each mp3, what about placing a unique identifier on the mp3 and then having that do a database lookup?
I would be cautious about adding custom tags to mp3s as it is an easy way to ruin a large library. Also, I have gone down this road before and while I enjoyed the programming knowledge that came out of it, trying something like the iTunes SDK or Last FM might be a better route.

I would use a single-file, zero-config database. SQL Server Compact in your case.
I don't think XML is a good idea. XML shines in data interchange and storing very small amounts of information. In this case a user may rate thousands of tracks ( I have personally in online radios that allow ratings), and you may have lots of other information to store about the track.
Export and import using XML export procedures if you have to. Don't use it as your main datastore.

I would store it in a file as it is easier to keep with the mp3 file itself. If all you're doing is storing ratings, would you consider setting the ID3 rating field instead?

For this type of very simple storage I don't think it really matters all that much. The pro's of XML is its very easy to deploy and its editable outside of your app. the con's are, its editible outside your application (could be good, could be bad, depends on your situation)
Maybe another option (just because you can ;-) is an OODBMS, check out DB4Objects, its seriously addictive and very, very cool.

As mentioned earlier it is better to store such information in media file itself. And my suggestion is to use TagLib# lib for this (best media metadata lib I can find). Very powerful and easy to use.

I would store the ratings in a XML file, that way it's easy to edit from the outside, easy to read in .NET and you don't have to worry about shipping a database for something simple with you application.
Something like this might work for you:
<Songs>
<Song Title="{SongTitle}">
<Path>{Song path}</Path>
<Rating>3</Rating>
</Song>
</Songs>

If the song format supports suitable meta data (eg. MP3), then follow Kevin's advice of using the meta data. This is by far the best way of doing it, and it is what the meta data is intended for.
If not, then it really depends on your application. If you want to share the rating information - especially over a web service, then I would go for XML: it would be trivial to supply your XML listings as one big feed, for example.
XML (or most other text formats) also have the advantage that they can be easily edited by a human in a text editor.
The database would have its advantages if you had a more closed system, you wanted speed and fast indexing, and/or have other tables you might want to store as well (eg. data about albums and bands).

Fast way to search for particular string (or byte array) in another process memory in C#?

Please post a working source code example (or link) of how to search string in another process memory and getting offset of match if found. The similar way its done in game cheating utils which search for values in game memory using ReadProcessMemory.

String searching algorithm on Wikipedia.

You may want to look into Memory Mapped Files as a way to share memory between separate processes. You'll need to use Win32 P/Invokes to implement this in C#, see this Code Project link for an example that you may be able to adapt.