Invalid program version in Paint.NET v3.5.10?

[StephanP]

I use SUMo (Software Updates Monitor) to regularly scan for new versions of my programs.

With PdN 3.5.10, SUMo fires an error message: "Empty / Invalid version", which - I assume - implies that it cannot find the version number in the executable.

Could it be that the version numbering in the paint.dot.net.exe has gone gaga?

I'll report this with the producer of SUMo as well, in case there is something to do on his side.

Stephan

Edited October 11, 2011 by StephanP

[Rick Brewster]

I have no idea. Sounds like a Sumo problem.

If you want to keep Paint.NET up-to-date, then just use Paint.NET's built-in updater. Problem solved.

[KyleKatarn]

Sorry, no known limitation in SUMo so far.

Paint.Net page in SUMo shows that nothing is reported above v3.59 : http://www.kcsoftwares.com/sumo/view.php?ProductName=Paint.NET&Company=dotPDN+LLC

I'll investigate... would you accept to do the same on your side ?

Kyle

[KyleKatarn]

Root cause found !

It comes from the versionning system used by Paint.NET : v3.5.9 is identified as v3.59.

Therefore v3.5.10 is identified as v3.510 and rejected by SUMo due the following limitation in SUMo : http://www.kcsoftwares.com/bugs/view.php?id=542

Any chance to get PdN using a more straight forward version identification in coming versions ?

No workaround at SUMo level because 3.510 could be 3.5.10 or 3.51.0...

[Rick Brewster]

Sorry, that's the way Paint.NET does its versioning. Version "N+1" must have a numerically higher version than "N", and the 3.5.x scheme has to combine the 5 and the x into the 2nd version field.

If they want, they can enter it into their system as 3.60 or something. That's actually how I had to stamp the MSI for 3.5.10, because apparently MSI only allows 2 digits in the 2nd field.

And really, to keep Paint.NET up-to-date, you should just use the Paint.NET updater. That's what it's there for! I can't see much advantage to using an external update manager for Paint.NET.

[KyleKatarn]

I'm the developper of SUMo and i don't see any other solution than applying a specific processing for your product, splitting the 2nd digit in two : 1st digit appart and the rest.

But this won't work if you intend to use same versionning for 3.10.2 (3.102 -> 3.1.02 -> wrong detectino !)

Using an external update manager make sense since it allows to detect that an update is available BEFORE you need to use your software.

Changing the way you tag version would help both MSI and SUMo issues. Thanks !

[Rick Brewster]

Sorry but I won't be changing Paint.NET's versioning scheme.

v3.5.10 stamps its version as 3.510.*.*. If there's a v3.5.11, then it will stamp itself as v3.511.*.*.

In fact, it wouldn't be possible for me to do this because it would break my updater: 3.510.*.* will look for updates whose version fields are greater than v3.510, and won't offer anything to the user unless it finds one like that. If I were to release a v3.6, then I would have to stamp it as v3.600.*.*.

(As an aside, each field of the version is compared separately. 3.6.*.* is not greater than 3.5999.*.* and 3.6.*.* is not equivalent to 3.600.*.*.)

Seems to me like SUMo should simply fix its bug! Alternately, ignore the 2nd field and only use the 3rd. The 3rd field will always be the number of days since January 1st, 2000. The fourth field is the number of seconds since midnight, divided by 2, so it can't be used without the 3rd field in order to provide temporal ordering of updates.

[KyleKatarn]

Sorry but I won't be changing Paint.NET's versioning scheme.

v3.5.10 stamps its version as 3.510.*.*. If there's a v3.5.11, then it will stamp itself as v3.511.*.*.

In fact, it wouldn't be possible for me to do this because it would break my updater: 3.510.*.* will look for updates whose version fields are greater than v3.510, and won't offer anything to the user unless it finds one like that. If I were to release a v3.6, then I would have to stamp it as v3.600.*.*.

(As an aside, each field of the version is compared separately. 3.6.*.* is not greater than 3.5999.*.* and 3.6.*.* is not equivalent to 3.600.*.*.)

