YumeYao

yes it was not uninstallable because at that time I did not realize how to get it(that's why put stroke line on them). But if you have followed everything in my updated tutorial, it should work. I guess you may still work with my previous tutorial, or you've missed something, or your install script is preventing them from being uninstallable. So just attach your modified msi(s) and install script for an easy check.

once .net 3.5 can not be removed, then it blocks .net 3.0 and 2.0 from being removed.

replying from my mobile device. this log issue is because environment variables are not assigned at T-13. strel specified log path to "%temp%\logname", resulting "\logname", which means logname in the current root. I have locally fixed it by adding this line to install.cmd if not defined temp set temp=%cd%

First I'd say sorry I am again busy in real life. Er..... and I think I may have a cold(one f*cking guy of my roommates keeps motorfan running but it's already 3 days raining in a row.), so I decide to postpone my effort on this project to this weekend. Yeah it's OS/SP# independent, so it's totally OK to be installed on XP/2K3. For the statements in red, you get the wrong idea. For the definition of these totally 6 files, KB898461 describes it. Although they vary in version, and even files in same version may vary(due to different compile dates causing different build times in PE header), they are doing the same job. They are similar to 7zip sfx module, how they work all depend on the configuration files(just like 7zip sfx config.txt) and contents(just like 7zip sfx 7z archive). Only that maybe a higher version provides more features. So, here, I want: use highest version of the copy of these 6 files for any installation in hotfix form. The reason is because 7z archive same files only once, hense making the output size smaller. And the hightest version must be downgrade-compatible(there are enough proofs for us update pack makers) so it doesn't curropt the original functions at all. I'm acturally upgrading not downgrading , version in .NET 3.0 is 6.3.13.0, in 3.0 LP is 6.2.29.0. BTW, the shell for 3.0LP have renamed spmsg.dll to spmsg2.dll. Just FYI. Sorry you make it wrong again. (I think I have to improve my ablity of expression. ) Continueing with the previous topic, I said that there are totally 6 "update shell files". Actually for most windows hotfixes/updates, there are only 5, spupdsvc.exe missing. spupdsvc.exe is not DELAYING jobs for next reboot at any time(this part can be simply done by registry), instead it always makes DELAYED jobs start right now. It's not odd that you can't reproduce it. For most delayed jobs, they are safe to be executed at once, that's the reason of spupdsvc.exe's existing. M$ uses this file to do certain post-hotfix-install routines including making delayed jobs execute. For an untouched windows install source, there are some delayed jobs that can't be executed at once when the progress is T-13, but the problems they're causing are so slight that most people would ignore them. An example is if you use nlite to crack syssetup.dll, nlite will make a delayed schedule at Pre-T-13(registry process stage) to restore syssetup.dll on next boot(move sysback.dll to syssteup.dll). Then a spupdsvc.exe executing at T-13 will break this.(it try to move sysback.dll to syssetup.dll but syssetup.dll is in use so sysback.dll is deleted and syssetup.dll is left as it was.) Because as I said, most hotfixes doesn't contains spupdsvc.exe so it doesn't need the user to delay hotfixes to RunOnce and nlite can handle this correctly. Off the topic, I suggest direct integration of hotfixes, or what's better, an update pack(as the maker will consider everything through). thanks for this. For my blocking scripts, yes they were not working correctly. Blockalllp.vbs is always working as expected, BlockKB951847.vbs was not working and I have fixed it(removed "(" and ")" for function WriteRegKeyIfNotExists in line 6,7,8). Blockall_Undo.vbs is still not working and I can't figure out where the error is. Do you know any editor or tool that can assist a vbs editing? EDIT: I've found a tool named PrimalScript, 45 days free-trial, it should be enough for me. thanks anyway. EDIT2: Just see that you are woking on spupdsvc.exe fix. I have accompolished a modified version of your install.cmd, which including this fix. I'll put it here later in a word document(do you prefer .doc or .docx or .rtf?) with colored comments. Then all you need to do is convert them into your script(adding echo>>install.cmd and adding %, ^ and such special symbols.)

I don't know how to make it easy to understand, but you know that there are some post-reboot actions made by an installation due to various types of causes, such as replacing file-in-use, delayed services start, etc. So does a windows hotfix. a windows hotfix may prompt you to restart your computer, for example, it's a hotfix that contains a newer version of shell32.dll, which is in use, so you have to restart your computer to replace it. But here we say, Anyway, this type of hotfixes is not what causing problems at T-13(svcpack.inf). There is another type of hotfixes, they may not require a reboot, but they have some post-install commands, therefore they may call spupdsvc.exe to perform these commands AT ONCE. WTF spupdsvc.exe doesn't know which delayed commands are scheduled by this installation and which are by others, so it executes every thing. This is quite ok on a living system, but on a setup-in-progress system, it may be fatal. if you ever have a look at Windows Setup timeline(although it's quite out-dated it does something to this issue), you'll know that all steps are scheduled in order for a windows setup. One mistake may lead to the change of all the timeline after it. However, on a untouched system, this issue is so slight that can be ignored. But on a customized system, this issue may lead to quite a lot of customized actions fail. EDIT: and windows setup is so fragile that even a small fault may lead to global fail. There once was a thread in RyanVM.net that discussed about all these, if I don't make it wrong, it was because a guy who made a T-13 switchless installer that executes some inf files to perform certain installation. Unluckily, his installer met some condition that make windows perform something similar to spupdsvc.exe, then it corrupted windows setup. (The situation was more complicated than what I described here.) This issue made us(I mean active RyanVM.net members at that time) realize such an issue. I have tried to find it out, but failed, sorry for this. I have modified your install.cmd script and I'm now doing some windows setup tests in VM to see how it works. I have modified a lot so it's hard to tell what changed in short, I'll later post here anything I find.

