I am challenged with creating an automated release for a legacy Delphi (Delphi 2006) project.
I am a complete Delphi noob. So my question is maybe heading in a wrong direction ...
As far as I understood the release process of the given project it works like this:
A developer opens the project in Delphi Studio
Right-Click on the Project -> Properties -> Version Info
He sets the new version number of the next release in the Dialog.
He saves the project. This automatically generates the corresponding .resx file which contains the version number in binary form.
The .bsproj and the the .resx are checked in into source control
The automated build (Hudson) picks up the change and builds the release.
I would like to automate this process, since there are several projects that needs to get a new version number for each release.
I guess I could easily manipulate the .bsproj with a custom tool since it is xml.
However I am struggling with the generation of the .resx file which is currently done when saving the project in Delphi Studio.
Is there a way to automate the generation of the .resx? i.e. with a commandline-tool or something similar?
Or is there a smarter approach?
Any help is appreciated.
You can do it all in a batch file
Update the version numbers as specified in this SO question: change version number at build time
Use the DCC command-line compiler to build all the projects. There's plenty of documentation for that, basically you do just dcc32 <project>.dpr
DCC is e.g. documented here or here
I do wonder where your .resx files come from, but they can be converted as well. See this SO post.
Give it a go using these resources and for specific issues write a new SO question with your attempts so far.
Related
We have a software package which is about 16 years old. It's gone through just about every version of Delphi (besides .NET ones). Over the years, things have become very confusing when it comes to cross-referencing and keeping proper setup for additional packages (like third-party libraries). I was wondering if there is some standard practice when it comes to keeping large projects (and groups of projects) like this organized.
So to explain the current setup...
This is a multi-application system. Meaning, there are 12 executable projects (and a few DLL and service projects) involved. We also keep things in SourceSafe and multiple developers work on the same code on different computers. All of these projects are more-so dumped into a central folder. The "Root" folder contains THE major EXE project (along with about 20 folders, all containing units and forms) and it almost seems like an endless hierarchy of folders and files. This one project alone has half a million lines of code involved.
Then all the additional applications aren't necessarily separated properly from this major project. Each of these projects has its own folder based in the main project's root.
The two major concerns of mine are:
How to properly set up the DCU files so that they aren't mixed in with the projects? DCU's should NOT be placed in the SourceSafe (and any similar file, for that matter) or otherwise, any file compiled from the project. Visual SourceSafe makes files read-only when they're not checked out, and DCU files (and EXE files and more) cannot be written to in this case. So how to properly separate any of such file to a remote location to avoid any mixture with the source code?
How to properly set up packages and libraries? We have the following:
QuickReports 5.05
NativeJpg library V302 -
Another anonymous reporting library
Our own component package, which requires QuickReports, NativeJpg, and the other anonymous library
All 4 of those libraries are stored in completely different places of each computer, and need some centralization. The biggest pain of setting up each new developer's computer is locating these from the lead developer's computer and copying them to the same place on each other computer (and making sure the library path is correct, etc.).
We also need to keep completely separate environments for different versions of Delphi on the same computer. This means a copy of the projects on each computer, a copy of packages and libraries on each computer, a copy of the projects and packages and libraries in the SourceSafe, etc. Each computer needs to have an identical setup. We already utilize environment variables to direct our projects where to look for certain project files (and libraries).
Another new concern: XE2 introduces 64bit capabilities. We don't plan on 64bit compiling yet, but we certainly will in the future. How do I properly differentiate 32bit from 64bit in all these projects?
What I'm really asking for is a reference to a good tutorial on how to optimize such an environment and keep it organized the best. I don't expect anyone to take the time and answer all this in the question. The projects are over 15 years old, have had the hands of 200+ developers from around the world in it, and has a LOT of cross-referencing between projects. For example, one project may use a unit from another project, and vice-versa. I personally don't like this concept, but I also didn't design it to begin with. I've been given the task to get this system organized and thoroughly documented how to set up Delphi on a new computer for new developers to work on our projects. As I'm looking at our projects (as I'm not necessarily a developer of the system, but am being pulled into development), I'm seeing a lot of confusion in how the code is organized.
I am assuming that possibly Embarcadero has some guidelines and standards on setting up such an environment?
Location of DCU files
Regarding the DCUs that are the output of the compilation process, you should specify a DCU output directory in each project file. The default value for this, in the latest version of Delphi would be fine: .\$(Platform)\$(Config). This results in sub-folders of the project directory like this: Win32\DEBUG or Win64\RELEASE.
If you set-up your project files using option sets then you will be able to control this setting (and all others) from a small number of option files.
Location of 3rd party code
You should always use 3rd party library as code. If the vendor charges more to receive the library as code, pay up. Once you have done so you simply include the source code into your version control system (VCS) and treat it largely the same way as you treat your own code. I say largely because you should avoid modifying it.
Once you have all your code in the VCS then you can put the entire source code onto a new machine with a single checkout operation.
Organisation of your projects
I personally have a strong aversion to using compiler search paths. I don't use them and include every unit that is required in a project in the .dpr file.
If you do use search paths then you make it impossible to work on variant projects.So for example, suppose you have a client that has discovered a bug in the version of the software you released 2 years ago. You would like to address that bug by releasing an upgrade to the 2 year old version of the software. It is perfectly plausible that asking them to upgrade to the latest version is not viable. Perhaps they have not paid for the upgrades. Perhaps the full upgrade has breaking changes that they do not want to tackle right now. A perfect example would be all the Delphi developers still using Delphi 7.
Now, having motivated the scenario, how would you create a build environment for the 2 year old project? If you are using search paths then they will refer to today's libraries. You would be forced to change your search path, or copy the old libraries over the top of today's libraries.
That entire headache is trivially side-stepped by not using search paths and by including all your source in the VCS.
What you should be aiming for is to be able to checkout any historic version of your program and have it build immediately. You should be able to do this with full confidence that you are building identical software to what was built at the time that version was released. This also requires you to have build automation but I can't imagine you are lacking that for a project of this size.
I'll address folder organisation. This comes from a software suite which has 50+ exe's and dll's and plenty third party libraries, so I guess I know where you are coming from...
We use Perforce as a source control system, so my default workspace's root folder is called Perforce, but I also have a couple of other workspaces set up and they are in Perforce2, Perforce3, etc.
General folder setup (starting from the workspace root folder)
General
Components
Delphi
Indy
Indy9
Indy10
MadCollection
v2.5.8.0
v2.6.0.0
Plugins
Releases
Released
... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
Acceptance
Sub1
Sub2
My Environment library path in the IDE is empty (not even the BDE standard paths are in there). This ensures that a project's paths declare all path's needed and that projects are not reliant upon a particular machine's IDE setup.
We have an environment var (ie MRJ) set up in our IDE's that points to "General\Components\Delphi" so in a project's options we declare the paths to our components as $(MRJ)\MadCollection\2.6.0.0.
General holds IDE plugins and components used by our projects. We keep all versions we use in source control. That way when I have to switch back to an old release to track down a problem, I can simply pull it and build it as its library paths will still point to the version of the components that this specific release needs.
The organisation of folders in a particular work branch (Acceptance or one of its subbranches) follows this pattern:
General
Includes
MainComponent1
Project1
Project2
Shared
MainComponent2
Project3
Project4
Shared
Shared
Windows
SoftwareSuite
Scripts
Tools
MainComponent1
Project1
Dcus
Project2
Dcus
MainComponent2
Tools
Tool1
Dcus
Tool2
Dcus
The General folder holds all platform independent sources/files, the Windows folder holds all Windows specific files. Each component can hold multiple projects and will have a share folder for sources shared between those projects. The shared folder directly under General holds sources shared by all projects. The Windows folder is set up in a similar manner.
Note that each project has its own dcus folder. This is configured in the project options. As the path can be entered as .dcus, we (at least I) have this set up as the default for any new project. Each project sending its dcus to a unique folder ensures two things:
it is easy to keep dcu's out of version control by simply setting up a filter in your version control software.
more importantly it ensures that compilation/build of a project never interferes with the compilation/build of another project. I can safely change settings and build knowing that I won't be bothered by dcu's lying around from a previous build from another project.
I recommend the following practices:
Keep your library path simple, and make sure everything in the library path is either a folder that ships with delphi, or a DCU binary (library) folder in your d:\Components\ folder.
Use a MODERN type of version control. I recommend Mercurial over others. Source Safe is crap, stop using it.
Back up your environment (export registry keys etc) and restore it to the other developer PCs in a standardized way. You can keep a few .reg and .cmd (batch) files around to automate setup of a new system. you can put these scripts in your component repository in your version control system.
Outside the scope that was largely discuss before, I would recommend :
Unit testing - with DUnit for example
Continuous integration. Just to be sure that all these projects can compile on another machine and that tests are ok.
So this is heavily related to project organization and VCS strategy.
For a similar setup, a company I worked for found this configuration useful:
all third party libraries (components etc.) go to a fixed location (C:\Delphi\name-version)
Delphi projects can be checked out from version control anywhere (drive C: or D: and folder name does not matter), as all projects and scripts use relative paths
all projects are sub folders of one main project folder so checking out this one will bring the Delphi projects and other relevant resources to the workstation, and a version control update is easy to do
we use a build script (written in Apache Ant) which sits in the main folder, and iterates over all folders to build the Delphi apps and run unit and integration tests against a development database server, to verify all changes work before checking in to source control
the build script can also be run automatically on a build server (Hudson CI) on every commit to see if something broke
And a note about component libraries: avoid package installation where possible, prefer creation of components at run time. If you quickly need to apply a fix to a five year old version of a project, uninstalling / installing a dozen of packages can become frustrating. At least for non-visual components, run-time creation is a huge time saver.
Checking in third party code in source control can be very helpful, for example to share fixes which are not yet available as new official releases. Best practices are covered in the Subversion documentation chapter Vendor Branches.
Plus, with Subversion you can use svn:externals to place a specific version (tag) right into a project directory structure. This can be used both with third party library and with your own source code, and makes dependency management easier and workstation setup easier.
p.s. the Ant build script defines the search paths for everything, so it is 'the reference' for all developers how to configure the IDE, where to put the third party libs and which compiler flags to use
p.p.s. your project sounds like a lot of fun - I am open for contract work :)
My team use virtualization and when we see back it was a real good move.
We use MacBook Pro laptops and VmWare Fusion, but I'm sure other packages work fine as well like VirtualBox or VirtualPC.
It is always a good feeling to know that when a new developer starts or an old installation got trouble it is just to copy a new VM image from the master image and the setup is exactly as the original. The master image is stored on a fast USB2-disk. Now when Thunderbolt and USB3 is coming it would be even faster to copy an image. And there is no real concern about performance on a modern computer as long as there is memory. 8 GB should be enough to run 2 images in parallell. Another advantage of virtualization is that it is so easy to try What if scenario. Experiment with different configuarations and versions without any risk to disturb the real working environment.
Btw I also think that SourceSafe is crap... :-)
Somé tips:
Make one groupproject file for all the apps belonging to the project, each app in its own dir under the groupproj file
You should be able to specify which file types to include into your version control system. Make sure you set Delphi to write DFM files in text format.
You could tell Delphi to output DCUs in subdirs named 'dcu' under each app (less visaul clutter).
Third party stuff often insists on installing in distinct locations, there's not much you can do about it. Make a document describing how to setup a complete working environment and keep it up-to-date
Develop in virtual machines. A new developer gets a copy of the VM.
Maintaining for different Delphi versions? Rethink that, try to go to one version. If you absolutely must have two groupprojects and directory structures for each version. [I'm assuming you're not compiling the same app with two Delphi version, that's developer hell]
Delphi XE2 will output to different 32/64 subdirectories, that should give no problems.
I am migrating projects from XE to XE2 and I have noticed that I am missing my manually entered version information such as Company Name, Product Version etc. Creating a simple empty VCL forms applications I see that data typed in for version info under 'All configurations - All Platforms' disappears when you then select for example 'Release configuration - 32-bit Windows platform'. I guess I can go through the platforms re-entering my info but what is going on here? One would expect the 'All configurations - All Platforms' info to propagate across all platforms unless overriden, just like compiler options etc, or am I missing something?
Further note - As I investigate further, I see that there is a work around using DDevExtensions which adds a menu option under 'Project'. If you check the boxes at the bottom 'Apply to Selected' and 'Apply VersionInfo to all platforms' then you can get the displayed version info copied to all platforms without affecting the other projects in your group.
This is still an issue in build #16.0.4429.46931. However, I found that I can eliminate the problem by opening the project's "dproj" file and delete all of the <VerInfo_Keys> elements except for the base property group (<PropertyGroup Condition="'$(Base)'!=''">). Doing this allows the "All configurations - All platforms" version information to be inherited to the different build and platform configurations without any need to duplicate.
It seems to be a bug in XE2 that causes version info not to be propagated from higher to lower levels. The QC I opened on this issue (99428) was closed on 7th November and marked as "resolved in build 16.0.4256.43595".
For production use (when we switch to XE2), I will be using FinalBuilder to get the version info correct, but I await the fix, hopefully in the next month or so, in order to get IDE builds to match the real versioning from FB. But in the mean time I will try your suggestion of using the fix pack...
I believe there is a ‘bug’ in the version information stuff where its putting multiple version configurations into the .djproj file in the project folder.
It seems to be ok if you change the Target to ALL Configurations the very first time you open it up in Delphi XE2. Then once it has loaded drop down the target and click only on the bold entries to copy down the version info. If you accidentally click on a non bold entry the text is set to the default and is made permanent in the .dsproj file.
I have fixed this by doing the following - you will need to mod the details as necessary I suggest you just look at the file first - it is usually obvious what it happening.
1) Copy the project .dsproj file then Open the projects .dsproj file in notepad
2) Locate the first occurance of it will be around line 40.
3) Copy and paste this bit above it.
<PropertyGroup Condition="'$(Base)'!=''">
<DCC_ExeOutput>**c:\xxx**</DCC_ExeOutput>
<VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo>
<VerInfo_Locale>2057</VerInfo_Locale>
<Manifest_File>$(BDS)\bin\default_app.manifest</Manifest_File>
<VerInfo_AutoGenVersion>true</VerInfo_AutoGenVersion>
<VerInfo_MinorVer>12</VerInfo_MinorVer>
<Icon_MainIcon>**My_Icon.ico**</Icon_MainIcon>
<VerInfo_Release>1</VerInfo_Release>
<VerInfo_MajorVer>5</VerInfo_MajorVer><DCC_Namespace>Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell;System;Xml;Data;Datasnap;Web;Soap;Winapi;Data.Win;System.Win;Bde;$(DCC_Namespace)</DCC_Namespace>
<VerInfo_Keys>CompanyName=xxxxxxx;
FileDescription=**xxxxxxxx**;
FileVersion=5.12.1.0;
InternalName=;
LegalCopyright=2012 xxxxxx Services;LegalTrademarks=**xxxx**;
OriginalFilename=;
ProductName=**xxxx**;
ProductVersion=5.0;
Comments=</VerInfo_Keys>
</PropertyGroup>
4) Replace the starred entries with the information from further down in the file– if you cant find the icon you will need to add it again although I have found that in most of my projects it is in the folder as a separate .ico
5) You can then remove all the other original property group entries right down to :
<ProjectExtensions>
<Borland.Personality>Delphi.Personality.12</Borland.Personality>
<Borland.ProjectType/>
<BorlandProject>
"The QC I opened on this issue (99428) was closed on 7th November and marked as "resolved in build 16.0.4256.43595".
Alas this is not fixed as of the latest version 16.0.4358.45540
If you migrate a project from an earlier version of Delphi, it'll create version resources at 'All configurations' level containing the copy of the older configuration. This is good.
It'll proceed to completely ignore it - this is really really bad. We didn't notice until quite late in testing that all our executable files were being built with no copyright and trademark information - it was simply being ignored.
The only solution is to hand edit all the dproj files as above. Really it needs someone to write a tool to fix this.. it's fairly mechanical & I wish I had the time.
FinalBuilder sounds nice, but $3.5k for a license on top of the $2k per developer for XE2 would give our accountant a heart attack...
I've created an application, which will remove child build config version info after conversion...
When I open an old project I then close it and run the tool.
This will ensure the version info to be properly inherited (Update 4 does not resolve this).
I use Project Options / Version to manage the version info (N.N.N.N format).
Anyway inside my project I duplicate those info.
So if in project options I am working on release 2.4.3.178
inside my application I have 4 integer variables that hold the 4 numbers.
I manually set them
Major := 2;
Minor := 4;
Release := 3;
Build := 178;
The reason of this is simple: I have licensing based on version number. So if the user buys release "2.4" it is not allowed to upgrade to version "3.0".
But if I rely on project version info the user can (with Resource Hacker tools) change the version info and therefore "activate" the product.
The user cannot change the 4 variables in the same way (not as easily at least).
This works but forces me duplicate the info.
Could you suggest a better approach?
Otherwise said: is there a way to write the version info using the data I write in those 4 variables. Something like in Post Build Events, but how do I pass data to post build events?
You'd need a pre-build event rather than a post-build event since you'd want to get the .res file built before linking.
I do something very similar with a simple Perl script that reads an include file (.inc) containing constant declarations of the version numbers. I read them in using a regex and then create my .rc file which I pass to brcc32. It's all invoked as a pre-build action.
Since you're on Delphi-XE and have Final Builder, why don't you put it to good use and make your "final" build from it? It can give a very nice solution to the version number problem, and can do a lot more.
Here's how I'd do it.
Set up a small INI file that holds the relevant parts of the version information.
Optionally make a small Delphi forms application that reads the version number from the INI files and gives you a chance to change it. When changes are saved to the INI file, the delphi application should automatically generate a small Delphi PAS file that defines the constants!
Create a FinalBuilder project that does the following:
Calls your Delphi exe to set up version number. You'll be in charge of changing whatever needs changing, and this is probably appropriate since your licensing scheme depends on version information.
Set up a few project variables to hold the version information numbers
Add "Read INI file" actions to read the version information from the ini files into your project variables.
(optional) Build the unit test project, if you have one.
(optional) Call the unit test project.
Add a "build Delphi project" action, set it up to build your project using whatever options you need. Add a small "Before" script to set up the version information numbers to what you've got in the project variables you just read from the INI file.
(optional) create setup packages using whatever tool you use.
(optional) upload those setup packages to a website.
In other words, take the opportunity to start using Final Builder.
Moving your version numbers into code is also easy to get around.
One way to pass the information is to generate a version.rc file programmatically (you write a tiny build tool yourself using delphi or a scripting language of your choice), and link the resources to the program, instead of using the built in version-info feature.
Your question seems to be fundamentally a matter of preventing the user from modifying (easily) the version number once you have determined it.
So my suggestion is that you encrypt the version number and you use the encrypted version, instead of the version in the VersionInfo structure.
I have used DCPCRYPT for things like this. But if you hope to be hacker-proof let me just say this; Anything you can do, hackers can undo. If you want to be more secure, you will also need to tamper proof your whole application. There are commercial tamper proofing solutions but none work fabulously out of the box with Delphi.
I have started using MonoDevelop for F# on a Mac. It's pretty cool, except for the fact that it crashes quite a lot. One thing that is bothering me is that I can't change the order of the F# source files in a project. Is this possible? It will make organising projects a bit of a nightmare if it isn't.
Yes, you can reorder files. There is a special tab for doing that in project options (under the build tab).
Unfortunatelly, this cannot be done using the file browser (because MonoDevelop automatically sorts files by file name and there is no way to disable it).
Assuming you're using MonoDevelop 4.x and a recent version of F# Binding, you can drag and drop to move files into a correct order (no shortcut key supported yet).
Here is the original issue and the pull request if you're interested in (big thanks to Dave Thomas for implementing this).
As a last resort, you can open fsproj files in a text editor and rearrange xml nodes corresponding to source files.
I have a Delphi XE project and I'm trying to change the version number of the program before building it with MSBuild. Version number information is located in the DPROJ file but if I change these values the version number does not change. I think the reason for this is that when you change version number in the IDE, Delphi saves the changes to both DPROJ and RES files.
Is there a way to compile the RES file from the command line with the changes in DPROJ file? I found this question which suggested saving the version number in an INC file and including that to the project but this feels a bit more complex solution compared to just making changes in DPROJ.
shameless plug: http://www.dummzeuch.de/delphi/dzprepbuild/englisch.html
I ended up solving my problem with this answer. First I unchecked "Include version information in project" in Project Options and added VersionInformation.rc with dummy data. When my build batch file is executed, it generates the correct RC file and because that RC file is added in to the Delphi project, MSBuild uses the contained information for built executable.
I use FinalBuilder to handle the version info. Isn't the stripped version bundled with your Delphi? If not, it is definitely worth the money. Makes releasing a one click action.
Yes you are right. Delphi keeps the version number in both project file and resource file. Unfortunately, resource files' structure is a bit complicated so it is not easy to update programmatically. When I came across this need, I ended up using a tool "SetVersion.exe" which did the job for me. It might help you as well. See this link.
EDIT
Actually now I remember, I used a different tool named "ChangeRes.exe" and it worked smoothly (but it is not free). You can try both and see which one works for you.
Some years ago, I have writed a script to build and increment build number using ruby and rake. Very easy to use.
After the build, the script calls Inno Setup and generates a new installer.