Anybody changing FileVersion directly in dproj file?

[Mike Torrettinni 198]

I noticed TDprojParser class that changes FileVersion in dproj file.: https://blogs.embarcadero.com/change-dproj-file-and-product-version/

It seems to do a good job. Anybody using it?

 

I also noticed this thread about that people are using simple find/replace tools: https://en.delphipraxis.net/topic/4413-how-to-set-version-number-for-all-the-projects-in-a-project-group/

 

I know probably best option is creating .rc file, but if I opt for second-best, anybody ever found any issues with changing .dproj file while building projects?

[Lars Fosdal 1792]

I prefer to use a build server that deals with discovering code changes and performs the versioning.

We use Continua CI (which is free for personal use) to automatically start builds after a commit to GitHub, and FinalBuilder which deals with the finer details of configuring projects.

Continua can assign the same version number to any number of projects in the build configuration.
 

[Mike Torrettinni 198]

44 minutes ago, Lars Fosdal said:

 Continua CI

Thanks, but that's overkill for my needs.

 

[David Heffernan 2345]

For releases, do you build from the IDE?

[DPStano 15]

we have even hard rule to not commit dproj ... delphi modifies dproj without reason, and it's really annoying to resolve conflicts all the time, we created simple script in PowerShell that runs before build and creates resources with version info based on a custom comment in dpr

 

like

program Test;

{@FileVersion=2.0.0}
{@FileDescription=}
{@InternalName=}
{@Comments=}
{@CompanyName=}
{@LegalCopyright=}
{@LegalTrademarks=}
{@OriginalFilename=}
{@PrivateBuild=}
{@ProductName=@InternalName}
{@ProductVersion=@FileVersion}


uses

 

[Mike Torrettinni 198]

23 minutes ago, DPStano said:

we have even hard rule to not commit dproj ... delphi modifies dproj without reason, and it's really annoying to resolve conflicts all the time, we created simple script in PowerShell that runs before build and creates resources with version info based on a custom comment in dpr

 

like

program Test;

{@FileVersion=2.0.0}
{@FileDescription=}
{@InternalName=}
{@Comments=}
{@CompanyName=}
{@LegalCopyright=}
{@LegalTrademarks=}
{@OriginalFilename=}
{@PrivateBuild=}
{@ProductName=@InternalName}
{@ProductVersion=@FileVersion}


uses

 

I'm not sure what you are showing here... I'm not familiar with this syntax. Would you mind expanding on this?

[DPStano 15]

@Mike Torrettinni It's our own custom syntax to define version info without touching *.dproj, these lines are parsed by *.ps1 script called from prebuild event https://docwiki.embarcadero.com/RADStudio/Sydney/en/Creating_Build_Events that creates res file https://docwiki.embarcadero.com/RADStudio/Sydney/en/Resource_file_(Delphi) that is linked to project during the build.

Edited August 26, 2021 by DPStano

[Mike Torrettinni 198]

15 minutes ago, DPStano said:

 It's our own custom syntax to define version info without touching *.dproj, that lines are parsed by *.ps1 script

Aha, it creates .rc file. Why do you put it in .dpr, to keep it with the project so you know what version it built, right?

[Mike Torrettinni 198]

I never noticed corrupt .dproj file, but .dpr at least several times a year. Quick check in source control and restore, if needed.

 

I've been running builds with this new TDprojParser and all seems to work pretty good!

[DPStano 15]

1 hour ago, Mike Torrettinni said:

Aha, it creates .rc file. Why do you put it in .dpr, to keep it with the project so you know what version it built, right?

it's one of the reasons, next one is that xml(dproj) is one of the worst formats when you have to rebase branch and resolve conflict, and borland/embarcadero moved it to another level, delphi it is constantly changing dproj (switch to debug build -> dproj changes -> switch back and it changes even more, add a new file and you have like thousands new changes and so on) so we stripped all ballast(90%) from dproj and locked it for changes and we separated version info to own rc but version info section has to have the same encoding as defined inside https://docs.microsoft.com/en-us/windows/win32/menurc/stringfileinfo-block and we were constantly changing it from utf-8 to win1250 and back, fields like company name and the product description were almost always broken ... so we switched to simple powershell script that makes everything that we need in the right encoding all the time and it has to take version info from somewhere and dpr was good candidate for it couse it already contained header with similar info...

Edited August 26, 2021 by DPStano

[Clément 148]

I'm also using a custom solution. I found .DProj format very messy. Once I have my project version set I can't loose it. It messes my updates to sites and customer updates.
My solution generates a .RC and compiles it to .RES with data I store in a .INI file. The .RES is included in the .DPR manually only once.
My builds have the same information and the built number is incremented always correctly.

 

I run the "versioninfo interface" from the Tools menu. Very handy

Edited August 26, 2021 by Clément

[y2nd66 3]

