I had similar issues like this. This happens because when you run an upgrade, the Windows Installer sometimes uses the old version of your custom action DLL instead of the new one included in the installer. Even though you added the new DLL in your upgrade package, the installer might still have the old DLL in memory or cached in the temp folder. As a result, any new methods or classes you added won’t be found, and you’ll encounter errors about missing methods or classes. You noticed this yourself with your logging. When you upgrade, you still see the old log messages, which means the old code is running. When you rename the DLL or namespace, it works. This forces the installer to load the new DLL, but you clearly don’t want to rename everything for every release. The real fix is to ensure your custom action runs after the installer copies over the new files. In Advanced Installer, you should schedule your .NET custom action after the “InstallFiles” action, or even better, as a “deferred” custom action. This runs after the files are in place. This way, the new version of your DLL is already on disk when the installer tries to load it, so you won’t run into the issue of the old DLL being used. Also, make sure to do a clean build of your installer each time to avoid old DLLs lingering in your output folders. To sum up, you’re seeing this because the installer is using the old DLL during the upgrade. Schedule your custom action after the files are installed and mark it as deferred if possible. This will ensure the correct new DLL is always used during upgrades, and you won’t have to rename files or namespaces.