Delphi.dpr and .dproj - consequences of non-compliance

What are the consequences of having a mismatch in the uses list in Delphi.dpr and .dproj projects (XE, if that matters)?

At first glance, it seems that .dproj is updated in accordance with .dpr, but is this always the case?

The reason we are having this problem is because we need to apply the parameter to the project after checking the version control, this parameter depends on the developer, therefore it always led to conflicts in version control. We decided to sort this problem using the template file and generate the .dproj file. Now we have a potential problem for developers who forget to change the template when adding / removing .pas files from the project. As I said, this seems to work, but does anyone know of any dangers we may face?

Alternatively, does anyone have a better idea for a solution? Interesting DProjMaker seems to be interesting - has anyone used it? http://delphi-divining.blogspot.co.uk/2012/10/dprojmaker-tool-to-create-delphi.html

2nd option - could we just remove all .pas links from templates and rely on Delphi, regenerating them if necessary? I think this will only affect MSBuild? (can someone confirm)

Additional information in response to the comment: The parameter is an encoded string containing information about connecting to the database (and maybe some other things, I did not look too deep).

In a normal (user) operation, we have a login program in which the user selects which database they want to connect to, and launches other applications, passing this information as a parameter. As developers, we need to run programs directly, so we create the appropriate code for the database we are connecting to and set it as a parameter that should be passed to the application in Delphi.

+6
source share
1 answer

As suggested by Brian Frost:

The solution is to delete the .dproj files.
Delphi will recreate the file when opening the .dpr file.

+1
source

All Articles