I'm also using a custom solution.

  IOTAIDENotifier = interface(IOTANotifier)
    ['{E052204F-ECE9-11D1-AB19-00C04FB16FB3}']
    { This procedure is called for many various file operations within the
      IDE }
    procedure FileNotification(NotifyCode: TOTAFileNotification;
      const FileName: string; var Cancel: Boolean);
    { This function is called immediately before the compiler is invoked.
      Set Cancel to True to cancel the compile }
    procedure BeforeCompile(const Project: IOTAProject; var Cancel: Boolean); overload;
    { This procedure is called immediately following a compile.  Succeeded
      will be true if the compile was successful }
    procedure AfterCompile(Succeeded: Boolean); overload;
  end;

I set "Include version information in project" and "Do not change build number" for "All configurations - All platforms".

Then I manage the values for the compilations at the convenience of my personal settings.

Edited August 27, 2021 by y2nd66

[Mike Torrettinni 198]

On 8/26/2021 at 9:38 AM, Lars Fosdal said:

start builds after a commit to GitHub

Thanks for the idea, I was doing this manually, now automated!

[Fr0sT.Brutal 900]

18 hours ago, Clément said:

I found .DProj format very messy

Actually it's MSBuild's format so all WTF's should go to Micro$oft

[0x8000FFFF 22]

See also:

How to define application version in one place for multiple applications?

Delphi Version number central but other info decentral

 

[Guest]

Project management in the IDE is utterly broken. Quoting from another post.

I still do (build for prod in the IDE) but i have a hand-written checklist that i fastidiously follow each and every time.

It is painful, because sometimes i release several times a week. Edge cases more than one release per day.

Dangerous and bad is my analysis.

Edited September 4, 2021 by Guest
removed a name

[David Heffernan 2345]

33 minutes ago, Dany Marmur said:

I still do (build for prod in the IDE) but i have a hand-written checklist that i fastidiously follow each and every time.

Why wouldn't you automate the build? 

[Uwe Raabe 2057]

1 hour ago, Dany Marmur said:

I still do (build for prod in the IDE) but i have a hand-written checklist that i fastidiously follow each and every time.

I learned that creating a separate build project is mandatory even for small and/or short lived projects. Alone that it just gives the customer a professional experience when you are able to fix a bug and provide a new setup for download in a few minutes just by committing and pushing the changes.

[Guest]

2 hours ago, David Heffernan said:

Why wouldn't you automate the build?

Because i run a one-man shop. If i adhere to all best practices everywhere that would be the only thing i would have time to do.

It will come, but it will come when i have the time to allocate mental capacity.

Basically my non-technical problem is this: https://xkcd.com/1319/

So before i start to wrap my head around the alternatives, i cannot know if it will be the time-save that i need.

Wrapping my head around the intricacies might even cost me more (in hours/mental juice) even if i find a good solution.

So /my/ problem description is all but technical and actually, OT in this thread, apologies for that.

[Mike Torrettinni 198]

2 minutes ago, Dany Marmur said:

So before i start to wrap my head around the alternatives, i cannot know if it will be the time-save that i need.

That's why I gave up on .rc file, after 2h I couldn't make it work on new empty project, so I can't imagine it's worth investing time for all my projects, because I'm sure each of them will have it's own little quirk and valid reason why it's not working.

 

Setting version in .dproj file on build and commit worked out of the box and every time, since.

[Attila Kovacs 629]

setting the version is just one thing in the build process... there are so many other things you can automate.. even with just some shellscripts

[Uwe Raabe 2057]

24 minutes ago, Dany Marmur said:

Because i run a one-man shop.

So do I 

[Guest]

1 hour ago, Uwe Raabe said:

Alone that it just gives the customer a professional experience when you are able to fix a bug and provide a new setup for download in a few minutes just by committing and pushing the changes.

I can and do do that. And it's 10 minutes QC. Not a huge problem (yet). When it becomes a problem, i will solve it. That is my live "in a nutshell", solving problems for myself and my clients. Even for my friends. But in order to "stay on top of things" i need to have serious pipeline. Nothing more, nothing less. As much respect as i have for you and your posts, i'm sure there are stuff you struggle with that i got pinned down some 20 years ago. Or not.

 

Anyhow, i am so OT. I'll stop now.

Edited September 4, 2021 by Guest
typos

[dummzeuch 1505]

39 minutes ago, Dany Marmur said:

Because i run a one-man shop. If i adhere to all best practices everywhere that would be the only thing i would have time to do.

It will come, but it will come when i have the time to allocate mental capacity.

Basically my non-technical problem is this: https://xkcd.com/1319/

So before i start to wrap my head around the alternatives, i cannot know if it will be the time-save that i need.

Wrapping my head around the intricacies might even cost me more (in hours/mental juice) even if i find a good solution.

So /my/ problem description is all but technical and actually, OT in this thread, apologies for that.

I think you overestimate the complexity of an automated build:

• Have a release configuration in the IDE
• Build from command line.

That's it. You can always add more to the automation but the command line build is a good starting gpoint.