Would anyone recommend re-creating NEW projects and re-adding source, and why?

Question

We have a large SQL driven software system which has been around since Delphi 1. It uses the same original project files in all of its various projects. We've recently begun upgrading to Delphi XE2, and I've been contemplating the idea of creating NEW project files and re-adding all the source again - to make sure they get the recommended defaults of a new Delphi XE2 project.

Would anyone recommend this? And what are the risks? Obviously it's a difficult task, re-defining version number, project names/description/company info, etc. But it's the size of the original projects that scares me. 3 main executables plus many others, totaling in probably close to 3 million lines of code all together.

The main reason I'm thinking of doing this is because I've seen how new Delphi XE2 projects automatically create sub-directories per platform and release (Win32, Win64, Debug, Release, etc.). Our projects are currently a mess and I've been trying to clean it up.

So what would you say the risks are in this? And why or why not is this a good idea? Could there be some alternative to "Reset" the defaults?

Answer 1

Re-creating the project file shouldn't hurt, yet it shouldn't add anything useful either. I'd seriously question your motivation and I'd consider changing only what needs to be changed:

Our projects are currently a mess and I've been trying to clean it up.

Anyone that's been around a big project probably thinks that at some point. If there truly is some "mess" somewhere, it's in the project's source files (PAS, DFM) not in the actual project file. Refactoring should probably go the other way around. Reorganize the source files (if needed), remove files that are proven to be redundant, and the project file will immediately reflect the new found cleanness.

Obviously it's a difficult task, re-defining version number, project names/description/company info, etc.

That's ALL on one page in the project's options. I honestly doubt that's going to be the most difficult thing you'll need to do. You're much more likely to discover hard-coded dependencies on 3rd party components and other in-house projects. Those will be a pain to track down, because you'll hit ReBuild time and time again, fixing the one unit the compiler complains about.

The idea is that the project file lists the files that makes up the project and includes a minimal set of compiler options and defines. If you re-create the project file you'll end up adding all the compiler options and defines back in, and you'll also add every single one of the files back in, one at a time, because that list is actually coded in the uses clauses of the files that make up your project. The only files that will NOT make it back in are those that can be found on the search path, in the project's folder and those that truly are redundant. If you want to remove redundant files, this is not the way to go. Better look into some sort of uses list analyzer.

The main reason I'm thinking of doing this is because I've seen how new Delphi XE2 projects automatically create sub-directories per platform and release (Win32, Win64, Debug, Release, etc.)

No need to re-create the project file for that, simply change the Output Directory and Unit Output Directory in your project's Compiler Options to this:

.\$(Platform)\$(Config)

Answer 2

One thing you need to be wary of if you go about recreating the .dpr is making sure that your units don't have any hidden interdependencies that will spring up and make your app misbehave in strange ways.

In fact, we ran into exactly this recently. Avoiding the backstory of why it was done, one of my coworkers created a new project and re-added all of a current (legacy) project's units. After rebuilding, the new executable threw access violations and then put a dialog prompt up on screen where he couldn't find the reason for its access.

It turns out there are quite a few dependencies between items (e.g. A form's OnCreate calling methods in datamodules) that caused the AVs, and the wrong form was being created first, making it the app's main form. The original project source had all the items added in a particular order to ensure that. When he recreated the project, he added all the units from Explorer in their native order -- alphabetical.

Now, you could use this as an opportunity to refactor your application to ensure that these kinds of timing issues and dependencies aren't a problem and perhaps disable form-auto create so that the only forms that are active in your app are the ones you need at any given point in time. Or you could just carefully modify the options directly to match the new defaults, if they make more sense for your project than the old ones.