Jump to content

Silent .NET Maker synthesized 20100118 - W2K/XP/2K3 x86

strel

By strel
in Application Installs

 Share

Recommended Posts

YumeYao

YumeYao

Posted
Posted (edited)

just methodic.

but i'm undertaking a series of tests to see how your script really acts. and I have found something interesting.

On a clean system(I just cleaned HKLM\software\microsoft\devdiv, HKLM\software\microsoft\NET Framework Setup, and entries in WINCUR\Installer & Uninstall, then I assume it's clean)

1. Install .NET 2.0 with MST, WU delivers KB829019(2.0 LP) & KB951847(3.5 LP).

KB951847 is not needed.... WU delivers it because .NET 3.5 is considered installed...

2. Install .NET 2.0 lp with MST, WU delivers none.

This seems perfect but.........

3. Uninstall .NET 2.0 lp, WU delivers KB829019(2.0 LP) & KB951847(Not LP).

see, removing .NET 2.0 lp breaks the blocking of KB951847. since KB951847 is delivered, so KB951847(LP) is not pushed.

4. Install .NET 2.0 lp with MST again, hoping it fixes blocking KB951847, but WU delivers KB829019(2.0 LP) & KB951847(Not LP).

It doesn't fix.......

So I think this is, of course, not intended. and I suppose you want this:

any .NET fx is installed ----------------> blocks KB951847 and KB928416. let WU push LP for what is current installed.

any .NET lp installed ------------------> doesn't need any fix, because if they are installed WU won't push them.

so here is my solution for your purpose.

especially, for .NET 2.0 + .NET 3.0 + .NET 3.5 combination, KB829019 is not needed because KB951847(LP) includes it. so my solution satisfy this.

EDIT3: this part is re-written and is still experimental.

For PT-BR fix on PT-BR system, if this fix is overrides PT-BR 2.0 LP, then it must be applied each time "blocking KB829019" and .NET 2.0 LP install; if this fix is just an addition to PT-BR 2.0 LP, then it can be applied for one time on installing .NET 2.0.

.NET 2.0 install ---------> block KB951847 and KB928416 and KB951847(LP - 3.5 branch) --------------> WU pushes KB829019

.NET 3.0 install ---------> block KB829019(KB951847 - LP - 2.0 branch) and unblock KB951847(LP - 3.5 branch) -----------------> WU pushes KB951847(LP) -- I don't know whether it's ok as .NET 3.5 is not installed

.NET 3.5 install ---------> unblock KB951847(LP)(3.5 branch - condition: 3.5 LP or 3.0 LP is really not installed) and block KB829019(in case it's unblocked by other actions) -----------------> WU pushes KB951847(LP)

.NET 2.0 LP install ----------> do nothing.

.NET 3.0 LP install ----------> if .NET 2.0 LP not installed && .NET 3.5 not installed, then unblock KB829019

.NET 3.5 LP install ----------> if .NET 2.0 LP not installed && .NET 3.0 LP installed, then unblock KB829019

and for uninstalling, I don't think there is an easy method than checking 6 components's existance to reapply all registry blockings....

BUT....... If you decide to block LP forever, things will be very easy.

.NET 2.0 install ---------> block KB951847 and KB928416 and KB951847(LP) EDIT: block KB829019-PT-BR on PT-BR --------------> WU pushes none

.NET 3.0 install ---------> do nothing --------------> WU pushes none

.NET 3.5 install ---------> do nothing --------------> WU pushes none

.NET 3.5 uninstall ---------> reblock block KB951847 ------------> WU pushes none

.NET 3.0 uninstall ---------> reblock block KB951847 ------------> WU pushes none

.NET 2.0 uninstall ---------> remove all blockings ------------> WU pushes FULL .NET+LP Package

.NET x.x LP uninstall ---------> reblock KB951847(LP)(x.x branch)(EDIT2: condition - .NET 2.0 is installed)

EDIT4: there are totally 4 edits in the post(including this).... sorry for any inconvenience.

EDIT5: the first solution is still being edited each time i find it's inproper.

Edited by YumeYao
Link to comment
Share on other sites

strel

strel

Posted
  • Author
Posted (edited)

Mmmm maybe I left this possibility uncovered with KB951847 (2.0 SP2 langpack), I'll check. Anyway, if you're uninstalling langpack for 2.0, the next logical step is to uninstall the framework. Forget about the relationship among KB951847 and ( KB829019, KB928416 ) fixes, the last group of fixes avoids SP0 langpacks (a WU nonsense), and are not related with KB951847 fix.

Edited by strel
Link to comment
Share on other sites
YumeYao

YumeYao

Posted
Posted (edited)

no no no. not lp combo.

If I have 2.0 language pack installed, then WU doesn't push KB829019.(I can see your fix is writing a reg key with "\1.1")

but If I don't have 2.0 language pack installed, then WU pushes KB829019.

Edited by YumeYao
Link to comment
Share on other sites
strel

strel

Posted
  • Author
Posted (edited)

What's happening is that, remebering I realize, I conceive the uninstall/install operations this method is covering with framework+langpack as a block for installing and for uninstalling, what is the normal use. But you're right this issues should be covered. Anyway you seemed to be the first one complaining, so it seems it doesnt bother.

Edited by strel
Link to comment
Share on other sites
strel

strel

Posted
  • Author
Posted (edited)

I'm making the VC8 (only) removing file. In the VC8-DrW removing draft you posted, in Directory table the following entries are not removed, is this intentional?

WinSxsDirectory.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E

WinSxsDirectory.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E

WinSxsManifests.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E

WinSxsPolicies.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E

Edited by strel
Link to comment
Share on other sites
YumeYao

YumeYao

Posted
Posted

of course not. you know when creating mst, InstEd's removing related entries function doesn't work....

well I decide I'll always create a modified msi first, then create mst file by clearing original entries and pasting new entries. :P

Link to comment
Share on other sites
strel

strel

Posted
  • Author
Posted (edited)

For the debugger (only) removing file, the Property Custom Actions with target [WindowsFolder], [CommonFilesFolder] and [ProgramsFilesFolder], and its related entries in the XXXXExecutionTables, I'm dubious about removing them in the same manner as with that CA of the 3.5 slimming files. Is the same case? Any news around this?

EDIT: I understood finally what's the logic in removing them, they are there only for supporting the creation of a folder tree where only resides a DW subfolder exclusively related with office debugging. In the case of the [XXXXX_folder] entries in 3.5 slimming files I ask you before, it's not the same case in my opinion, I have not see they are there for creating any uneeded forlder tree, in fact I still don't know it's function, if any.

Edited by strel
Link to comment
Share on other sites
strel

strel

Posted
  • Author
Posted

About debugger removing. You say it's convenient an option to remove debugger because there is ways to install updated versions than that inside .NET 2.0, but from your draft I see in the FeatureComponents table that removing all components of Watson Feature you're removing also C# debuggin and logging, should they remain or are they updated by OFFICE 11 SP3 too?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...