How to keep personalization when moving a class from WebPartManager to a new assembly?

Question

We have a website project that was launched many years ago. Personalized web parts are used on the landing page, and the web part manager is an extension of the .NET WebPartManager class located in App_Code. Curiously, if we move this class to another assembly in the same solution, the personalization will be cleared, and we will be able to save the new personalization. But when we move the class back, it again loads the original personalization. All PathId, UserId, and ApplicationId objects remain unchanged in the asp_PersonalizationPerUser table (see http://msdn.microsoft.com/en-us/library/aa478955.aspx for details.)

UPDATE. The reason I ask is because we need to convert our project into a web application project, and we don’t want to cause any crashes among some of the 500 users who use the application daily. I set the shelves for conversion, and everything seems to be designed except for this problem.

UPDATE 2: It occurred to me that I needed to reformulate my question.

How to keep personalization when moving our class that comes from WebPartManager to a new assembly?

Answer 1

Since the implementation is very complex and internal to the .NET platform, creating custom source code to manage this is unacceptable. Instead, working with a database script during maintenance would be a better option. Example:

// Read the 'PageSettings' column from the ASP personalization tables // into a byte array variable called 'rawData' first. Then continue: var mems = new System.IO.MemoryStream(rawData); var formatter = new System.Web.UI.ObjectStateFormatter(); var oldState = formatter.Deserialize(mems) as object[]; var index = oldState.ToList() .FindIndex(o => o as Type != null && ((Type)o).Name.Contains("WebPartManager")); // In our case, the derivative class name is "MyWebPartManager", you // may need to change that to meet your requirements oldState[index] = typeof(WebPartManager); mems = new System.IO.MemoryStream(); formatter.Serialize(mems, oldState); var newState = mems.ToArray(); // Write 'newState' back into the database. 

Answer 2

In addition to determining personalization status by user name and path, SqlPersonalizationProvider supports scaling by application name. Websites that register personalization providers with the same applicationName attributes share web part personalization data, while websites that register personalization providers with unique application names do not. Due to the page-specific and control-specific nature of the personalization data, however, as a rule, it does not make sense to use the same application name to personalize web parts on different sites.

Does your new web application project have a different application name than the previous one?