I'm cursed.
-
New job. Obviously the first time I'm on watch for the release pipeline, the bloody installer failed. I'm cursed. Every time I think about anything related to installers, something will break. I HATE THIS! Also, it works on my machine, but not on my colleague machine. sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
-
New job. Obviously the first time I'm on watch for the release pipeline, the bloody installer failed. I'm cursed. Every time I think about anything related to installers, something will break. I HATE THIS! Also, it works on my machine, but not on my colleague machine. sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
I bet something wasn't configured correctly on your machine that the rest of them all know about but it has been so long since anyone had to configure a system they have forgotten. Ask them, was there anything weird about when you configured your system? It might help. Then again, if they are using VMs for that I am talking out of my hat.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
New job. Obviously the first time I'm on watch for the release pipeline, the bloody installer failed. I'm cursed. Every time I think about anything related to installers, something will break. I HATE THIS! Also, it works on my machine, but not on my colleague machine. sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
Every time I think about anything related to installers, something will break.
Installers shouldn't be any less robust than your application code. This is a hard lesson we learned after using several different installer tools: InstallShield, Wise, and more than one MSI package. We now use Inno Setup exclusively. While it is somewhat less capable than the other tools, it is predictable.
Maximilien wrote:
it works on my machine, but not on my colleague machine
Our product runs on an industrial PC for which we create the system image. A common test for us is to re-image a machine and then install the product application to ensure all dependencies are installed properly. In a more general-purpose environment it's harder to manage dependencies. You have to contend with variable end-user environments plus a wider variety of Windows versions. The user may have newer versions of something installed that you depend on. It takes a lot of tedious testing to make sure all of the use-cases are covered.
Maximilien wrote:
I HATE THIS!
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures. You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
Software Zen:
delete this; -
New job. Obviously the first time I'm on watch for the release pipeline, the bloody installer failed. I'm cursed. Every time I think about anything related to installers, something will break. I HATE THIS! Also, it works on my machine, but not on my colleague machine. sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
It never worked in the first place. They just said it did ... waiting for the "new guy" to fix it ... :wtf:
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Maximilien wrote:
Every time I think about anything related to installers, something will break.
Installers shouldn't be any less robust than your application code. This is a hard lesson we learned after using several different installer tools: InstallShield, Wise, and more than one MSI package. We now use Inno Setup exclusively. While it is somewhat less capable than the other tools, it is predictable.
Maximilien wrote:
it works on my machine, but not on my colleague machine
Our product runs on an industrial PC for which we create the system image. A common test for us is to re-image a machine and then install the product application to ensure all dependencies are installed properly. In a more general-purpose environment it's harder to manage dependencies. You have to contend with variable end-user environments plus a wider variety of Windows versions. The user may have newer versions of something installed that you depend on. It takes a lot of tedious testing to make sure all of the use-cases are covered.
Maximilien wrote:
I HATE THIS!
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures. You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
Software Zen:
delete this;Quote:
We now use Inno Setup exclusively.
I second Inno setup, it's robust and I prefer software that works like a tank over all the clever brittle software.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
New job. Obviously the first time I'm on watch for the release pipeline, the bloody installer failed. I'm cursed. Every time I think about anything related to installers, something will break. I HATE THIS! Also, it works on my machine, but not on my colleague machine. sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
I learnt there is one thing I should never do: upgrade the firmware of my hardware. Everyobne does it and it works flawlessly. I do it, something critical breaks.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Maximilien wrote:
Every time I think about anything related to installers, something will break.
Installers shouldn't be any less robust than your application code. This is a hard lesson we learned after using several different installer tools: InstallShield, Wise, and more than one MSI package. We now use Inno Setup exclusively. While it is somewhat less capable than the other tools, it is predictable.
Maximilien wrote:
it works on my machine, but not on my colleague machine
Our product runs on an industrial PC for which we create the system image. A common test for us is to re-image a machine and then install the product application to ensure all dependencies are installed properly. In a more general-purpose environment it's harder to manage dependencies. You have to contend with variable end-user environments plus a wider variety of Windows versions. The user may have newer versions of something installed that you depend on. It takes a lot of tedious testing to make sure all of the use-cases are covered.
Maximilien wrote:
I HATE THIS!
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures. You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
Software Zen:
delete this;Quote:
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures. You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
AMEN! I do software repack and deployment. I have to deal with at least one bad installer a week, and it doesn't matter what it was built with. I can't tell you how many times I've called up vendors and asked them "what the hell are you doing mate?" Time and time again, there's only one person building the installers and, like you said, it's always up to the "DSJB". I've even had installers that work fine on install, but on uninstall, they treat the customer machine like a $2 whore. "WMI Providers? Nuke 'em. What do you mean we just killed your SCCM deployment system on your machine?"
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
I learnt there is one thing I should never do: upgrade the firmware of my hardware. Everyobne does it and it works flawlessly. I do it, something critical breaks.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Quote:
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures. You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
AMEN! I do software repack and deployment. I have to deal with at least one bad installer a week, and it doesn't matter what it was built with. I can't tell you how many times I've called up vendors and asked them "what the hell are you doing mate?" Time and time again, there's only one person building the installers and, like you said, it's always up to the "DSJB". I've even had installers that work fine on install, but on uninstall, they treat the customer machine like a $2 whore. "WMI Providers? Nuke 'em. What do you mean we just killed your SCCM deployment system on your machine?"
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
> they treat the customer like a $2 whore Oh man, I have got to use that line in a meeting some time. :laugh:
Software Zen:
delete this;