m53rd

@Rick Brewster, you're the best! The different REINSTALLMODE worked great for me, too. Come to think of it, I believe I once observed that you were using something different than the typical "amus," but as Paint.NET always seemed to work fine, I never gave it much thought. Despite your frustrations with it, I hope you do stick with MSIs (or at least offer an MSI version), as they really do make it quite convenient from a patch management perspective. Thanks for all of your work on this!

Well, I certainly don't mean to sound ungrateful by reporting that it doesn't seem to work! I did some additional tests and made some observations. Hopefully something in here will prove useful in tracking down the problem. We have three separate computer images that all give the error on startup that @stevenv documents after an upgrade to 4.2.9. All images have only ever had the MSI version installed. As stevenv also reports, it doesn't matter if you upgrade the 4.2.8 install with the MSI or with the EXE; you get the same error. Here are some tests: Run the repair as requested. Result: the files in the error message are updated with new date modified dates. They have different files sizes. The program then works. Manually remove the c:\program files\paint.net folder and then run the installer. Result: a full set of files is installed and the program works. Various hacks at the MSI file, such as playing with the conditions (i.e. remove "NOT installed" where it is used), playing with the sequencing (changing when RemoveExistingProduct and RemoveFiles happens), and explicitly adding TARGETDIR as a folder to remove. Result: with the MSIs that still agreed to run after I was done with my hacking, I generally ended up with an install that was completely missing the files mentioned in the error message. Of course, the program gave the error message in this case. I'll stop playing at this juncture unless there's something specific that the author would like me to try.

Same problem over here with the /createmsi flag. Glad I'm not alone 🙂

You are awesome! I will try this with your next update. Have a great weekend!

Hi Rick, Thanks for getting back to me. I see I've left out a few key details. I work at a library and I manage the updates on our public-use machines. I prepare most of the updates to go out from my work computer, where my user account doesn't have admin rights. It turns out that you can create and edit MSIs with a freeware product without needing admin rights. So I can package a Firefox MSI, for example, and upload it to our update server, even though the MSI wouldn't run on my machine. With Paint.NET, the installer does create %TEMP%\PdnSetup before it fails for lack of admin rights (at least on my machine!), allowing me to grab the MSI before I close it out. If I know what changes need to be made to the MSI, I can make them with my freeware tool and upload the update to my server without leaving my desk. If I need to rely on a something that requires admin rights, then I have to move to my test machine and run that there. Does that make a little more sense? --Francis

If you start the Paint.NET setup process and then go to the installer's temp folder, you find this interesting read me: I'm certainly familiar with the official instructions listed on that page. I'm just wondering if the /createMsi does anything other than add rows to the Property table. If so, I'd rather automate that myself than truck the installer over to a machine where I have admin rights just to have it create the MSIs. The only property whose value may be hard to predict is LASTACCEPTEDEULAVERSION, but that doesn't appear to change too often. Alternatively, I'd like to see the /createMsi switch NOT require admin rights, since I'm not actually installing anything.