After migrating all the source files, it's time for the actual code migration.
AS stated before, the pilot is implemented on a real project.
The project is divided to 1 infrastructure subsystem and another 4 subsystems.
For now, we decided to migrate only the infrastructure subsystem,
and one of the other subsystems, that contains both server & client code, so it's a good case to work on.
The conversion was done on a VMWARE machine, running with one 2.7Ghz CPU & 512MB RAM with Windows 2003 Server SP1.
We asked Ziv (one of the senior developers in the system) to migrate the code.
Ziv did not have prior experience with CLR 2.0. Most of the findings here were translated from and Internal Report Ziv wrote.
The target was to make the code compile with no errors or warnings what so ever,
and then make all the unit tests pass as green ( Nunit 2.2.2, see prior post).
It took 2 days to make the code compile, 2 more days to solve runtime errors, and another day to make all the unit tests pass.
No QA tests were done to the system beyond that.
All the code changes were made with special regions & were well commented,
for easy merging to the real dev branch in the future.
It took a total of 5 work days for 1 senior developer to complete the mission.
General impression from the code migrations stage:
The new IDE is pretty stable for a Beta 2 version. during the working week we encountered only few Exceptions/Aborts.
The newly added features such as code refactoring etc are great.
The main problem was performance. The performance is unacceptable for normal developing.
Compilation time increased about 5 times more then VS 2003, the IDE often freezes for several seconds which is pretty annoying...
Another general problem we encountered is that the new IDE make a bad assumption that the developer has an Internet connection.
A big part of the links in the IDE are links to the Internet and not the local MSDN installation.
in our case the developers work in a closed intra-net environment, so it's a bit frustrating.
During the migration, the compiler often tries to help by giving a link to MSDN
which explains how to convert the code which is great, but most of the links again - refer to the Internet,
even if the information is also available in the Local MSDN installation.
sometimes the explanation was available only in the Internet, which forced us to go to another network and print some pages there...
The new MSDN Feel & Look is nice, it takes time to get used to for us "old" developers,
but it seems like an improvement as the search tab now tries to be a "Search Engine" like.
The big problem with the new MSDN was that it was very buggy.
The search engine constantly returned false results. For example, if I search for the work "XML" I get X documents,
and when I search for "XML and Schema" I get Y documents, and Y was greater then X which is logically impossible.
it gave us a bad time while searching for migration information, especially since the original compiler help links did not work for us.
I edition to that , the new MSDN Archive Manager which is a nice Idea, gave us trouble too.
We selected several topics to be included, but when we saved and open the MSDN tool,
the list of topics we got there was different from the one we selected...
The integration with the Team Foundation Server is very nice & user friendly, but performance is terrible too.
The Team Foundation server has memory leaks which causes performance degradations, and after 3 days of work with 1 developer
I had to restart the services in order to be able to continue testing in a reasonable time...
List of Source Code changes we made during the migration phase:
- Changes we made in order to make the code compile with no Errors or Warnings:
- Major Changes:
- The usage of XML Schemas has changed. The new framework uses a class called XmlSchemaSet which represents a collection of schemas which compile together to a single logical unit.
- The usage of XML Readers has changed. The new framework makes the XmlValidatingReader obsolete. Instead, we now need to work directly with the XML Reader, supplying it with an object of type XmlReaderSettings which defines some attributes on the reader we have created.
- Compile-time error identification of unmanaged resources usage problems. I must say we liked this new feature a lot. the new framework identifies in compile time bad usage of Finalizers and reports on it. We encountered only one instance of this case in the system and replaced it with a correct implementation. Coolness.
- Minor Changes:
- The Assembly signature method has changed. in CLR 1.1 we signed the Assemblies using the AssemblyKeyFile Attribute usually found in the AssemblyInfo.cs file. Instead, the new framework makes as use Project Level definition. This is not so bad, only it was frustrating to change it manually to our 70 assemblies. in VS2003 we could select multiple projects and change a property for all of them at the same time. In 2005 The GUI did not let me select multiple projects for the Project properties dialog. I wonder why.
- The usage of Path.InvalidPathChars was replaced with the Path.GetInvalidPathChars() method.
- The Certificates usage was changed. The new framework defines a delegate method on ServicePointManager for Certificate validations instead of the class usage which replaces the standard behavior of the Certificates Control.
- Form.AutoScaleBaseSize used to be an int value. In the new framework it was replaced with Form.AutoScaledimensions which is a float.
- The AppDomain.GetCurrentThreadId() Method was replaced with CurrentThread.ManagedThreadID.
- The SmtpMail class is now obsolete. there is a new class which replaces it. we decided to remove the entire code that uses SMTP which implemented special critical error log reporting using email, since we never used it in the past 3 years.
- The Dns.GetHostName() method was replaced with Dns.GetHostEntry() method.
- Parameter.Add() method was replaced with Parameter.AddWithValue() method.
- Changes due to runtime errors:
- This is a new cool feature of the runtime. The new Framework identifies at runtime of objects trying to access other objects from a Non GUI thread to a GUI Thread object without a proper Invoke. It throws a proper Exception. we identified only one case in the system (Bad code in the Client's Splash Screen). This is very cool, because such code can ofthen create random results, and hard to re-create bugs. Other instances of the problem might come up when the system will be sent to QA for a proper regression test.
- Microsoft score again. Another cool feature ! The runtime now identifies inconsistencies between XSD Schemas of Datasets, against the real Database Types ! When the runtime encounters an inconsistency, it thrown an exception. The the system we encountered 2 instances of the problem, and the Schemas were corrected according o the DB Types. I guess it happened when someone changes the DB without changing the DAL Code properly.
- Changes made due to Unit Test Failures:
- The new framework adds the `xml:space="preserve"` Attribute when it finds an empty node in the XML Document. We added the new attribute to the proper places in the XML files.
- Some Unresolved Issues we decided to let go for now:
- The client application had a special mechanism that used a special "Home made" Semaphore ( CLR 1.1 didn't have a built in one, CLR 2.0 does). the implementation was bad and we knew it for some time now. it caused a some bugs in the GUI, but they were very rare. When running on CLR 2.0 for some reason the mechanism stopped working almost completely. We did not try to fix or search why, as the proper action here is to re-write the entire mechanism correctly.
- The server Application started to load very slowly. Short investigation discovered that there is a problem the the Assemblies loading phase that causes some kind of a deadlock. The runtime releases the deadlock somehow after 20 seconds and everything goes on well. It's mainly annoying for debug time to wait these extra 30 seconds each time we start the server process...
- The Client Splash Screen started to appear in the top left corner of the screen instead of the center. We didn't bother to check why for now.
Pilot Milestone Conclusions:
Due to these findings we have decided to stop the Pilot process at this time.
We understood that the migration process is not very heavy,
so we don't need to start it too much ahead before we actually want to transfer to 2.0.
We are estimating that giving the knowledge we got during this work week,
the entire team (4 People) can Migrate all the system in one more week).
One of the possible ways we thought of going here before the pilot
was to transfer the dev team to start developing Version 2.0 of the System which starts in less then a month on the Beta2,
with the new Team Foundation, and only transfer them to the release version in November after the Whidbey final release,
as Version 2.0 of the system is not expected to reach production stage until the middle of 2006.
Sadly, since the development experience with the current performance is not acceptable,
we have decided to wait for the final Release in November,
Hoping that Microsoft will fix the performance problems & server Leaks by then.
We saved the converted source, awaiting November 7.
Phase 4 & 5 of the Pilot will not happen for now,
I will write some conclusions about it in a separate post, but it won't be informative as I planned too.
Eli.