First Published: Jan 2014
Last Revised: Nov 2015
The following is a
definitive guide re: the "mysterious" failure of Dotnet 3.5 install on
certain Win8.1 systems, complete with backstory, roadmap,
explication, strategies and recipe, in a concise structured format,
for
IT professionals, not
end-users.
Synopsis:
- Microsoft Dotnet Framework is a platform required by many
applications.
- each
generation of
Dotnet has unique architecture & APIs:
- Dotnet 4.x will not support applications written for 3.x
- Similarly, Dotnet 3.x will not support applications written
for 2.x.
- Multiple parallel installations
might be required
- Each platform is
loaded & initialized at boot time, with intensive
scheduled optimization, regardless of whether you have
programs using it or not
- Windows 8.1 RTM come bundled w/ Dotnet 4.5 pre-installed (4.6.1
is current),
- Dotnet 3.5 SP1 is cached
to hard drive (in SxS), but
not pre-installed.
- attempts to activate
& install this via
control panel will likely fail**
- download "redistributabe package" for
offline install will also fail
- also applies to "disc install" using
application vendor's
bundle, which is essentially their MS download
- "web install" method will
fail shortly after the "stub" launches
- all cases in the field I encountered involved
Windows 8.1 and
Server 2012 R2***, but this
doesn't rule out Windows 8
and Server 2012 also being
affected.
Cause:
- certain critical updates released by Microsoft for Windows 8.1, instituted security policies, and
modified system settings, to the point where above mentioned
normal methods of Dotnet 3.5 SP1 package
installation will fail.
- known culprits include: KB2966826 KB2966827
KB2966828
- there are also "roll-up" updates which incorporated these
patches
- many 3rd-party software vendors also
integrate (not
include) them (along with
other "offending" patches) within their installer CAB/MSI/exe
- why some systems are "inexplicably" unaffected
- the offending patches impedes installation of dotnet 3.5, as SxS, or standalone package... but it does not harm the operations of dotnet 3.5, if pre-existing.
- upgraded from Windows 7 to Windows 8/8.1 with Dotnet 3.5
SP1 previously installed and working, it will be preserved: no need
to install = no failure
- those installing fresh
copy of Windows 8.1, absolutely
unpatched and with zero
3rd-party packages (applications or system utilities) would
be able to install & activate without blockage, using standard
consumer procedure
Solutions* & Workarounds
- hunt down and uninstall
all
offending patches, then install and activate the Dotnet 3.5 SP1 module
previously pre-copied into SxS during OS install, and finally--reapply
those uninstalled patches. Note:
brute-force method!
- surgerically undo
each and
every pertinent system security
policy, group policy and
miscellaneous registry
settings, that were fortified
by those "offending" patches. Again:
brute-force method!
- RECOMMENDED: use Microsoft
Deployment Image Servicing and Management (DISM),
with Window 8.1 installation DVD disc, via elevated CMD
Prompt:
DISM
/online /enable-feature /featurename:NetFX3 /All /Source:Q:\sources\sxs
/LimitAccess
Must be entered
exactly, without line-break.
Change Q:
to your actual drive letter!
- For consumer PCs without
installation media, obtain ISO image and mount
it (now a built-in OS feature!)
- Ultrabooks without optical drive: mount ISO image
- If no ISO image available, create one from physical DVD (use
imgburn, etc.)
- advanced tip: instead of uploading
entire 4 GB DVD image, just
extract the q:\source\sxs folder, totaling
287 MB, compressed down to a
very manageable 39 MB, if
you use the most advanced techniques.
- in-place Win8.1 reinstall via OEM DVD, which effectively revert 99%
of all Microsoft executables and DLLs back to factory default
(pre-patch/update) condition, likely rendering some applications
inoperable, triggering need to reinstall them afterward.
- As always, virtualization
is a candidate workaround, and an effective one in this case.
- run the new application requiring dotnet 3.5 as isolated virtual instance
- eliminate the need to install Dotnet 3.5
- select alternate product written for Dotnet 4.x platform, or
- stick with Windows 7
Commentary
- solution #1 & #2 above are extremely unlikely to be ultimately
successful, and therefore is "highly
discouraged."
- #4 is "banned" for all
DIFAs under Bravo IT
jurisdiction.
- Explicit exception override (with justifications) required.
- If you're an outside consultant, or represent the application
software vendor: let it be known that it is considered
harmful,
unacceptable, and
needless (due to readily
available alternative: DISM method. Therefore: We decline &
disapprove.
- of course, #5 implies all the ramifications of virtualization,
including: isolation (pro or con?), guest OS license, user procedural
training, potential USB pass-thru can-of-worm, etc.
- indiscriminately pre-install & activate Dotnet 3.5 at time of OS
install, prior to patches, regardless of actual need, is
unacceptable, as it violates 3
fundamental IT principles: Security,
Reliability, and Performance
Microsoft Dotnet
Framework |
Version |
Rel Date |
Full |
Bundled in |
Requirements |
1.0 |
FEB 2002 |
|
n/a |
|
1.1 |
APR 2003 |
|
Server 2003 |
|
2.0 |
NOV 2005 |
|
n/a |
|
3.0 |
NOV2006 |
54M |
Vista, Server 2008 |
|
3.5 |
NOV 2007 |
197M |
Win7, S2008 R2 |
|
3.5 sp1 |
NOV 2008 |
250M |
n/a |
incl. 2.0 |
4.0 |
APR 2010 |
54M |
n/a |
xpsp3,
visp1, w7 |
4.5 |
OCT 2013 |
66M |
Win8, Server 2012 |
visp2,
7sp1, ie6, msi3.1 |
4.6 |
JUL 2015 |
63M |
Windows 10 |
same as 4.5 |
* I have never encountered a single case where the DSIM method did not
work. However, I have to allow for that unlikely possibility. Hence the
claim of "99% success expectation."
** Detailed in the "Cause" section, including why the "mystery..."
*** Server 2012 R2 requires entirely different strategies, policies and
procedures, due to "Server
Roles" selection, and unique user
interface. All concepts & principles described here 100% apply. |