Software Deployment

Surprisingly, this is the second time I've heard of MS renaming the contained Installer file...

The Office compatibility pack for 2007 had no extension, a .msp had to be added.

If you can rename the file and open the tables in ORCA, I wouldn't worry to much about the rename.

-West Michigan huh? -> I was born and raised in Kalamazoo

Then you know all about just how cold it is here in Januarary!

.NET 3.5 gets uglier. The more I look at it, the more it looks allot like the visual studio and SQL Server setup. It's a collection of .MSIs controlled by a central .MSI inside of an exe, thats created in a Randomly named folder. Who defined the .MSI standard again...

It looks like it might take parameters from an .ini file like SQL Server does, but I haven't yet found documentation on what that .ini file should look like, or be named. I'm starting to wonder if getting my custom transform around the .NET 3.5 setup is even worth it. I remember the nightmare that SQL turned into. If anyone is interested, the actual .NET 3.5 setup is extracted to:

<USER PROFILE>\Local Settings\Temp\dotnetfx<Random Number>\1033\dotnetfx35\netfx35_x86.exe

If you look inside of that archive you will find the .MSI and what looks like the parameters file for configuring the command line.

I'm not sure what the rest of the setup does outside of the .MSI. Why not build your transform, install it and then use a lightweight snapshotter (e.g. Ziff Davis's In Control) to see what the Setup stub adds (or removes)? This is what I have always done with EVERY re-package I've done and have now started to do with MSI-extracting Setup stubs which look likely to be doing the dirty on me.

On our computer we have a standard setup and after the installation we are installing FRMWRk 1.1 then 2.0 then 3.0. maybe 3.5.

We have VS 2003 and 2005 and we need to do a regiis on the correct FRMWRK location.

Is it true, we are correct by installing frmwrk in that order? It seems to me installing all those frmwrk is taking too much time... very slow. Is it a way to get faster?

3.0 will install 2.0 if it is not there, 3.5 will install 3.0sp1 and 2.0sp1. So you really only need to install 1.1sp1 and 3.5

Don't do it. We finally got our 1.1 and 2.0 packages working correctly
using the MSI/admin install method, then later discovered some
problems. Thankfully, they were caught before we rolled out the
packages.

Use Microsoft's method and use whatever distribution system you have
to deploy it.

Don't try to do an admin install. I know a lot of people in these
forums say they've done it successfully, but IMHO it's not worth the
risk. It's not supported by Microsoft.

With VS 2003, we are doing a REGIIS [FRMWRK1.1 path] and with VS2005, we are doing a REGIIS [FRMWRK2.0 path] .

In our VS package we have force the REGIIS.
As our users are lockdown, they cannot do themself a regiis.
If a service pack is apply on an existing .net installation, will the directory name being change?
If so is it a way to make sure everytime REGIIS will point to the good directory?