Seems to me like SUMo should simply fix its bug! Alternately, ignore the 2nd field and only use the 3rd. The 3rd field will always be the number of days since January 1st, 2000. The fourth field is the number of seconds since midnight, divided by 2, so it can't be used without the 3rd field in order to provide temporal ordering of updates.

I'll find a specific workaround then... http://www.kcsoftwares.com/bugs/view.php?id=1387

Btw how would your update deal with v3.11.0 (=3.110) if you previously released a 3.1.11 (=3.111 > 110 !!)

I'd have suggested to use revision number (4th digit) to do the trick...

[Rick Brewster]

No no no don't use the 4th digit ... the "revision" wraps around every day.

A quick set of definitions:

* File version. This is the version that's stamped into the files, and what's seen programmatically, and what you're used to.

* Application version (aka "marketing version" I suppose). This is the "prettied-up" file version. "3.510.*.*" is printed as 3.5.10. It only exists, so to speak, as part of what's displayed on-screen for the end-user, and what's shown on the website. Programmatically speaking it doesn't exist. It is never printed alongside the Build or Revision. (e.g. you'll never see 3.5.10.4297.28964).

You want the file version's "build" field, the 3rd one.

Major.Minor.Build.Revision

"Build" increments by 1 every day, and equals the number of days since January 1st 2000. "Revision" is the number of seconds since midnight, divided by 2 (I think it's based on UTC but I'm not sure). Heck, you can use this to determine the date and time that I pressed "build" in Visual Studio, if you really want to, and it's what Paint.NET uses to handle it's expiration logic for pre-release versions.

public static DateTime BuildTime
{
   get
   {
       Version version = PdnInfo.Version;

       DateTime time = new DateTime(2000, 1, 1, 0, 0, 0);
       time = time.AddDays(version.Build);
       time = time.AddSeconds(version.Revision * 2);

       return time;
   }
}

You can depend on Build and Revision always following these definitions. I won't be changing that, and you can count on it.

Also, I noticed you mentioned something about the registry in your link ( http://www.kcsoftwares.com/bugs/view.php?id=1387 ). Paint.NET doesn't publish its version into the registry.

If you need to know where Paint.NET is installed, you can use HKEY_LOCAL_MACHINE \ Software \ Paint.NET \ TARGETDIR . From the directory listed, grab PaintDotNet.exe and query its file version. That's the only supported way of programmatically querying Paint.NET's version.

[Rick Brewster]

Also, I'd be careful of only ever using the 3rd / Build field.

Let's say I release an alpha of 4.0, let's call it 4.0.4600.1. And then I release a bugfix update for 3.5 a week later, let's call it 3.511.4607.2. You wouldn't want to install 4.0.4600.1 and then a week later install 3.511.4607.2.

Also, there's the possibility that after 4.0 is finished ("final") that there will be updates for the 3.5 line. 4.0 will require Win7, and I'll need to keep 3.5 available for awhile afterward in order to support XP/Vista users. If there's a need for a critical security fix, then there could be a 3.5 update with a higher Build field than the newest 4.0 build. I hope this won't be necessary but it's a possibility.

Example: 4.0.4700.1 "final" released on January 1st, 2012*. Then, 3.511.4707.2 released on January 8th, 2012.

However in this case, if you support OS targeting then you can split Paint.NET into separate "3.5" and "4.0" listings. (assuming that makes sense for your system, which I'm admittedly not deeply familiar with)

* I'm making this up for the sake of example. This is not an announcement of 4.0's release date

[KyleKatarn]

I've found an acceptable workaround by extracting the version from the product name (and not product version) from the registry (install section) AND adding the 3'rd digit from main exe file version properties.

Therefore, in next release of SUMo, Paint.NET will appear as 3.5.10.4297.

Is this satisfactory for everyone ?

[Rick Brewster]

Why are you pulling anything from the registry? I just gave you everything you need to know about Paint.NET versioning and detection, which certainly doesnt include manually parsing the product name in the MSI catalog.

But whatever. As long as it works, it's really of no consequence to me.