An area of current difficulty with technology management is the inability to rely on particular versions of Dot Net being uniformly available across the enterprise. I’ve used Dot Net for the standardisation of software packages as it allows for standardised interfaces with software management to occur.
One of my pet-subjects is software standardisation. I have believed for a long time that all software needed to be standardised and involved a standardised wrapper to ensure that packages were portable. About 5 years ago I decided to get rid of all the old vbscript install scripts and separate configuration information from execution logic. By using XML for recording all the data about an application (install syntax, owner, manufacturer, versions etc) while a Dot Net executable could handle the more complex logic of dealing with the actual install. The system works extremely well but the Launcher requires Dot Net runtime to be present.
Dot Net is now in a transition stage. We could rely on Windows XP to have Dot Net 3.5 but as more modern systems replace the older technology, Dot Net 4.5 is present instead. With my standardised applications I recompiled the Launcher as a Dot Net 4 version & use SCCM to work out which version will be used as part of an Application Install.
SCCM Deployment Types
SCCM is extremely flexible and there is lot of disagreement amongst technical staff as to how the technology should be used. What I believe is that the way to support different platforms (in this situation) is to create different deployment types within an Application, with each installer targeted for running on its own targeted environment. As I am catering for Dot Net 3 and Dot Net 4 environments I have two separate, script based deployment types.
As normal, each Deployment Type can be created from the same installation source.
However “requirements” can be specified on each Deployment type to only run if the destination machine has Dot Net 3 or Dot Net 4 present. This can be done because both Dot Net releases install assemblies in folders under “C:\Windows\Assembly” (Dot Net 2 files are actually installed with Dot Net 3).
The condition created with this deployment type will only be satisfied when the “NativeImages_v2.0.50727_64” folder from a Dot Net 3 installation is present on a machine.
The Dot Net 4 based installer is conditioned to be used when the version 4.0 assembly folder is present.
By setting up dual Deployment Types I can be certain that the custom installer will work on old and new Operating Systems - regardless of the Dot Net runtime they are installed with.
- Log in to post comments