As I work on the help desk I occasionally
talk to people who have various kinds of problems after installing
updates. I see that many customers
hesitate to install updates. Usually, they
worry about two things:
- it can break the functionality of my
application which took me so long to get right!
- most likely, it will not be easy to
upgrade. I will have to waste hours on this minor update!
Yes, it sounds dangerous... Before you make a Hamlet's decision - to
update or not to update - let's estimate the risks. I hope that after reading my blog, it will be
easy for you to make such decisions.
It's easy if you know what to do.
Usually, there is a lack of information on
how to carry out an upgrade. Is it
enough to install a new version or do I have to do anything special? Publishing such information isn't given
serious consideration for two reasons:
a) an upgrade is only done once;
b) information on how to update from
version A to version B becomes obsolete very quickly.
Therefore, this kind of information isn't
worth publishing.
Both points are quite correct, but the
conclusion is a mistake.
Clear understanding of a product and the
difference between its versions is a 50% guarantee of a successful update from
version to version. So please let me
describe how we created our Xtra~ component set over the past 5 years.
As you know, we offer components for .NET
Windows Forms. They have the
"Xtra" prefix in their name.
Originally there were just four products: XtraBars, XtraEditors,
XtraGrid, and XtraSideBar. However,
components had something more in common than just the name prefix: they shared some
code, namely, they had a common DevExpress.Utils assembly. Thus components were interdependent and
mixing their versions made the component set incompatible and lead to problems (http://www.devexpress.com/kbA675).
The history of XtraGrid versions
The XtraGrid is the flagship of our .NET WinForms
squadron. This does not mean however that
the other controls aren't useful, they are very powerful and stable!, but the
XtraGrid still has the greatest tonnage of our squadron. It's easy to define the ages of our component
suites by the version of the XtraGrid.
The first version of XtraGrid was created
in 2001. An installation of it was first
uploaded on our Web site in April 2001. We
were the first component vendor on the .NET market with a commercial (and good,
if not to say superb) product! Well, it
was not easy, but our developers had done a great job!
XtraGrid 1 was created when Visual Studio
.NET was in beta. There was very little
information about the new .NET technology.
Microsoft's documentation on the .NET Framework in the form you see it
now in appeared later. By version 1.5.x
we have significantly improved the XtraGrid 1 and made it feature rich and
stable. XtraGrid 1 was great, but it had
many bottlenecks in its design.
As I said, there were shared assemblies in
our components. DevExpress.Utils was
used (and it is still used) by all of our .NET components. Additionally, there were XtraEditors
components. The XtraEditors are used by
many our products. At the time of
XtraGrid 1.5 the XtraEditors could be used in the XtraGrid, XtraTreeList, on
toolbars and in menus of the XtraBars and as stand-alone controls on a
form. Drawbacks in the XtraEditors internal
design prevented us from moving forwards.
Our developers had to make a hard decision to rewrite the XtraEditors
from the ground up. We knew that a new
version would be incompatible with version 1.
But we also knew that we would never create XtraGrid 3, if we did not
rewrite the XtraEditors for XtraGrid 2.
Upgrading a project which uses XtraGrid 1
to XtraGrid 2 is not easy. I have
written a Knowledge Base article (http://www.devexpress.com/kbA953)
which covers 90% of the upgrade process from v1 to v2. Now, as we already have XtraGrid 6.1
released, I can add just two comments to the article:
1. It's impossible to jump from XtraGrid v1
straight to v6.1. A project with
XtraGrid 1 must be first upgraded to XtraGrid 2, then to v3 and finally to
v6.1. It may sound strange, but doing so
it's easier to control the upgrade process and make sure that you have your
project working correctly after getting it compiled with the latest version of
the XtraGrid. This process is described
in detail below in this blog.
2. The upgrade process from v1 to v2 is
difficult. If you give up performing it
yourself, you can rely on our assistance in this regard. Feel free to write to support@devexpress.com and we'll upgrade
your project for you.
Here I want to thank you everyone who had
their project with XtraGrid 1, converted it to XtraGrid 2 and did not lose his faith
in Developer Express. Thank you!
XtraGrid 2 had eight companion products:
XtraBars, XtraEditors, XtraNavBar, XtraPrinting, XtraReports, XtraSideBar,
XtraTreeList, and XtraVerticalGrid. Certainly,
these products were interdependent.
Customers often had a problem after updating some of these products and
forgetting to update others. We created
a combined installation - Windows Forms Suite - and it prevented customers who
had the entire component suite from installing incompatible versions of
different components. Customers who did not
own all products still could get into trouble after installing incompatible
versions.
There was also another problem with
XtraGrid 2 - its assembly had exactly the same name as in v1. As a result, a programmer could not have
XtraGrid 1 and XtraGrid 2 installed side-by-side to work on projects with old
and new XtraGrid versions (http://www.devexpress.com/kbA954). To tell the truth, it was not a big deal:
XtraGrid 2 was worth upgrading to from XtraGrid 1 regardless of the hard work
involved in doing so.
XtraGrid 3 was released in April 2005. We have learned the lesson from our customers'
problems with upgrading XtraGrid v1 to v2.
XtraGrid 3 and its companion products are 99% compatible with the
previous version. The upgrade process
was supposed to be smooth and it was, if compared with upgrading from v1 to
v2. We prepared an "XtraGrid v2 to
v3 Conversion Guidelines" document which, unfortunately, was not
published. We also renamed the
assemblies of all our .NET components - they include number 3 which indicated their
compatibility with XtraGrid 3. Users
could have XtraGrid 2 (Windows Forms Suite v1) and XtraGrid 3 (Windows Forms
Collection v2) installed side-by-side and quite easily detect whether an
assembly belongs to XtraGrid v3 or v2 component family. However, version numbers of different
assemblies were still confusing. For
example, compatible versions are XtraGrid 3.2.3.0 and XtraNavBar 2.7.3.0 and
XtraReports 1.12.3.0. That is, one could
detect compatible / incompatible versions only by the assembly build number
(it's x.x.3.0 in my example) which, of course, wasn't intuitive.
Another problem with our XtraGrid 3 products
we figured out was the Microsoft Installer engine (MSI) used in our
installations. MSI is so
"clever" it "decides" itself which assemblies are
interdependent and locks them in the Assembly Cache (GAC). It happened sometimes that assemblies were
not removed from the Assembly Cache after uninstalling a product. Then after installing a new version there
could be a situation when multiple versions of a given assembly were installed
simultaneously. This caused various
problems both at design- and runtime. We
created a VersionChecker utility (http://www.devexpress.com/freedownloads/VersionChecker.zip)
to detect these situations.
Additionally, I've written an article which should help you ensure your
system is clean before installing maintenance updates to the XtraGrid v2 and v3
products (http://www.devexpress.com/kbA138).
DXperience 6.1 is a new generation of our
.NET components product line. The
components included in the suite have been significantly updated, but, in my
opinion, the fact that our new installation system solves all problems
mentioned above is an even bigger step forward:
1. There is a single installation. It will not allow you to install incompatible
versions of our components.
2. All assemblies have one and the same
version number. DLL versions are no
longer confusing.
3. We don't use MSI any longer. The installation executes very fast! The installed files aren't locked in the
Assembly Cache.
4. If you decide to rebuild components from
source code, it is easier to do this than before (http://www.devexpress.com/kbA609),
because
* the projects' output paths are the same
as the DLLs installation path;
* you can be sure that your assemblies
automatically overwrite our assemblies;
* it's easy to remove the existing
assemblies from the GAC - they aren't locked;
* you don't have to add any registry keys
to make Visual Studio "see" your assemblies.
I hope to update the mentioned article soon
if I have some spare time.
I read rumors in our public newsgroups that
our new system of assembly naming is bad.
Don't worry about this and believe our experience - it has more pros
than cons :-)
Now, as you have a notion of our products
evolution, let's talk about conversion from version to version. I will first describe the conversion process
for major versions - v1 -> v2 -> v3 -> v6.1 - and then minor version
updates.
Converter Utilities
The converter utilities - XtraConverter and
ProjectConverter - are supposed to upgrade a project from a minor version of
our components to a major one. You don't
need them after installing each maintenance update.
The XtraConverter utility
(XtraConverter.exe) was shipped with XtraGrid 2. It was intended to upgrade a project with
XtraGrid 1 to XtraGrid 2. It did the
following:
1. Removed a reference to
DevExpress.XtraEditors.Core from a project and added a reference to the
DevExpress.Data assembly.
2. Patched the Windows Forms Designer
Generated code, namely the InitializeComponent method of your forms and
UserControls.
It did not patch user's code - we cannot
take responsibility for changing your code.
Thus, you had to manually fix compiler errors due to any
incompatibilities between the XtraGrid 1 and 2.
I mentioned this above.
The XtraConverter shipped with the XtraGrid
3 / Windows Forms Collection 2 and could upgrade a project with XtraGrid
v2-family components to v3. It did the
following:
1. Replaced DevExpress.* references with
references to the DevExpress.*3 assemblies in project files (~.csproj and
~.vbproj).
2. Cleared the content of the licenses.licx
file.
Please note that this version of the XtraConverter
does not change any code. XtraGrid 3 is
backwards compatible with XtraGrid 2.
After executing the XtraConverter against your project, you should be
able to compile the latter without any errors.
Please note that the XtraConverter
utilities don't support Visual Studio 2005 project files. Thus, you should first convert your project
to XtraGrid 3 and then to VS2005, not conversely.
DXperience 6.1 installs a ProjectConverter
utility. It does the following:
1. Replaces DevExpress.*3 references with
references to DevExpress.*.v6.1 in the project files.
2. Clears the content of the licenses.licx
file.
3. Parses the RESX files of your project
and replaces the DevExpress.*3 references with DevExpress.*.v6. This occurs if your project contains
localizable forms.
General Instructions on Upgrading Your Project
I'll write my instructions in a
step-by-step manner - it's easier to follow them then. Let's consider the major upgrade process on
the XtraGrid 3 to XtraGrid 6.1 conversion example.
You were using XtraGrid 3 / Windows Forms
Collection 2 and have decided to install the DXperience and upgrade your
project.
1. Do not uninstall XtraGrid 3. You will do this later.
2. Install the DXperience product.
3. Backup your project.
4. Execute the ProjectConverter against
the directory where your project is located.
5. Open your project (solution) in Visual
Studio. If there are forms or
UserControls opened in design mode in your development environment, please
close them without saving any changes.
6. Rebuild your project. If there are compiler errors, please correct
them. Please ignore compiler warnings if
any at this stage.
When your project is successfully built,
you can open forms in design mode and carry on working on your project: launch
it, test it, write new code, design forms and user controls. If you wish to eliminate warnings introduced
by the new version - some methods and properties may be marked as obsolete,
please note that most of the warnings usually relate to the Windows Forms
Designer Generated code. You can easily
fix them with the following steps:
7. Open a form which has warnings in design
mode.
8. Change anything on this form - I advise
that you change a Boolean property, e.g. set AllowDrop to true and back to
false - to force re-generation of the InitializeComponent code.
9. Save your form file.
It's best to repeat steps 7-9 for each form
in your project especially if your forms are localizable. However, this is not always necessary and you
don't have to do such dummy manual work :-)
Perhaps, we will work out a way to automate this process.
Instructions for a Safe Minor Update
Assume, you have DXperience 6.1.1 and want
to update it to DXperience 6.1.3. Note that you can jump to 6.1.3 without installing 6.1.2 - all our minor updates are cumulative. Please
perform the following steps:
1. Backup your project.
2. Install a new version (DXperience 6.1.3
in this case). The installation will
automatically update the previous version so you don't have to explicitly
uninstall it.
3. Open your project in Visual Studio and
rebuild it. If you are using Visual
Studio 2005 and get compiler errors, please see the following Knowledge Base
article:
http://www.devexpress.com/kbA2950
Launch your project and check how it
works. If you have automated tests for
your project, I advise that you execute them.
XtraGrid v1 to v6.1 Upgrade Walkthrough
Below are step-by-step instructions on how
to upgrade a project with XtraGrid 1 to the latest version of our XtraGrid's squadron. If, say, you have a project with XtraGrid 2,
just skip the first step.
0. Please backup your project. We also advise that you create a new backup
after performing each step listed below.
1 You should uninstall the XtraGrid v.1.x
components, install XtraGrid v.2 and convert your project to it. Here is the link to the XtraGrid v.2 trial
version:
http://downloads.devexpress.com/Share/Updates/WinForms1.3Trial_ToConvertGrid1to3.exe
Then please follow the instructions from
this Knowledge Base article:
http://www.devexpress.com/kb953
Please note that you should use Visual
Studio .NET 2002 or 2003.
2. Install Windows Forms Collection v.2.2.5
(contains the latest version of XtraGrid 3).
http://downloads.devexpress.com/Share/Updates/WinForms2.2Trial_ToConvertGrid2to3.exe
Here is the document, which may help you to convert XtraGrid v.2 project to XtraGrid
3:
http://downloads.devexpress.com/Share/Updates/XtraGridV2toV3.zip
If any errors cannot be fixed, please
send the error message text and the relevant code snippet.
3. Install DXperience 6.1 and use the
ProjectConverter tool shipped with the suite to convert your project from v.3
to the latest version.
4. If you need to upgrade your project from
VS.NET 2003 to VS 2005, please install DXperience 6.1 for Visual Studio
2005. Convert your project to the .NET
Framework 2.0 by opening it in Visual Studio .NET 2005. I advise that you check the references to our
assemblies, because they are different for .NET Framework 1.0/1.1 and .NET
Framework 2.0. The references must have a
Runtime Version equal to v2.0.50727 and point to the C:\Program Files\Developer
Express .NET 2005 v6.1\Sources\DevExpress.DLL directory (the default location
of our assemblies). If they don't,
please delete the references and manually add them: browse to the mentioned
folder and select the assemblies from it.
Finally, you will need to rebuild your project.
Hopefully, this information will come in
handy and you will not be afraid of the upgrade process for our
components.
Free DevExpress Products – Get Your Copy Today
The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the
DevExpress Support Center at your convenience. We’ll be happy to follow-up.