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).
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.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
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.
I just installed Delphi 7 on a new Windows 7 pc.
Everything finally works, but every time I now encounter a breakpoint and press F7 or F8 to step further I get the ' Source has been modified. Rebuild ? ' question.
I never had that on other pc's.
Anyone know what is causing this prompt ?
I have 'Autosave : Editor files' and 'Project desktop' checked in the environment options, and I have CnPack installed.
UPDATE
When I prevent CnPack from loading ( when holding the shift key when starting Delphi 7, you get a form where you can disable all of the CnPack extensions ), the problems disappears.
So it's certainly one of their wizards.
Since there are a lot of them , I may not find which one immediatly.
But when I do, I will edit my question once more ...
Or if someone else finds it , please add you answer here.
Although this is like closing the barn door after the horse has escaped, I suggest you install both DDevExtensions and DelphiSpeedup. One or the other of these will suppress the prompt you're getting.
http://andy.jgknet.de/blog/ide-tools/
These are good tools for many other reasons too!
I found the culprit.
When CnPack installed : choose 'CnPack - IDE Enhancements settings - Version enhancements'.
When one of both of the check boxes in the form are checked ('Insert compile time into version info' and/or 'Auto-increment build number', the question of the modified source is asked every time you want to step through your source.
When the check boxes are cleared, no such question is asked.
Edit: To investigate if UAC/Administrator issues influence this:
Install Delphi 7 in the XP-Mode of
Windows 7 should solve this problem.
If not, be sure to run it as
Administrator, and disable UAC as the
answers to this question suggest.
The reason for this investigation is that UAC introduced two security tokens for an administrator: the first token has the 'normal user' role, the second the 'elevated user role'. Under some circumstances, the elevated role can influence the normal role, but not otherwise.
That didn't solve it, so something else must be changing your files.
Where are your files stored? Remote? Local? Which directory?
Download and install Process Monitor, then watch the files that Delphi thinks are modified.
Then look what other process tries to touch those files.
If the 'other processs' that changes the timestamp on the files is Delphi itself then:
Do you have 3rd party components and experts installed in Delphi?
If so, try to disable them one by one and see if the problem persists.
--jeroen
In the Delphi Project Properties dialog, there are settings for the "Product Version" and the "File Version". Can anyone explain the philosophical differences between the two?
The Product Version will be the version number of your whole application.
The File Version will be the version number of this component.
The two are usually in sync, but don't have to be. It would depend upon how modular your application was.
So for example you might have an application that's at version 2.3.4.0 (say), but one file reader component that's at version 5.6.7.0 as it was inherited from a different application and another at version 1.2.0.0 as it's a more recent addition.
Additionally, some components might not change between releases so theoretically they should remain at their original file version.
However, as this might well cause confusion (not least with the developer) about which file goes with which version of the product these numbers are often kept in sync.
Not all the files are to be changed when the product version changes.
E.g. you've written a dll implementing the core functionality that remains unchanged during following product version changes.
Product version is the version of the product the executable is a part of, like Firedox 3.5.2 - all files in the product should have the same version (for a given version, obviously). The file version is normally the version of the specific file, like the firefox executable, for example, without respect to the product. This doesn't seem to get used much.
In contrast to the file version the product version is not necessarily numerical. E.g. we use the pre-build scripts to set it to the current date. This way, we can easily check when an executable was built.