Problems encountered during binary system serialization -- Understanding ASP. net2.0 page compilation Mechanism

 

 Problem description

There is an industry portal in hand, and each user has a sub-site (or template). Each sub-site has some configuration data (such as logo, horizontal bar image, or other unexpected items) for programming convenience and future expansion convenience, I use it directly in. classes defined in the aspx file are used to save the data. For convenience of modification (the time for compiling a site has reached an unacceptable level), I use a separate class here. aspx file (not associated. CS file), the configuration data will be allocated to the defined class, and then the class will be serialized. If used, the deserialization will be executed (basically similar to the profile process)

 

Below is serializationCode

 

Public static class serializationhelper
{
Public static string serialize (Object Data)
{

Using (memorystream streammemory = new memorystream ())
{
Binaryformatter formatter = new binaryformatter ();

// 2. serialize the DataSet object using the binary formatter
Formatter. serialize (streammemory, data );

// 3. encrypt the binary data
String binarydata = convert. tobase64string (streammemory. getbuffer ());

// 4. Write the data to a file
Return binarydata;
}

}

Public static object deserialize (string serialdata)
{
Object Data = new object ();
Try
{
Memorystream streammemory;
Binaryformatter formatter = new binaryformatter ();

// 2. Read the binary data, and convert it to a string
String cipherdata = serialdata;

// 3. decrypt the binary data
Byte [] binarydata = convert. frombase64string (cipherdata );

// 4. rehydrate the dataset
Streammemory = new memorystream (binarydata );
Data = formatter. deserialize (streammemory );
}
Catch (exception ex)
{
// Data cocould not be deserialized
Data = NULL;
}

Return data;
}
}

 

Binary serialization is used here. The following two files are available: templateconfig. aspx and index. aspx.

 

The code in the templateconfig. aspx file is as follows:

<SCRIPT runat = "server">

 

// Define the configuration data persistence class

[Serializable]
Public class temp_entproperty
{
Private string _ bar;
Private string _ logo;
Private system. Collections. Generic. List <subitem> size;
Public System. Collections. Generic. List <subitem> size
{
Get
{
If (size = NULL)
{
Size = new system. Collections. Generic. List <subitem> ();
}
Return size;
}

}
Public String bar
{
Get {return _ BAR ;}
Set {_ BAR = value ;}
}
Public String logo
{
Get {return _ logo ;}
Set {_ logo = value ;}
}
}

[Serializable]
Public class subitem
{
Public Subitem (string name, int value)
{
_ Name = Name;
_ Value = value;
}
Private string _ name;
Private int _ value;
Public string name
{
Get {return _ name ;}
Set {_ name = value ;}

}
Public int Value
{
Get {return _ value ;}
Set {_ value = value ;}
}
}

Protected void buttion#click (Object sender, eventargs E)
{

Temp_entproperty properties = new temp_entproperty ();

Config. serializedata = serializationhelper. serialize (properties); // Save the serialized data to the database.

// Database operation ....

}
</SCRIPT>

The page tag is omitted .......

 

The index. aspx file code is as follows:

 

The templateconfig. ASPX page needs to be referenced.

<% @ Reference page = "~ /Templateconfig. aspx "%>

<SCRIPT runat = "server">

Protected void page_load (Object sender, eventargs E)
{

ASP. templateconfig_aspx.temp_entproperty properties = serializationhelper. deserialize (serialdata) as ASP. templateconfig_aspx.temp_enterproperty;

// Serialdata is the serialized data in the database.

}

</SCRIPT>

The page tag is omitted .......

 

 

 

This process often works normally (as you know, this is one of the three cases)

First, I run the templateconfig. aspx file first, and then run the index. aspx file to find everything is normal.

 

Second, I modified the templateconfig. aspx file and ran the index. aspx file again, but an error occurred.

Single-step debugging finds that deserialization is normal, but a problem occurs when the deserialized object type instance is converted to temp_entproperty,

One-step debugging clearly shows that the object type instance is temp_entproperty, but conversion is not allowed ....

 

