The Installer Team needs to be reorganized, there's no excuse for this. The 0.5% of our team coding activity regarding being able to install a Service on our own, in-house Web Server? You want me to have a Windows Installer Specialist on staff just to satisfy Unless I am willing to spend a week hacking through this BS. I finished writing my service logic yesterday, it is all working beautifully, but now I can't deploy it. What is wrong with the Installer group at Microsoft? You want me to earn a PhD in Installers so I can struggle with this dysfunctional set of tools? I need to get on with my Business Functionality! I think it was a big mistake to try to create a Windows Service, just because of this deployment deficiency. I don't have time to become a Windows Installer Developer. Basically you'd edit the InstallExecuteSequence table (use Orca), deleting the InstallExecute row, and changing the sequence number of RemoveExistingProducts to 1525 (the number doesn't matter, only that it is immediately after InstallInitialize). You'd need to do that with a post-build modify of the MSI file. ![]() If you were to go back to the previous behavior of VS 2005 then that would solve the problem because that uninstalled the previous product before uninstalling the new one, if you can deal with that, because it uninstalls everything, even databases or other files that you have installed and may have been updated. ![]() So the issue is that they want an MSI-based install but they're not willing to follow the rules that it requires. ![]() Practically every build and update process used (except for the one in VS 2005!) depends on file versions - things like patches, service packs and VS 2008's RemovePreviousVersions *depend* on file versions to update files. If the process being used is that they are updating Dlls and not incrementing the version then they're doing it wrong, just to be blunt.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |