Software Deployment

Please, please keep MSI packages seperate! There are many reasons they NEED TO BE seperate (which I'm not going to list).

I would stay away from Nesting, especially a package such as .Net Framework in which other apps may require and which may come with updates.

Honestly, in my opinion you would make things eaiser if you create two packages. Just distribute the .Net framwork 1.1 to the entire enviornment. This package and others, such as Java, ISSCript, etc are common and required by multiple applications and are often updated. To aviod having to remove the origional applicaitons (as would be the case with nested MSI) it is eaiser to create a global distribution list and include these applications and make sure they are on all your PCs.

This would allow for eaiser updating and when your next application that requires .NET framework comes around you do not have to worry about including it in the new package because the user my or may not have the first application.

Depending on your distribution tool, you can probably put a install condition on the distribution.

Mr Hunter and Tom,

thanks for your replies.

I agree that nested installations are rather awkward especially
because of the remove/maintenance issues.

That leaves me with the command line install or something else,
because...

The package must be a single msi.

The reason is: This is not a deployment task in an enterprise I have
access to. It is a software for render farms which should be
installed through group policies. And when I start to ask the
users to handle different packages, I will lose the ease of deployment
which is an essential advertised feature of the product.

Potential customers will see a long list of instructions and and say
"Tally-ho! I am not in the mood for it. Let's see the next one"

Should it be the truth that a complete installation is not planned for?

Asks, with regards,

Andreas.

Hassmanm,

The Dot NET framework is an msi. So making a CustomAction in your first msi to call either the setup or the Dot NET msi may not work becuase you will have another instance of MSIEXEC running.

I would suggest you create a stub laucher such as an EXE, BAT, VBS or some other command file to call the install of the DOT NET and then the install of the second application. If you are deploying via AD then I belive in AD you can create another type of install other than an MSI to install via a GPO. You can use this and lauch the two applications sepperatly.

If you have some other deployment tool like SMS you can use SMS installer to create an EXE that launches the two MSI files one at a time.

Hassmann,

just create a custom msi of dot net. and put it in as merged module (wise installer has this option).
Here jou can put a complete msi into an other msi.. without creating a custom action.

else create a custion action when the files are installed... and do a if..

If Not Installed
custom action
end

gr

Dear Tom,


thank you for your thoughts.

This is how I finally did it:

Created an exe and put in dotnetfx.exe and my .msi as custom resources.
When it starts, it checks for .NET installed and if not, extracts
dotnetfx.exe to the disk and starts it with the appropriate switches.

On process exit, it deletes dotnetfx.exe, extracts my .msi and
installs it afterwards. Then it deletes the .msi.

This way I could still have a single file to download. But I had to
give up the idea of a single .msi, unfortunately.

I wish MS would decide to install .NET as part of the standard installation.
That would help this very useful framework to gain developer base.

Regards,
Hassmann.

Given how widely it used these days, can't you just send out .Net Framework to all workstations as a separate package? That way you also have a managed uninstall option if you ever need it...

The vendor MSI for .Net Framework is easy to transform for silent install - just change the Accept property from No to Yes. Although it does have a fair whack of validation errors and warnings, about 1500... pretty standard stuff for a Microsoft MSI!

Cheers,
Rob.

On the Distribution side, there is the concept of the Prerequisite Application. That's an app that, although seperate, is relied upon by another app in order to function. Common prerequisites would be Adobe Acrobat Reader, Oracle Client, Crystal Reports and... .NET Framework! Even though they're two MSIs, customers often have a distribuiton system where they can define one application to be a prerequisite of another.

Very true, Rob,

and in addition to the Accept switch, one would add the cab to the msi and prefix it
with "#" in the Media table, but that would still leave you with two separate
installation files and thus too much hassle for potential customers to try out and
fall in love with the product.

Another idea would be to use the .NET msi and merge in your own files, replace the
MS UI, and apply for approval at the next hospital for the mentally challenged.

With my .exe I still have a managed uninstall of .NET, but I do not have a .msi
for group policy installation.

Why can't you run two instances of msiexec simultaneously, anyway?

This ICE validation thing with the .NET msi is rather disturbing for sure.

Skin off your nose,
Hassmann.

but that would still leave you with two separate
installation files and thus too much hassle for potential customers

Yep but if you send it out as a machine based install via GP it would auto install on startup (before users get ctrl+alt+del) no hassle for them at all - just leaving your other package for them to install in the normal way with no love lost [:)]

Not sure what you are going to achieve with the .cab file and the # thing as the cab file is already in the media table..

Don't know exactly why you can't run MSIEXEC twice, guess it just needs exclusive use of the system and that's that - although often when you look at task manager during an install you'll see more than one MSIEXEC process running!

Cheers,
Rob.

Delicate affairs and tender feelings...


I am not worried about the sympathy of my users.
The admins are hard to get laid.

And they will not try out my product if there are too many steps
to perform to install it. That's why I am trying to get a single file.

The "#" is to tell MSI that the cab is included in an internal stream.
I had added the dotnet.cab to the dotnet.msi before, using msidb.exe -a

What's in the mug, anyway?

Hassmann.

Knowing Alan it would be Directors Bitter!

I've got it coming out of my taps!

I install .net with the following KIX-code

; Remove of .Net Framework 1.0
If Exist("%Systemroot%\Microsoft.NET\Framework\v1.0.3705\ConfigWizards.exe")
Shell 'cmd /c %systemroot%\Microsoft.NET\Framework\Install.exe /u /p Microsoft .NET Framework Full v1.0.3705 (1033) /q'
EndIf

; .Net Framework 1.1
If NOT Exist("%Systemroot%\Microsoft.NET\Framework\v1.1.4322\ConfigWizards.exe")
Shell 'cmd /c $Source\Sources\Dotnet\netfx.msi /q'
Shell 'cmd /c $Source\Sources\Dotnet\NDP1.1sp1-KB867460-X86.exe /q'
Shell 'cmd /c $Source\Sources\Dotnet\NDP1.1sp1-KB886903-X86.exe /q'
Else
; .Net Framework 1.1 SP1 - KB867460
$DotnetPatch = ReadValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{411EDCF7-755D-414E-A74B-3DCD6583F589}","ComponentID")
If NOT $DotnetPatch = "S867460"
Shell 'cmd /c $Source\Sources\Dotnet\NDP1.1sp1-KB867460-X86.exe /q'
Shell 'cmd /c $Source\Sources\Dotnet\NDP1.1sp1-KB886903-X86.exe /q'
Else
; .Net Framework 1.1 SP1 - KB886903
$DotnetPatch = ReadValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{8EFA4753-7169-4CC3-A28B-0A1643B8A39B}","ComponentID")
If NOT $DotnetPatch = "M886903"
Shell 'cmd /c $Source\Sources\Dotnet\NDP1.1sp1-KB886903-X86.exe /q'
EndIf

EndIf

EndIf