Software Deployment

- Leave files outside of .MSI
No opinion either way

- When an update comes, just replace the files <snip> reinstall using VAMUS.
No version control (how will you roll back to previous version?)

- How do you feel about using the ODBC table instead of the registry to push ODBC settings?
ODBC junk is registry-based so go straight to Registry table. If you're a Wise user, you do this already because Wise has a reputation for screwing this up

- Multiple files per component
Only one file can be the key path. If the key path file is already present with the same or higher version the component doesn't get installed.

- capture all vendor apps and apply manifest files using something like manifest maker.
- ALL vendor apps? You mean all vendor apps with legacy installers, right?

- All packages pushed through a login script rather than a deployment utility. So 1 app might hit 2000 machines when everyone logs in.
Your network admins must love you and your users even more so. LOL. Most deployment tools use a) throttled downloads and b) scheduled deployments.Ask your Helpdesk people and they'll tell you that one of the most common gripes from users is the time taken to log in. Installing apps during that process won't endear the IT Dept to your users and, let's face it, that relationship isn't exactly rosy to begin with.

- What do you do if one of your file keypaths (.exe) in the new version is v2.0 but the newly supplied executable is v3.0. Consider uninstall and reinstall new is not an option.
Doesn't make sense but shall we assume you mean the existing version is v2 and the new is v3? Surely this is a simple upgrade?

I'm a professional packager. I wouldn't market myself as the best packager out there. I'm not trying to downplay myself but let's face it... I come here and I'm often humbled by the knowledge of many here (including yourself, VBScab).

But I do know that when something doesn't make sense it's probably not the way to go.

I recently started a new job with a company. The job description was application packager and some virtualization and a help to start packaging windows 2007 (found out this probably wont happen for another few years). They wanted someone to replace a former overseas type of packager who was "terrible".

I come in and look at some of these packages and decide that I'm going to try to standardize a few things. So far all of the home grown apps have ODBC settings. So I start placing this stuff into the registry. When you install a package using the ODBC table and the driver doesn't exist, the MSI generates an error letting you know that the setting cannot be applied because the driver isn't on the machine... I was told by someone else to keep the error so that when they install the app should a problem occur, they'll know which driver they have to add. Ridiculous.

Every package gets installed with a "REINSTALL=ALL" applied to it via the logon script. That's just how it is here. The other day, one of our developers released a piece of software. They call it "a new version". They don't pay attention to version numbers. The previous version of a file for example was v5.0.1.3... Well wouldn't you know it, the new version of this file is v5.0.0.1. This file is a keypath with 10 files under it. Guess what!

I'm being paid fairly well but I think I'm being held back and I'm not sure how much longer I'll last.

By the way, to answer your question regarding the re-packaging of vendor apps... NO. ALL VENDOR APPS... Yes, even the .MSI based ones! I've never heard of this before.

I'm having a problem stating my case here because the guy who manages the login scripts has been here for 10 years and keeps telling the management that an UNINSTALL/REINSTALL will kill the network if 2000 people log in at 9am!

Isn't an uninstall/install new the best way to go? I thought it was. I'm just so frustrated...

In my opionion, it is and it isn't. What I mean is that it depends on the situation. For most installs, I create an admin point and distribute from there to maintain consistancy. We would patch it and do a reinstall=all or unistall/reinstall to have the target machines be at the same version as the admin point. Sometimes we created a secondary admin point if it was a highly distributed app like office 2003. It usually meant lenggthy and time consuming upgrades and the clients didn't like that too much.

Now with the new style of "setup.exe calls the msi" (office 2010) installs, the patches are applied with the initial install separately and then individual patches are sent to the machine afterwards. So you can't really patch your admin install any more. I personally don't like this because you have no real way of knowing what level you machines are patched to. The clients like this better because there are less lengthy upgrades, but rather a series of short installs now and then. But hey, thats the way the technology is going this week. Next week, it will be something different...

As for the woes of poor and problematic packaging standards, keep plugging away at and and you might be able to fix some things. If the money is good, just focus on the goal which is another mortgage payment, beers at the pub or a new LCD TV. If not, I'm sure theres another packaging contract somewhere.

My 1cent, keeping the other for gas.
[:D]

(In house developed app)


use WiX all these issues go away. Re the ODBC settings the downside of using ODBC tables is the source gets checked for existance during installation. Due to this you cannot install on a box that cannot see the db. which can be annoying.

Considering the in house developed packages... What do you do if one of your file keypaths (.exe) in the new version is v2.0 but the newly supplied executable is v3.0. Consider uninstall and reinstall new is not an option.


this confused me somewhat as well. If you have a new version of the same file leave the component with the same id increment the version.

the REINSTALLMODE property will take case of the rest. Typically OMUS / VOMUS will cause upgrade to happen on newer versions without the need for uninstall / reinstall.

If you need some wix guidance give me a shout I have a stack of templates that make life easy in the wix world. perhaps i should just post them when i stop being so lazy.

JM... I had a typo here I think... What I meant to say regarding "the new version is v2.0 but the newly supplied exe is v3.0"... here is the exact situation. The old version of the exe is v3.3.3.1. This .exe is the keypath of a component which has 10 additional files. The newly supplied version of the .exe is v3.3.0.0.

Also, I PM'd you a while back with my email address regarding the kix stuff. Take a look.

Thanks for the replies everyone... Guess I'll just have to collect the paycheck and roll with the punches.

How do you feel about this way of packaging...

(In house developed app)
Leave files outside of .MSI
When an update comes, just replace the files and recompile your package leaving package code the same, reinstall using VAMUS.

--first thing that comes to mind is "Another version is already installed". I'd at least set this to be an upgrade.

Multiple files per component

-- since you can only have one key file per component and each exe, dll, ocx (you know the drill)... without knowing the files, it's hard to say but if it's multiple executable files it's a bad idea.

(Vendor app)
capture all vendor apps and apply manifest files using something like manifest maker.

---You aren't capturing MSIs? Good luck getting vendor updates and patches to apply.

All packages pushed through a login script rather than a deployment utility. So 1 app might hit 2000 machines when everyone logs in.

--- if you don't field complaints about login times and network slowness, that will work. I shudder to think what would happen when all your users get Office on an undersized deployment box

Considering the in house developed packages... What do you do if one of your file keypaths (.exe) in the new version is v2.0 but the newly supplied executable is v3.0. Consider uninstall and reinstall new is not an option.

-- I haven't developed an msp before, but that'd be where I'd start looking.

I have my opinions but I'm really interested in some other professional opinions/pros/cons.

perhaps i should just post them when i stop being so lazy. PM Bob, ask him if he thinks there's mileage in a separate Wix forum and, if positive, you can pop your notes in as a 'Sticky'.

I've asked Bob about the great idea regarding a separate WiX forum :)

I'm skeptical about product focused forums as I 've tried it a few times now and have usually had to take them back down due to inactivity. If there is a demand for it, I'm very happy to do so, but an empty forum looks bad so I'd love to judge the level of interest here. I've created a feature request in UserVoice at the link below, if you'd like to see a WiX area, please vote for it!

http://www.appdeploy.com/uservoice.asp?target=appdeploy