Sounds like you want the BinaryFormatter. This saves to a non-readable binary file. One of the major benefits of it over XmlSerialization (for example) is that your properties don't need to be public.
However I would personally like to dissuade you from this idea. I've been down this road myself and while its easy in the short term, in the long run there is a lot of pain on the way.
You will have massive issues with versioning. Whenever you want to update any object (say, add a new property) you'd have to convert all of the files.
Even worse if you want to do this within the same application you'll need both definitions available at the same time. This leads to absurdist class definitions such as:
// my original object
class SavedObject
{
public string Data{get;set}
}
// needed to add a field for last edit
class SavedObject2
{
public DateTime LastEdit{get;set;}
public SavedObject2(SavedObject so){}
}
// need a small restructure so we can now have multiple datas
// 'data' is now obsolete
class SavedObject3
{
public List<string> DataList{get;set;}
public SavedObject3(SavedObject2 so){}
}
Serialising as a means of persistence is only good in two scenarios. One where you know the data will never change in definition (incredibly rare) and: Two where you are just saving the data in a primitive fashion (for example just a collection of strings that code then converts into classes).
I would seriously consider using a database. If you're disliking the administrative chores that come with most production databases then consider using Sqlite, it's small, portable and very easy to embed within an application.