Binary

You can serialize an object into binary format quite easily using the .NET Framework.  This is the quickest and smallest way to serialize; however, the binary format can only be deserialized using the same .NET Framework.  This may be a problem for interoperability. It must be noted that this format will serialize Public and Private members (unlike XML serialization).

The example below shows how to serialize an object called “newCustomer”:

        Dim newCustomer As Contact = GetSampleContact()

        Using fs As New IO.FileStream(filePathandName & ".bin", IO.FileMode.Create)
            Dim binFormatter As New Runtime.Serialization.Formatters.Binary.BinaryFormatter()
            binFormatter.Serialize(fs, newCustomer)
        End Using

And here is the reverse to deserialize:

        Dim readCustomer As Contact

        Using fs As New IO.FileStream(filePathandName & ".bin", IO.FileMode.Open, IO.FileAccess.Read)
            Dim binFormatter As New Runtime.Serialization.Formatters.Binary.BinaryFormatter()
            readCustomer = CType(binFormatter.Deserialize(fs), Contact)
        End Using

SOAP

SOAP is another method. This is similar to the binary method except the serialized data is stored in a standardized form (SOAP) which will easily allow interoperability. Public and Private members are serialized using this method as well.
To serialize:

        Dim newCustomer As Contact = GetSampleContact()
        Using fs As New IO.FileStream(filePathandName & "SOAP.xml", IO.FileMode.Create)
            Dim soapFormattter As New Runtime.Serialization.Formatters.Soap.SoapFormatter()
            soapFormattter.Serialize(fs, newCustomer)
        End Using

And to deserialize:

        Dim readCustomer As Contact
        Using fs As New IO.FileStream(filePathandName & "SOAP.xml", IO.FileMode.Open, IO.FileAccess.Read)
            Dim soapFormattter As New Runtime.Serialization.Formatters.Soap.SoapFormatter()
            readCustomer = CType(soapFormattter.Deserialize(fs), Contact)
        End Using

XML

A third choice is using the XMLSerializer class. This method will only serialize Public properties and members and the object must be marked with the Serializable attribute and contain an empty constructor. This method of serialization will be smaller in size than the SOAP method since less information is serialized. Here is an example of such class:

     <Serializable()> Class Contact

        Private _FirstName As String
        Public Property FirstName() As String
            Get
                Return _FirstName
            End Get
            Set(ByVal value As String)
                _FirstName = value
            End Set
        End Property

        Private _LastName As String
        Public Property LastName() As String
            Get
                Return _LastName
            End Get
            Set(ByVal value As String)
                _LastName = value
            End Set
        End Property

        Private _MiddleI As String
        Public Property MiddleI() As String
            Get
                Return _MiddleI
            End Get
            Set(ByVal value As String)
                _MiddleI = value
            End Set
        End Property

        Private _PIN As String
        Public WriteOnly Property PIN() As String
            Set(ByVal value As String)
                _PIN = value
            End Set
        End Property

        Sub New()

        End Sub

        Sub New(ByVal fName As String, ByVal middleI As String, ByVal lName As String, ByVal p As String)
            _FirstName = fName
            _MiddleI = middleI
            _LastName = lName
            _PIN = p
        End Sub
    End Class

Here is how you would serialize using the XMLSerializer:

        Dim newCustomer As Contact = GetSampleContact()
        Using fs As New IO.FileStream(filePathandName & ".xml", IO.FileMode.Create)
            Dim xmlFormatter As New Xml.Serialization.XmlSerializer(GetType(Contact))
            xmlFormatter.Serialize(fs, newCustomer)
        End Using

And to deserialize:

        Dim readCustomer As Contact
        Using fs As New IO.FileStream(filePathandName & ".xml", IO.FileMode.Open, IO.FileAccess.Read)
            Dim xmlFormatter As New Xml.Serialization.XmlSerializer(GetType(Contact))
            readCustomer = CType(xmlFormatter.Deserialize(fs), Contact)
        End Using

You can download a sample serialization demo project that I created to demonstrate: SerializationDemoProject.zip.

This is what started it all (at least at my previous employer).  The company I worked for company sells stuff and that stuff has to be installed by a professional installer.  They have a large staff of professional installers.  They have a lot of stuff that needs to be installed.  See where I am getting?  Before I started, this information was stored in a Excel spreadsheet, which did the job until they started growing.  Then it was moved to an Access database, which was much better; however, not everyone knows how to use Access, so a basic web interface to the database was created in FrontPage to update the rows of data.  Each row in the table was a day and each row had a column for every installer.

Problem:

This was functional, however as installers were added and new column had to be added to the Access database.  Also the FrontPage site had to be updated to account for the added column.  The good thing about FrontPage was that it appears simple because it hides a bunch of code behind the scenes, the bad thing is that if something goes wrong (like your computer crashes while updating the site) it becomes a real nightmare to get everything back up and running.

Solution:

The plan was to create a fully database driven installation calendar.  One that could be updated from within the application itself.  Instead of having a list of days and putting a installation on each day, we would have a list of jobs and add installers.  This makes it easier to use since jobs often spanned across multiple days.

Result:

Fig. 1

Fig. 2

Fig. 3

I created a web site that used ASP (Classic ASP, not .NET) and a MSDE database.  The hard part for me on this project was drawing out a calendar dynamically and "putting stuff" on it.  How was that going to look?  How should it look?  Fig. 1 shows the result.  The calendar is shown on the left and jobs that are shown in the current view are shown on the right.  Fig. 2 shows the detail view of a job.  This is where installers could be added to a selected job along with a few other functions.  Fig. 3 shows the print view.  This was helpful when trying to coordinate the jobs.  This was another painful page to write because of the layout.  The only way I could get the data in the format I needed for the page was to do lots of sub-queries.  One for each day and installer, this made the process time for this particular page several seconds!