Jump to content
Sign in to follow this  
Mike Torrettinni

Anybody changing FileVersion directly in dproj file?

Recommended Posts

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?

Share this post


Link to post

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.
 

  • Like 1
  • Thanks 1

Share this post


Link to post

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


 

  • Like 2

Share this post


Link to post
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?

Share this post


Link to post

@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 by DPStano
  • Thanks 1

Share this post


Link to post
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?

  • Like 1

Share this post


Link to post

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!

Share this post


Link to post
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 by DPStano
  • Like 1

Share this post


Link to post

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.

image.thumb.png.7883cb2a09f836a60ab78d551e393f73.png

 

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

Edited by Clément
  • Like 1

Share this post


Link to post

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 by y2nd66
  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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 by Guest
removed a name

Share this post


Link to post
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? 

  • Like 2

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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 by Guest
typos

Share this post


Link to post
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.

  • Like 2

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×