wow, hard work. I only viewed .NET 2.0 SP2, .NET 3.5 SP1 and .NET 3.5 SP1_cn. Nothing serious, only if you like, you can make this cleaner. 35_slimmingmore.zip

about blocking strategy: I choose always block all language packs: .NET 2.0 install ---------> Blockalllp.vbs BlockKB951847.vbs BlockPT-BR.vbs(on PT-BR system) .NET 3.0 install ---------> do nothing .NET 3.5 install ---------> do nothing .NET 3.5 uninstall ---------> reblock KB951847 BlockKB951847.vbs .NET 3.0 uninstall ---------> reblock KB951847 BlockKB951847.vbs .NET 2.0 uninstall ---------> remove all blockings, but keep a language pack registry entries if it's really installed. Blockall_Undo.vbs .NET 2.0 LP uninstall ---------> reblock .NET 2.0 LP if .NET 2.0 is installed. Blockalllp.vbs .NET 3.5 LP uninstall ---------> reblock KB951847(LP) if .NET 2.0 is installed. Blockalllp.vbs PT-BR system checking is not included in the vbs.(same as yours) All other conditions are included in vbs. Blocks.zip I'm not very familair with vbs, so please review them. EDIT: I suggest you make 3 sperate msts. one for .NET 2.0 (Blockalllp.vbs BlockKB951847.vbs BlockPT-BR.vbs for installing, Blockall_Undo.vbs BlockPT-BR_Undo.vbs for uninstalling) one for .NET 3.0 and .NET 3.5 (BlockKB951847.vbs for uninstalling) one for .NET 2.0 LP and .NET 3.5 LP (Blockalllp.vbs for uninstalling)

T-13(svcpack.inf) installation behavior suggestion: make any windows hotfix delayed, such as KB971276(or XPS Printer), WIC, XPS-LNG. This is because spupdsvc.exe, which is executed by them, will take effect on those actions that are planned after reboot(or here specific, first logon to desktop). This issue can be serious in quite a large scale of customed XP/2k3 installations. so, at T-13, you can copy them to some temp folder, and then write a cmd file by echo>>SOMEWHERE\DNFstub.cmd, the content may looks like: Start /wait SOMEWHERE\(WIC, XPS, XPS-LNG)\update\update.exe /quiet(or /passive) /nobackup /norestart rd (WIC, XPS, XPS-LNG) /s /q del %~f0Then add this cmd to RunOnce(HKLM\software\microsoft\windows\currentversion\runonce). maybe a vbs is better but i'm not able to write a vbs without examples or documents, so there is no example. The pros of a vbs is it won't show up a black box. But I'm not sure whether a vbs can delete itself like a cmd does. Additionally, you can apply .NET 3.0 font cache fix MST only when it's at T-13. Cheers. EDIT: I was too fast to make this post. Let me ensure that .NET installations(msi) themselves don't break the delayed action of windows. EDIT: ok, seems not.

Yeah, but from what i know, there is no need for .NET 2.0 to use this dwsens.dll. .NET 2.0 doesn't have a debugger, etc. .NET 2.0, like it is, "framework", is a framework on which applications could be runned. Same thing happens on .NET 3.0 & .NET 3.5, that's why they don't have such a dwsens.dll. I have said that, only applications coming with a debugger for itself needs this. That's why I see no points it's needed. Additionally, I suppose the reason why .NET 2.0 include office debugger is for those who installed office11 but didn't have latest service pack applied. As it's said that .NET 2.0 is partly compatible to .NET 1.1 applications, so maybe this update is intended to let office 11's .NET 1.1 extension able to be debugged within the enviroment of .NET 2.0. As said, latest service pack of office 11 contains newer files, so definatively this functionality is embedded into office 11 itself. on 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst: they are safe. That's what the trick is. and thanks for the trick of creating mst file. very handy.