Third: Sometimes there will be deserialization errors, prompting that they cannot be foundProgramThe code line in the templateconfig. aspx and index. aspx files has not changed.

 

Problem Solving

Of course, these three problems were not discovered in the same way. In fact, these problems were discovered one after another during the test period of the site. To avoid these problems, I once set up a custom class (such as temp_entproperty) change to hashtable, because hashtable will not have the above problems, until today I will go back and look for the reasons carefully.

 

According to the error information, it can be roughly determined that it is an assembly problem during deserialization (based on the third case). In fact, the root cause of the above problem is. the classes defined in the aspx file are dynamically compiled, and the programs generated by the files are saved on the system disk.. Net directory (httpruntime. codegendir to find this directory. many changes to the aspx file will force Asp.net to re-compile this class during runtime to generate a new assembly (starting with app_web _), while binary serialization and deserialization are related to the Assembly, that is, the assembly information is retained in the data after binary serialization. During deserialization, the corresponding assembly is found to complete deserialization. On the other hand, in the Asp.net page compilation model, when the page changes, a new page assembly is generated during the runtime. There is a mechanism to delete the old page assembly.

Take templateconfig. the ASPX page is used as an example. During the first run, the system generates the corresponding app_web_2342usaj in the temporary directory (note that the file extension is. DLL, omitted here, the same below) Assembly, And then you modified the templateconfig. the ASPX page (save a space). During the second request, the app_web_asdfasd assembly will be generated during the runtime, And the app_web_2342usaj assembly will be deleted during the runtime, however, unfortunately, the app_web2342usaj assembly has been mounted to the appdomain. During Asp.net runtime, the Assembly that has been mounted to the appdomain cannot be deleted unless you restart the application (repair the web. config or global. asax, restart IIS or application pool, and of course restart the computer). If the server cannot be deleted, an empty file named app_web_2342usaj.dll.delete will be added to the temporary directory when Asp.net is running, this is a flag. When the application restarts, The appdomain will be reloaded. before the application is loaded, the app_web_2342usaj.dll file will be deleted, and the templateconfig will be modified 15 times in a row. after the aspx file, the application will restart, otherwise there will be too many assembly in the appdomain and the memory will be consumed (refer to ASP. net2.0 advanced programming). In addition, after using the reference in the page, observe the index. the. compiled files (under the temporary directory) can be found in index. aspx.2342s. the <filedeps> section of compiled (random numbers or characters) contains the templateconfig file. aspx reference, which indicates that the templateconfig is modified. after the aspx file or index is triggered. aspx depends on the cache to clear, that is, index. aspx will re-compile and generate a new assembly. you can also observe these processes on your own.

 

Now we can explain the three situations above.

In the second case, we modified templateconfig. then run index. aspx file, due to index. aspx depends on templateconfig. aspx file, so templateconfig. aspx file and index. the aspx file will be re-compiled to generate a new assembly. The problem is that index. aspx code

 

Protected void page_load (Object sender, eventargs E)
{

ASP. templateconfig_aspx.temp_entproperty properties = serializationhelper. deserialize (serialdata) as ASP. templateconfig_aspx.temp_enterproperty;

// Serialdata is the serialized data in the database.

}

The serialdata used is the data serialized by the original temp_entproperty assembly. Therefore, the deserialization is successful because the old assembly is still in the appdomain during restoration, but the conversion fails, the reason is that the two classes are of the same name, but they are located in different programming sets. If we restart the application at this time, the third case may occur.

 

Case 3: After the application restarts, the old assembly is deleted, the serialized data (including the name of the old assembly) of the temp_entproperty class in the old assembly is stored in the database. The Assembly cannot be found during deserialization.

 

If the problem is found, how to solve it is actually very simple. If you need the advantages of high performance and low data volume brought by binary serialization, put the classes to be serialized in a fixed set of Programs (create a project independently), if you want. the ASPX page directly defines the classes to be serialized, so you can only use XML serialization, because the data after XML serialization does not retain assembly information.