Migration to NET 2.0 Adventures
Well, I have started the migration of our huge code base to NET 2.0. Our entire solution includes more than 30 C# projects (counting setup projects), so it's a rather big solution.
I opened the VS2003 root solution using VS2005 to kick off the conversion process, and in general all went smooth. The process finished without problems after serveral minutes of hard work, everything compiled without major issues and then the post-convert tasks begin.
We have a policy regarding compiler warnings that states that all warnings must be treated as errors, so I must fix all warnings before continue. Several things are changed to obsolete in NET 2.0, and here I present a condensed list of items fixed to avoid those "obsolete" compiler warnings.
Changed Strong Name configuration
The attributes AssemblyKeyFile and AssemblyDelaySign that previously existed in the AssemblyInfo.cs file are not longer supported.
The recommended way to specify a strong name is by using the “Signing” tab in project properties. So, you must eliminate these unwanted attributes from every AssemblyInfo.cs file and touch every project configuration manually.
I think that simple and mechanical task could be performed by the conversion wizard, don’t you?
All “GetHostXXX” and “Resolve” functions are now replaced by the all powerful GetHostEntry. They return the same IPHostEntry objects and the change is rather simple.
GetHostByName à GetHostEntry
GetHostByAddress à GetHostEntry
Resolve à GetHostEntry
The method “GetMessageEnumerator” is now obsolete, replace with “GetMessageEnumerator2” without further changes.
The exception “ConfigurationException” is now obsolete, and is recommended to use the new “ConfigurationErrorsException” exception.
Remember to add a reference to the “System.Configuration” assembly or the later won’t be found.
Replace the class “ConfigurationSettings” by “ConfigurationManager”.
The method “GetConfig” from class “ConfigurationSettings” is now replaced by the method “GetSection” in the “ConfigurationManager” class.
If your application writes to the EventLog you should be doing a security assert trough CAS. The recommended way to do that is using declarative security through the use of attributes, in particular “EventLogPermissionAccessAttribute”.
Previously, if you wanted full access to the EventLog you should demand “Instrument” permission. This permission is now deprecated and you should use “Write” permission.
EventLogPermissionAccess.Instrument à EventLogPermissionAccess.Write
If your application writes to the registry you should be doing a security assert trough CAS. The recommended way to do that is using declarative security through the use of attributes, in particular “RegistryPermissionAttribute”.
Previously, if you wanted full access to the local registry you should demand “All” permission. This permission is now deprecated and you should use “ViewAndModify” permission.
RegistryPermissionAttribute.All à RegistryPermissionAttribute.ViewAndModify
The property “FullTrustAssemblies” in the class “PolicyLevel” is no longer supported. All references to this must be removed from the project.
If you use interop you must work with handles. In NET 1.1 existed the “WaitHandle” class for thread synchronization but for NET 2.0 has been superseded by the new “SafeWaitHandle”. The change is almost a search & replace operation.
WaitHandle à SafeWaitHandle
The model for IDictionary based collections changed in the way internal items are compared and stored through the use of Hash codes. So, all constructors using an ICompare and IHashCodeProvider are now obsolete and should be replaced by the new IEqualityComparer interface.
In our case, the keys of all collections are strings and case insensitive so we use the “StringComparer.InvariantCultureIgnoreCase” object.
ICompare, IHashCodeProvider à StringComparer.InvariantCulture
ICompare, IHashCodeProvider à StringComparer.InvariantCultureIgnoreCase
All Framework classes implementing IDictionary must be changed to reflect the new signatures. Some of the more important classes modified include: CacheHelper.cs, IndexedDictionary.cs and XmlSerializableDictionary.cs.
All ToString( CultureInfo.InvariantCulture ) is now obsolete and the “CultureInfo” object must be removed from the “ToString” function.
The method “RegisterChannel” from the class “RemotingServices” now requires an additional Boolean parameter “security” to indicate if this channel will have security restrictions enabled. This flag supersedes the previous configuration parameter “typeFilterLevel=Full” to allow serialization of unsafe Types.
The “Configure” method from class “RemotingConfiguration” now requires an additional Boolean parameter “security” to indicate if security restrictions are enabled. This flag supersedes the previous configuration parameter “typeFilterLevel=Full” to allow serialization of unsafe Types.
The “AppDomain” class no longer supports the method “AppendPrivatePath”. To change this configuration the property “PrivatePathBin” from the “SetupInformation” property must be appended with the new folders, separated by semicolon.
The “AppDomain” class no longer supports the method “SetShadowCopyPath”. To change this configuration the property “ShadowCopyDirectories” from the “SetupInformation” property must be appended with the new folders, separated by semicolon.
The function “LoadWithPartialName” from the “Assembly” class is not longer supported and must be replaced by the “Load” method.
Pages containing a control named “Header” will fail to compile because the new “Page” class already includes a new “Header” property. The controls are renamed “HeaderLabel” to avoid the conflict.
The methods “IsClientScriptBlockRegistered” and “RegisterClientScriptBlock” are now obsolete in the “Page” object and the “ClientScript” class must be used.
The class “XslTransform” is now obsolete and replaced by the new “XslCompiledTransform”. This new class has some new overloads for the method “Transform” but in general conversion is easy.
The method “ToDateTime” from the class “XmlConvert” has a new parameter indicating the serialization mode of the date value. This new parameter is an enum of type “XmlDateTimeSerializationMode” and defines if the DateTime will be serialized using local time, UTC, etc.
The class “XmlSchemaElement” no defines a strong typed “ElementSchemaType” property that replaces the old (no strong typed) “ElementType”.
The class “XmlValidatingReader” is not longer supported, so “XmlReader” must be used. The class “XmlReader” now uses a new class of type “XmlReaderSettings” to configure the type of validation to use and schema information to include. This class is passed to the constructor of the new “XmlReader” class.
The “ApartmentState” property in the “Thread” class is now obsolete and must be replaced by “GetApartmentState” and “SetApartmentState” methods. Change is a simple copy & paste operation.
The property “GetCurrentThreadId” in the “AppDomain” class is now obsolete and must be replaced by the property “ManagedThreadId” in the “Thread” class.
I hope this serves as a guide for anyone migrating a NET 1.1 project to 2.0. I will post more information as the process of migration moves forward.
Andrés G Vettori
Leader of the C# Community of the Microsoft Users Group Argentina
Well, I finally managed to install it... but it wasn't easy....
I'm just uploaded to the Retina Workspace at GotDotNet a prerelease version of Retina.NET v1.0.7 (build 2) for testing and feedback from the community.
This is a minor release made to support all the new features of the Retina.NET ORM v22.214.171.124, and the changes are:
*- Better support for output parameters in the ADO.NET provider.
*- Support for TIMESTAMP columns.
*- Better support for variables and their assignation of values.
*- Removed the SQL Mobile dependency from the PocketPC version.
*- Some other minor issues.