But I still assume they are same. Well, have you noticed my description in my tutorial on the installer type, I defined it as an offline installer. Thus, an online installer may uses the location such as desktop, etc., because If i remember this correct, there was some online installer creating a shortcut on desktop(for resuming a paused downloading, etc.) Maybe when the online installer was modified into offline installer, M$ crap forgot to remove these entries. ---- I see no points why a external commandline/dll/internal binary using such properties. I just checked it again. I was sure dwsens.dll also appears in office 11, even same action(2 same entry points are loaded). However I looked at them again and found the 2 dwsens.dlls in office 11 and .NET 2.0 differs. So I'm not sure whether they do exactly the same jobs yet I expect it. I'll go to look up any info available about this, and maybe even test it.(hoping I can directly call it by rundll32, not by installer each time, installing office 11 will be insane.) EDIT1: for your mst files, I just applied both and then compare the transformed to mine. So I did some improvements (my previous draft also missed them). 20SP2_REM_OFFDEBUG.mst20SP2_REM_VC8.mst EDIT2: I decide to remove dwsens.dll. From what I know, the registry keys set in SYSTEM\CurrentControlSet\Services\Eventlog\Application\.NET Runtime 2.0 Error Reporting and SYSTEM\CurrentControlSet\Services\Eventlog\Application\Microsoft ® Visual C# 2005 Compiler doesn't need dwsens.dll. From what I see, dwsens.dll only appears in M$ products that have an external error handler, such as office, M$ defender, etc. So it must be such a dll, making external debugger(or we say here, error handler) able to override dr. waston's job. EDIT3: Updated MST here, with dwsens.dll removed. 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst and have you noticed the table "SensSubscription", don't you think dwsens.dll is relative to it?

When I wrote a subtitle for this thread ".NET 3.5 installer for 34MB", I mean it's 2.0+3.0+3.5. .NET 2.0 is about 15M(compressed), so, a lited 3.0+3.5 can be as small as 34M-15M=19M. Cheers.

I have just reviewed this. Yeah you are right, Watson20_Error_Logging_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 and CSharp_Watson20_Reg_Keys_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 should be kept.

I suppose so, and I havn't look deeply into this. but FWIS, removing them doesn't cause any problem.

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.

works for me.................. EDIT: msi tested by copying windows folder(containing VC9) together. I'll view mst file now.

maybe others all installs proper language packs for their OSes, but I never do this.

not only after uninstall 2.0 lp, but also before install it. if it's useless SP0 then it should be blocked on 2.0 installation, am i correct?

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.

do you mean KB829019 is a SP0 language pack, too? then why not block it? EDIT: just downloaded it, yeah it's SP0.

see this screenshot in VM...... install command was msiexec /i vs_setup.msi TRANSFORMS="NETWUFIXES.mst" ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0 and the (EDIT: original, before administrative deploying) msi is in previous attachment (EDIT: after administrative deployed.). EDIT2: have you cleaned "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" before testing?

well.... I just used this script (extracted from your script) to apply mst on msi.... like this: ECHO>35SP1SLIMMING.vbs Set instobjt = Wscript.CreateObject^("WindowsInstaller.Installer"^) ECHO>>35SP1SLIMMING.vbs Set dnfdb = instobjt.OpenDatabase^("vs_setup.msi", 1^) ECHO>>35SP1SLIMMING.vbs dnfdb.ApplyTransform "slimandclean35sp1.mst", 0 ECHO>>35SP1SLIMMING.vbs dnfdb.Commit CSCRIPT /NOLOGO 35SP1SLIMMING.vbs It works very very very smoothly for me. vs_setup_MOD.msi is modified manually and vs_setup.msi is transformed by this script. vs_setup.7z EDIT: the base msi is original vs_setup.msi in .NET 3.5 Install pack.

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.

thanks for reminding those CAs, I'll look further into them and I'll keep them if I can't find a potent reason. and I'm glad it works for you.

Thanks. But still I see no points on renaming .msi files. I uninstalled .NET 3.5 and then renamed them to whatever I like, WU didn't pust it. Then I uninstalled .NET 3.0, same result. and why not block .NET 2.0 lp when .NET 3.5 lp is blocked? I managed to do it: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727\2052] "Install"=dword:00000001 "Version"="2.2.30729" change 2052 to current system language first.

I don't know how it fails you but in my test, the registry value SystemComponent doesn't exist in key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}, after I removed ARPSYSCOMPONENT in Property table. so did you modified ARPSYSCOMPONENT to 0? or did you removed ARPSYSCOMPONENT and you forget to clean up the original registry value(since in my test, no value is set, therefore if there is an old value there it may cause this issue). anyway, I created slimandclean35sp1.mst by cleaning all original entries then copy in modified entries (I'm too lazy to remove them again one by one), and I have tested applying it, it works. This mst files do slip redundant components including VC, and do all cleaning up I've found. additionally, in your script: START/WAIT MSIEXEC /a "!TMPDIR!\WRAP35\vs_setup.msi" /l*v "%TEMP%\TRANSADMIN.LOG" NOVSUI=1 /qb TARGETDIR="!DNF35DIR!\DNF35" I didn't use NOVSUI=1. and I believe a slimmed down vs_setup.msi doesn't need this any more. and in my testings, msi files are executed by only adding flag ADDEPLOY=1.