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.
Related
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.
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 am debugging a bpg with multiple dll's. Can someone tell me why my breakpoints, that DO work, eventually stop working? The only way to get them back is to do a build all in my project group file (BPG file in Delphi 6)?
I have looked at several other posts, but have not had much luck getting an answer to this specific question. Again, I can successfully debug, all dll's in the BPG provided I do a build all. Doing a build all every time is taking too long.
I am using Delphi6 in WinXP.
Thank you
In Delphi 6, such a failure to find debug information (all the blue lines are gone from your sources) that is solved by a complete rebuild is usually a symptom that you have to examine your project (.dpr) settings. For each project (dll or exe) make sure a different unique compiler output folder (DCU output folder) is used.
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.