Building DevExpress Sources

How to Build DevExpress DLLs for Debugging

This article is your 10-step guide explaining how to build a debug version of the DevExpress component assemblies from their supplied source code. My recent experiences force me to say, wonderful component suite, but their instructions on this particular activity fall a little short of being self-explanatory!

1. Get the Zip

First go here:

http://www.devexpress.com/Support/Center/p/A609.aspx

Pick up the Attachment version relevant to the target DevExpress DLLs version. If it's not listed, request it, go home, and come back next day.

Notice the file PublicKeyToken.txt, which we'll be using later. Actually that's the only, paper-thin justification for this article's Security tag...

2. Check DEFINES.BAT

Follow the first couple of instructions in the Attachment's README.TXT file: copying all the files from its folder or Zip archive into your DevExpress Components Sources folder, and then checking the content of DEFINES.BAT. Note from the location of this file, that should you have to edit it, you will probably have to do so using e.g. Notepad Run as Administrator. Verify in particular the specific version of Studio you are using (vsver), the GAC path(s), and the locations of the correct sn, gacutil and MSBuild executables.

3. Edit the Supplied Batch Files

You're going to want to Run as Administrator the DevExpress source building scripts, CLEAR.BAT and BUILDALL.CMD, following the directions in the associated README.TXT file. But before you do, note that since the files CLEAR.BAT and BUILDALL.CMD will probably have to be Run as Administrator, their default current directory will be something like C:\Windows\system32. We need them to be running instead in the DevExpress source folder, and one way to achieve that is to edit these files so they look a bit like this:

REM @echo off
C:
CD \Program Files (x86)\DevExpress 2009.2\Components\Sources
call defines.bat

and so on. However, note also from the location of these files that you will probably have to edit them using e.g. Notepad Run as Administrator.

4. Build the DevExpress DLLs from Source

Okay, so now Run (as Administrator) your edited CLEAR.BAT and BUILDALL.CMD. Obviously you can safely ignore any generated error messages that relate to software components you haven't installed (CompactFramework, LightSwitch, SharePoint, SilverLight, etc).

5. Create Toolbox

If your target version of DevExpress supports it, now is the time to run the ToolboxCreator utility. How will you know if it's required? Well, if it's in the Start menu for your version of DevExpress, e.g.

Start / All Programs / Developer Express v2009 vol 2 / Components / Tools / ToolboxCreator

then it's required, and you should run it. Whereas if it's not, then it's not, and you shouldn't.

6. Copy New DLLs to Local Folder

Before proceeding to run ProjectConverter, if your third party component binaries are under version control as an External, you'll probably want to copy the newly compiled DevExpress DLLs from whichever output folder they've just been built into, e.g.

C:\Program Files (x86)\DevExpress 2009.2\Components\Sources\DevExpress.DLL
- or -
C:\Program Files (x86)\DXperience 12.1\Bin\Framework

to their local destination, e.g. MyProject\ThirdPartyComponents\Developer Express\DLL, or whatever.

7. Convert Projects

The devExpress README.TXT gives a command line for running the Project Converter utility. I prefer to omit the parameters and use the interactive graphical UI version. However that's not always possible, as earlier versions of the converter don't have the Advanced options UI letting you specify the new Public Key (PK). Be aware that the command line version, if provided with a Project Path, will start conversion immediately, without giving you a chance to adjust any of the other parameters. Either way, be sure to make all of the following settings correctly:

• Your Project Path(s);
• HintPath behaviour (I normally use Update rather than Remove);
• The new PK value (this should be available in the aforementioned file PublicKeyToken.txt).

Inspect any errors in the log output by the conversion process and decide whether or not you care enough about them to start again from Step 1 and be more careful!

8. Check Post Build Events

One subject easily forgotten during this process is the area of post build events in your own project code. These are often used to consolidate the outputs of multi-project or multi-solution systems into a final staging or deployment folder, and in particular, to ensure that all third party assemblies are copied efficiently, i.e., once only. For this reason, the events you are likely to have to care about are those associated with your main exe or web app projects: clients, services, data portals, auxiliary apps and so on.

The aim of this step is to ensure that all DevExpress references end up pointing to the same third party component assemblies folder.

9. Clean Project Output Folders

Again, the aim of this step is to ensure there are no remnant, pre-source-build versions of the DevExpress libraries visible to the compiler. Prior to compiling your code, be sure to delete all bin, obj, Output and/or Run folders generated during your build process, to ensure a clean result.

10. Build Your Solution(s)

And we're done! Get back into Visual Studio and check that you can step through the DevExpress source code, see it in the Call Stack, and enjoy all of its sourcey goodness. Or failing that, consult the troubleshooting section of README.TXT, or the DevExpress Support Centre, Knowledge Base and Forum.

11. Reversion

As described in the Attachment's README.TXT file, you can revert to the installed DevExpress binaries by running the installer in Repair mode. This is essentially the undo of Step 4 above, so to complete the process you will possibly want to follow this with steps 5-10. Alternatively, you might just restore your entire solution image(s) from version control.