Do publish your .dproj/.groupproj in your version control systems (via: DelphiTools)

But I partially agree with the statement that Eric Grange made at DelphiTools as part of his post via Don’t publish your .dproj/.groupproj a few years ago:

Ad interim, .dproj are just a kludge by design

I completely disagree with hist blog post title: in my opinion “Do publish your .dproj/.groupproj in version control systems”

The discussion that followed in the comments was quite interesting: to bad I missed it back then.

Both .dproj and .groupproj are indeed a bit of a kludge. The main reason is that there is little documentation about them on the Embarcadero sites: most of it are threads on the forums.

msbuild

If you remember that basically they are just msbuild XML files, which is part of the .NET 2.0 framework and higher, and both extensively documented and extendable, then it gets much easier.

Coming from a background that includes *nix, I’m very much used to having everything to be built into the sources, and all dependencies either automatically being resolved, or resolved through environment variables.

That is also the way to go with msbuild: it is in fact one of the really useful tips at the Embarcadero MSBuild Overview page.

In fact, Delphi contains a batch file that sets up the basic environment variables, for instance for Delphi XE5 it was:

C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\rsvars.bat

With this contents:

Properties

The broader msbuild concept here is “msbuild properties” which can be evaluated by surrounding them with $(). So $(PATH) inside an msbuild file gets you the PATH environment variable. Similar constructs exist for registry keys and properties passed through the commandline.

One of the things you will find in the root my repositories (for instance the root of the BeSharp.net repository) is a set of Dependencie. files that help resolving external references.

For open source libraries, they refer to the public repository urls, and the names for them used in environment variables.

The core is a dependencies.bat that sets environment variables, and can clone/fetch/update external repositories it depends on.

Then usually there is a batch file to start either Delphi with those environment variables et, or start Visual Studio with those environment variables set.

Without running those, Delphi will complain it cannot find external dependencies: since the environment variables are not set, the path will not resolve and you will get simple path not found errors.

Separate build and development machine

The ultimate place to check if you got dependencies, batch files and msbuild files right is to separate your build machine from your development machine.

There is a really cool post how to do that with Continua: VSoft Technologies Blogs | Building Delphi projects with Continua CI.

–jeroen

via: Don’t publish your .dproj/.groupproj – DelphiTools.