[SOLVED] MSI deployment of 4.2.9, missing DLLs prompting "repair" and reboot (MSI, AD/GPO, /createMsi) (consolidated thread)

[stevenv]

Edit by Rick 1: I've split this conversation out of the 4.2.9 announcement post so it can have its own dedicated thread

 

Edit by Rick 2: See fix below, along with explanation: https://forums.getpaint.net/topic/115940-msi-deployment-of-429-missing-dlls-prompting-repair-and-reboot-msi-adgpo-createmsi-consolidated-thread/?do=findComment&comment=567994

 

I'm using the classic release. After installing 4.2.9 over 4.2.8, I get this error on first launch:
 

Quote

paint net has detected that some important installation files are missing. If you click the Repair button it will attempt to repair this and then continue loading.

 

The missing files are: System.Collections.Concurrent.d11. System.Collections.d11. System.ComponentModel.d11. System.ComponentModel.EventBasedAsync.d11. System.Diagnostics.Contracts.d11. System.Diagnostics.Debug.d11. System.Diagnostics.Tools.dll. System.Diagnostics.Tracing.dll. System.Dynamic.Runtime.dll. System.Globalization.dll. System.10.Compression.d11. System.10.d11. System.Ling.d11. Systemling.Expressions.d11. System.Ling.Parallel.d11. System.Ling.Queryable.d11. System.Net.Http.d11. System.Net.NetworkInfoimation.d11. System.Net.Piimitives.d11. System.Net.Reguests.d11. System.Net.WebHeaderCollection.d11. System.ObjectModel.d11. System.Reflection.d11. System.Reflection.E4ensions.d11. System.Reflection.Piimitives.d11. System.Resources.ResourceManager.d11. System.Runtime.d11. System.Runtime.Extensions.d11. System.Runtime.Handles.d11. System.RuntimeinteropServices.d11. System.Runtime.Numerics.dll. System.Runtime.Serialization.Json.dll. System.Runtime.Serialization.Primitives.dll. System.Runtime.Senalization.Xml.d11. System.Security.Principal.dll. System.Text.Encoding.dll. System.Text.Encoding.Extensions.dll. System.Text.RegularExpressions.dll. System.Threading.dll. System.Threading.Tasks.dll. System.Threading.Tasks.Parallel.dll. System.Threading.Timer.dll. System.Xml.ReaderWriter.dll. System.Xml.XDocument.d11. System.Xml.XmlSenalizer.d11

 

I've tested on at least 3 computers and they all get the same behavior. It looks like if I manually uninstall the older version first, it works fine. It also looks like running the repair fixes it. However, that's not an acceptable work around because I need to deploy this to users who don't have local administrative permissions.

[Rick Brewster]

@stevenv You're using the MSI deployment method with /createMsi? 

[stevenv]

@Rick Brewster Yes, but I also tested with a manual install using the exe and got the same results.

[Ard]

I have the same issue, created the MSI files with /createmsi and tried on two computers to upgrade from 4.2.8 and it displays the above error. After that you can repair but this is not working if we do a deployment on our student computers.

 

Edited February 5, 2020 by Ard

[m53rd]

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

[m53rd]

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.

[BoltBait]

2 hours ago, m53rd said:

 

Well, I certainly don't mean to sound ungrateful by reporting that it doesn't seem to work!

 

Bug reports are ALWAYS welcome. 

[Rick Brewster]

For @m53rd, @Ard, @stevenv, have you been doing some kind of MSI upgrade process?

 

Paint.NET's UI installer only ever does an uninstall followed by an install (of the MSI, I mean) -- there isn't actually any update/upgrade process. It's definitely best if you always uninstall and then install.

 

I don't know why this is happening, but it's a symptom of adding a verification process to app startup, which was added because of random crashes I've been getting. The crashes were happening because files weren't being updated and they were the old versions. MSI is just a very brittle technology unfortunately, I'd really like to replace it completely with something like APPX or MSIX.

 

I am listening to the reports on this and taking notes. I'm just not sure what to do about it at the moment!

[stevenv]

I just did a couple tests. I uninstalled Paint.net completely between each test. 4.2.8 always launches fine no matter which method of installing. These tests were all manually just double clicking the msi or exe, no extra parameters.

 

• If I install 4.2.8 with the executable, then install 4.2.9 with the executable, everything works fine.
• If I Install 4.2.8 with the msi extracted with /createmsi, then install 4.2.9 manually with the executable, I get the error.
• If I install 4.2.8 with the exe, then install 4.2.9 with the msi extracted with /createmsi, I get the error.

If it's helpful, I'm attaching my msi output log

 

output.log

[Rick Brewster]

Okay, thanks for the info!

 

The good news is that progress is being made on this issue: before, the problem would go undetected and result in (seemingly) random crashes. 

 

Here's another thread on the subject: 

 

[Rick Brewster]

I moved the contents of this thread from here so it can have its own dedicated discussion thread: 

 

[Rick Brewster]

I've investigated this further and I have 1) a guaranteed fix without reboot, 2) an understanding of why the DLL problem is happening, and 3) an understanding of why PdnRepair requires a reboot

 

1) Guaranteed fix, no reboot required: 

• Choice 1: uninstall the MSI, then install the MSI. Yup, it's as simple as that
• Choice 2: run msiexec /fa PaintDotNet.msi . This is a repair operation and is the same thing that the "official" PdnRepair does

2) Explanation: The MSI contains new files, such as System.Buffers.dll. However, the file version and the assembly version are not in-sync, and the former (file version) can go down when the latter (assembly version) goes up. Thanks Microsoft, ugh. The assembly version is what's important. Windows Installer then looks at the file versions and says "this file doesn't need to be update", even though it does (you'll see this if you use msiexec with /l*vx (ALL logging enabled)). I should be able to package the MSI so that the files are tagged as "just always overwrite it okay? don't check the versions".

 

3) PdnRepair, the "official" repair UI that is launched when you get the DLL error and press the Repair button, requires a reboot because PdnRepair.exe itself is in-use and needs to be replaced too! 😂 I should be able to fix this easily (copy it to %TEMP%, execute, then delete).

[Rick Brewster]

🎉🎉🎉🎈🎈🎈✨✨✨

 

Update to #2: The fix should be to add an MSI property called REINSTALLMODE with the value amus. I tested this out by using Orca and running the 4.2.9 MSI when 4.2.8 is installed is now working great. No repair needed, etc.

 

I'll have that baked in for the next update, but for now you can create an MSI with it already baked in by using /createMsi REINSTALLMODE=amus (just include it with all the other properties like DESKTOPSHORTCUT, etc.)

 

More info on REINSTALLMODE: https://docs.microsoft.com/en-us/windows/win32/msi/reinstallmode

[stevenv]

Hey @Rick Brewster thanks so much for getting this figured out.

[Rick Brewster]

No problem!

 

This issue has been ghosting around in one form or another for a long time, I'm glad to finally have it figured out *knock on wood*

[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!

[Rick Brewster]

MSI is probably here for the foreseeable future, but hopefully I can make the MSI be just a wrapper around something less fragile (maybe MSIX?) and more manageable.

[Rick Brewster]

4.2.10 is out with the fix: