Hey strel.. I just managed to modify your brilliant script so it created a x64 addon.. I will run some tests before I write instructions for what I did..

Btw .. There's atm only one thing I can point my finger at when it comes to your script..
When I do a clean install with a FULL (every hotfix possible) addon that's called from svcpack I see alot of leftover log-files from the .Net Framework installers.. They are:

NETFX11
NETFX11lng
NETFX20
NETFX20lng
NETFX30
NETFX30lng
NETFX35
NETFX35lng

Maybe there should be a cleanup subroutine included or is the leftovers there because of the design of the script? I.e. if something goes wrong?
One could just write something like:

del %systemroot%\*.txt

in the end of the install.cmd, right?

Or of course, since we have the names of the log-files just specifically delete each and one of them so nothing unwanted gets accidentally deleted...

Djanz

Hi.

The logs are there in the same manner original installers left them in the %TEMP% folder, I just renamed and applied maximum verbosity to install logs only, uninstall logs are created automatically in the same folder by the installers, but are not renamed (I'm looking for a simple solution to do it from Add/Remove Programs but I'm not being able to manage msiexec.exe ... /l*v %TEMP%\NETFX##uninstall.log switch to work on the uninstall string). They are there to allow looking for errors in case it happened. I use a ccleaner scheduled task to remove them regularly on idle time. And of course you can use a del command to remove them.

About x64 add-on, maybe it's better you extract installers to test it, pay attention to the .mst files, Insted is your friend for doing that. Ask me if you have any questions.

EDIT: in fact the way install logs are stored is not exactly as the original one because install logs overwrite previous one for that framework/language, so there would less install .log files stored in the %TEMP% folder.

I have now managed to build a x64 installer that installs the full .Net Framework..
Only thing I need to get around now is to prevent it from showing up on MU ..
Maybe I have to look into the mst stuff! Hoped I could have avoided it though hehe..

I will attach the modified script when I manage to get around MU ..

Further testing will be run in the weekend if I get time..

Once again.. Nice script you've made, its clean and simple, yet it manages to build the smallest installer possible..
I like the way you make people build their own installers.. Hate those premade "packs" with updates and installers..
You never know whats inside and maybe there's stuff in them you want to exclude/include in your own custom made Windows... Tsch..

Write you later...

Djanz

Hi djanz.

OK. I don't know if regkeys or .msi database items to fix with .mst files have changed a lot from x86 version, if not you're lucky, otherwise it comes the boring part. You'll need to extract the .vbs files to understand what the CustomActions of .mst files do. The logic of the conditions to execute custom actions in the InstallExecuteSequence is a bit tricky. Ask me your questions.

New version in da hood!

Managed to workaround the old 3.0 framework errors in the event viewer installing at T-13 (and later uninstalling), and managed to fix and to adapt YumeYao's method for slimming down 3.5 SP1 installers, among other things.

Enjoy!

Hello when i try to create a localized merged addon of 1.1,2.0sp2.3.0sp2,3.5sp1 plus updates and language packs, whith all updates present in my working folder, i get a message for NDP35SP1-KB963707-x86 that there isnt even if it is in the folder.Same for dotnetfx35langpack_x86.Ididnt get those errors whith the previous script .Any idea why this hapens.Thanks again and sorry for my english.

Not getting that message. Please post your _SNMsynth settings and the file list in your work folder

My _SNMsynth.ini settings are
PROCESS_DNF1=YES
PROCESS_DNF2=YES
PROCESS_DNF35_DNF2=
PROCESS_DNF35_DNF3=YES
PROCESS_DNF35_DNF35=YES
PROCESS_DNF3_RGBRAST=YES
PROCESS_DNF3_WINIMAGING=YES
PROCESS_DNF3_MSXML6=YES
PROCESS_DNF3_XMLPSSC=YES
DNF_FF_ADDON=YES
PROCESS_LNG_DNF1=YES
PROCESS_LNG_DNF2=YES
PROCESS_LNG_DNF35_DNF2=
PROCESS_LNG_DNF35_DNF3=YES
PROCESS_LNG_DNF35_DNF35=YES
ADDON=YES
MERGE_FRAMEWORKS=yes
SILENT=
COMPRESSION_RATIO=

my file list is dotnetfx
NDP1.1sp1-KB867460-X86
NDP1.1sp1-KB928366-X86
NDP1.1sp1-KB947742-X86
langpack
NetFx20SP2_x86
NDP20SP2-KB958481-x86
NetFx20SP2_x86el
dotnetfx35
msxml6-KB954459-enu-x86
NDP30SP2-KB958483-x86
NDP35SP1-KB958484-x86
NDP35SP1-KB963707-x86
dotnetfx35langpack_x86el

Still no luck. You didn't include file extensions, I hope they're right. No idea what's happennig with you. Can I have a screenshot?

In my case the process run smothly except 1 bug I found applying KB963707 introduced in the yesterday release, and one minor issue removing unexistent files. But nothing about script requesting files actually present in the work folder.

Bugs fixed now. Download the new version!

EDIT: I forgot to remove 3 pause commands I use for testing, I've updaloaded it again. The first 9 who downloaded it, excuse me for the inconvenience

Hi Strel !

First... thanks for your script

I had a question about the size of generated file dnf35sp1: DNF35SP1_lng.exe
(I'm not using dotnet 1.xx)

_SNMsynth.ini:

My dir structure:
Screen of the filesize generated by the script (DNF35SP1fr.exe > 7MB)
Should'nt be DNF35SP1xx.exe bigger than 7MB ?

Note: I got no error with the script

I still haven't checked final filesizes, but if you didn't get errors, I think it's correct. It is the new YumeYao's slimming method integrated for 3.5 SP1. Try installing and uninstalling of 3.5 SP1 and its langpack. Moreover for the next version, this slimming method is going to be applied to the 3.5 SP1 langpack too, making 3.5 SP1 resultant installer, even smaller.

EDIT: I've checked it with the dutch installer. I was right. And if you don't touch COMPRESSION_RATIO to get max ratio (which should be doing everybody unless you have a pretty old machine with pretty low RAM), you'll get even smaller ones.

By the way, as I don't know what happened with you, and I don't know if you read my PM, and just discard it, can you try changing at the beginning of script CALL :EMPTYVARS line with REM CALL :EMPTYVARS ?

Many thanks first.


yeah, i've catched the cause before and am just curious, did you totally remove this from InstallSequence?
I don't know how it'll behavior but there is a post by code65536, says at T-13 there are still some jobs to be done for fonts. So do you think what original .NET 3.0 install does will or will not be done by windows's later jobs on fonts?


you can take a look at what I posted along with the method.
•KB955450 replaced with KB971276. KB955450 is XPS printer in .NET 3.0. I also did some trick to make it installable on both xp and 2k3.
•WIC's update shell replaced for better compression. I copied spmsg.dll, spuninst.exe, spupdsvc.exe and update.exe, spcustom.dll updspapi.dll from KB971276, as 7z will combine same files.
These two are helpful and harmless. I've tested it on XP SP3 and 2k3 SP2, it worked perfectly.
and for KB971276, I suggest you to use that for 2k3, since KB955450 in .NET 3.0 is 2k3-branch(some files are with version 5.2.xxxx). and for the trick I use, you can follow these steps when you make changes to your script.

1. extract KB971276 to somewhere, for example: %temp%\KB971276. you can use this commandline:
   WindowsServer2003-KB971276-v2-x86-ENU.exe /x:"%temp%\KB971276" /q
2. copy SP2 branch to SP3(for xp sp3), that means, make a copy of "%temp%\kb971276\sp2qfe" in ""%temp%\kb971276\sp3qfe"
3. copy KB971276-v3.CAT and update_SP3QFE.inf to %temp%\kb971276\update from WindowsServerXP-KB971276-v3-x86-ENU.exe, you can make these 2 files within your script(they are quite small).
4. modify %temp%\kb971276\update\update.ver, just duplicate all existing entries and change sp2qfe to sp3qfe(for each line there are 2 "sp2qfe"s)
5. modify %temp%\kb971276\update\updatebr.inf, add 3=SP3QFE in [DefaultBranchesServicePacks], SP3QFE="update\update_SP3QFE.inf" in [SourceInfsBranches], update\KB971276-v3.CAT in [SetupFiles.Common], then add section [SetupFiles.SP3QFE] with entry "update\update_SP3QFE.inf".
6. modify %temp%\kb971276\update\branches.inf
   SP2QFE="%SP2QFE_NAME%",SP2QFE -> SP2QFE="%SP2QFE_NAME%",SP3BTA
   add SP3BTA="%SP3BTA_NAME%",SP3RTM in [FileBranchInfo]
   add SP3RTM="%SP3RTM_NAME%",SP3GDR in [FileBranchInfo]
   add SP3GDR="%SP3GDR_NAME%",SP3QFE in [FileBranchInfo]
   add SP3QFE="%SP3QFE_NAME%",SP3QFE in [FileBranchInfo]
   add SP3BTA_NAME = "SP3BETA" in [Strings]
   add SP3RTM_NAME = "SP3RTM" in [Strings]
   add SP3GDR_NAME = "SP3GDR" in [Strings]
   add SP3QFE_NAME = "SP3QFE" in [Strings]

the attachment contains all modified files along with KB971276-v3.CAT and update_SP3QFE.inf.
This method will not increase the size because 7z will archive same files only once.
the weakness of this is XP SP2 users may not get this installed properly(I haven't done a test yet)
the side-effect of this is both KB971276-v3.CAT & KB971276-v2.CAT will be installed on the user's system.(however it does not harm)

There may be a solution but I don't have too much time now for working it out. FWIW the current solution will satisfy most occasions.

EDIT: I mean the user can choose whether he want to replace KB955450 with KB971276, it's suggested for XP SP3 & 2k3 SP2 users, and for others, they can just choose not.

I've substituted the .dll custom action RemoveFontCacheData in the InstallExecuteSequence with 2 .vbs custom actions that removes the font cache data file effectively. Why 2? I wanted to replicate original installer behaviour and another RemoveFontCacheData_commit custom action referring to the same .dll and entry point arises when the first is run from InstallExecuteSequence to be executed after InstallFinalize, thus trying to assure the operation (if there wouldn't be a bug).

This issue is not related with the previous one. What code65536 says is that windows is not registering some legacy fonts at T-13 until (at least) user log on. What he points out (I think) is that if this behaviour is overcomed, if you open a terminal (or so) during windows setup wrong font will be displayed, but only during setup. I don't exactly know what fonts 3.0 is installing but don't seems they are going to be legacy, so I don't think windows setup is handling its hidden attribute in order to avoid them to be registered over windows setup.

Answering the rest of your post, thx for clarifying your method.

So you're building .NET installers that include KB971276 features, I suppose all features of KB971276 are applied to the installers with this method, thus if windows would need to install KB971276 later, all this wouldn't make sense.

For the XPS printer you're combining XP+2K3 KB971276 hotfixes, I don't like this for SNMsynth because I think it's better to build different installers to different windows versions to adapt them to version specific requirements, since SNMSynth installers could include another hotfixes that could apply exclusively to a specific windows version. Moreover you say there could be problems installing over XP SP2, that would be a great weakness.

I don't know if I've understood you correctly but If you are saying something like an option to choose whether applying KB971276 or not, or whether applying XP+2K3 versions of it combined or not, would be a solution; then I agree with you, but only if this method apply all features from KB971276 hotfix(es), avoding the need to install it later.

For the rest of your modifications, as long as I think SNMsynth should be oriented to customization I think that giving the option to avoid to include VC runtimes in the resultant installer, allowing its install from another packs, is a good idea; as well as including options to allow .NET related windows hotfixes, like KB971314 and KB971276, to be included in the resultant installers, idea I deprecated until now because they don't have the form of .NET hotfixes and could easily be slipstreamed to a windows source, but I realize it makes a whole lot more sense if resultant installers are not meant to be used in a windows setup so a unique file with completion is a more interesting option. To avoid including WIC or MSXML, SNMsynth have options yet to do it. And of course documentation about what cases are this options useful to, needs to be included in the guide, now it's a grey area.

Cheers.

1. on the font. code65536 says it is because some hidden attributes are not set at T-13 so his utility fails, so maybe in some chance these attributes include font caching.
now you have explained your method so i see it's totally ok.

2. on KB971276.
i'm not combining that for 2k3 and xp but doing tricks on 2k3 hotfix to make it installable on xp - at least on xp sp3.
I haven't play with xp sp2 for quite long, and i'll test it later on a VM.

for KB971314, I never attend to include it in an .NET installer b/c it's totally an OS hotfix/update(therefore hfslip/nlite/RVM Integrator is a better solution.)
for VC runtimes, yeah, you can consider it. The VC runtimes in .NET are not complete ones, so even .NET is installed the user still needs the full VC package.
EDIT: from what i read from XPS Printer's install package, it's not installable on Windows 2000, is that correct?

fow WIC, yes it's still gray area but i can confirm it's not installable on xp sp3. when you try to install .NET on-by-on without any passive or quiet parameter, you'll receive an error installing WIC on xp sp3, saying "the target service pack lever is higher" or something else.

I've worked at ryanvm.net for 3 years so i'm sure with how an OS hotfix behaviors.

3. additionally, is there any chance to make .NET 3.5 language pack the same flavor? Although I know msi files for different language packs varies so there may be not a universal mst file.

Just my terrible headache this morning, I misunderstood him. And now I realize what are you referring to. Really have no idea on how font caching behaves about hidden file attribute on fonts, but I don't have any reason to think that problem is reproducing with font cache service.

OK, so I misunderstood your method, but why doing that? it seems 2K3 installer is Version2 and XP is Version3.

But may you concur with me that if resultant installers are not meant to be used in a windows setup it makes more sense to include it.

Nice info, to remove them you simply remove Windows folder in 3.5 SP1 portion, is that right?

It's done yet, 3.5 SP1 framework+hotfixes+langpack around 5 MB. I'm just deciding to include or not some extra modifications in the next version.

EDIT:
Never tried it.

1. yeah but they are all font related issues.
there are still many unknown mysteries of windows installation even we think we have know enough.

2. 2K3-V2 means it's newer than 2k3(-V1), and XP-V3 means it's newer than XP-V2 and XP(-V1). they are seperate branches, so you can't say XP-V3 is newer than 2K3-V2.

3. KB971314 can be applied on a living system without .NET installed, although it's needed after .NET is installed.
Additionally, it's not true that KB971314 isn't needed if .NET 3.0 is not installed. for example, KB948046, which address an printer issue, has already included an updated unidrv.dll, therefore it will also cause the issue descripted in KB971314 - PCL printer driver not signed.
so KB971314 is better included in an updatedpack for integration onto windows install source.

4. to remove VC 8 and VC 9 runtimes, removing entries in msi is also needed. If you are not sure how to do that, feel free to ask.

5. ok, glad to hear it so i don't have to help my friends do a slimmed .NET 3.5 language pack for each language they use.

YumeYao.

This one seems to work. [ OUTDATED FILE ] Prior to approve it, I'd like to have your opinion after checking the database as you've done this before and me not.

Thx in advance.

sorry for not replying in time but my schedule is suddenly ful-filled and it will last several days.
yesterday it was too late when i saw you post and first .mst file. yeah it obviously wouldn't work at one sight of transformed msi.

this time i'm not sure whether it really work since i don't have much time to test it. but i removed more entries than you did.

in brief:
Binary: SxsUninstallCA
CustomAction: SxsUninstallCA & SxsInstallCA
InstallExecuteSquence: SxsUninstallCA & SxsInstallCA
-------These 5 entries are used for installing VC runtime while Uninstall means uninstalling existing old VC runtime.

others seems all ok but just curious: can't an mst file drop a table instead of empty it? I mean, MsiSFCBypass and SxsMsmGenComponents are empty. don't mind since it doesn't matter.


and it seems you've forgot to remove VC8 in .NET 2.0 install package.
and in .NET 2.0 there is still a junk besides VC8, that's OFFICE 11 debugger.(office 11 SP3 contains newer version of debugger than .NET 2.0)
so attachment is what i did for .NET 2.0. it's based on the msi generated by your SNM. and i believe you can handle .NET 3.5 yourself now.

Yes, I was focusing only in 3.5 frameworks, I'll make files for 2.0 frameworks too, but I see yours is almost neat, that's going to save time.

My test revealed that removing those empty tables cause installation to abort, it surprised me, don't know if I did something wrong.

A lot of thx YumeYao.

waiting for good news from you, good luck!

when i'm free enough, i'll help deal with KB971276 (to find a solution compatible for xp sp2 and 2000, if M$ allows XPS printer in .net 3.0 installed on them.) and then later look through your msi files to see if there is still space for improving.

The re-sequencing of the FileTable is a nonsense from my point of view, I'm rebuilding all the slimming files to avoid it.

a fast reply....

I don't know how do you plan to apply my method for language packs, but if you decide to build mst files for each language available, I suggest you stop doing that because I've found a better way to deploy them, including .NET 3.5 (not langpack). I've done enough tests that proves its functionality and I'm going to compose an updated tutorial, so you can do the job after my turorial is updated.


EDIT:
ok, a quick description is on the base of your method, modifying property table, removes "ARPSYSTEMCOMPONENT" and "INSTALLLEVEL". then you don't need to modify registry later.

I'll check it again, but if I recall it correctly, ARPSYSTEMCOMPONENT is overcomed during install so its value is 1 in registry after installing. That's why I used the script.

EDIT: Let's give it a try, if INSTALLLEVEL work no file would be needed for langpacks nor for slimming removing VC9 too... Checking

after i removed this entry i don't need post-installation reg fix any more. maybe it must be removed together with INSTALLLEVEL together to take effect?


for KB971276, I have modified it again. now it's totally ok in XP SP2/SP3 and 2003, expect for a tiny bug in XP. However this bug is fixed and the attachment shows all(extract KB971276, modify it, generate bug-fixer as a cmd file for later use).

put the attachment in .NET 3.0 working dir, which includes XPS printer.
This attachment will also replace windows hotfix update shell in WIC and XPS lng pack with that in XPS printer, that ensures a smaller 7z archive.
I believe you are familiar enough with .cmd so there is no need for me to explain further, all info is in the attachment.

Nonsense proposal (mine in this post before I edit)

I'm looking into the mysteries of NETWUFIXES.mst, NOFFADDONFIX.mst and REMFONTCACHEFIX.mst.
Here are some suggestions/questions:



I understand how REMFONTCACHEFIX.mst works, yet I haven't confirmed how Binary.FCSInstaller performs a RemoveFontCacheData action.

I don't know if you're 100% sure but it makes sense. Anyway, if there is any space for unsure, here is a supposed improvment:

AppSearch WINDOWS_IN_SETUP DetectWindowsInSetupProgress
RegLocator DetectWindowsInSetupProgress 2 SYSTEM\Setup SystemSetupInProgress 2
InstallExecuteSquence RemoveFontCacheData NOT WINDOWS_IN_SETUP
InstallExecuteSquence CA_remfontcachedata WINDOWS_IN_SETUP
InstallExecuteSquence CA_remfontcachedata_commit WINDOWS_IN_SETUP



for NOFFADDONFIX.mst since i don't use firefox but from what i read, it should work flawlessly.



for NETWUFIXES.mst I understand KB829019 and KB928416 well. but for KB928416, my test shows even if's not executed, once .NET 3.0 language pack is installed then it won't show in WU/MU, and if language pack is not installed but this fix is applied, it won't show in WU/MU too. Is this by design? KB829019 is Portuguese only so i didn't test it.

and for KB951847, i'm not sure what does it do. all i know is it prevents KB951847 from showing in WU but can explain why you're going to rename those msi files to specific file names(because i renamed them back and KB951847 is still not showing in WU)? any info/link you can provide will be helpful. TIA.

and just out of curious, why don't you make NETWUFIXES.mst seperate ones and pre-applied them to the msi files? KB829019 for Portuguese .NET 2.0 lp, KB928416 for .NET 3.0 lp(for blocking lp?), KB951847fix1 for .NET 3.5 with KB958481&958483&958484, KB951847fix3 for .....(don't know, maybe all language packs?)

and a typo in NETWUFIXES.mst:
InstallExecuteSquence CA_KB951847FIX3b ( ProductLanguage=SystemLanguageID ) AND ( ProductVersion="3.2.30729" ) AND ( NOT REMOVE OR ( REMOVE AND ( ( LNG20="#2" AND KB958481 ) OR ( LNG35="#1" AND KB958484 ) ) ) )

About Binary.FCSInstaller, I cannot confirm it to you, I cannot decompile it, just an entry point from it is called and 2 errors happen in certain circumstances that implies CISDL reference for font cache file folder not to be resolved. I managed to substitute its functionality. That's all.

NETWUFIXES.mst, about KB928416, obviously this is the intention (block 3.0 SP0 langpack update), it just do the work, same for KB829019. The fix for KB951847, as the guide states, simulates that the parts not installed of the set of files KB951847 is able to cover, are installed, and do it in a seamless manner covering possible install condition changes, thus allowing to avoid install unwanted framework versions, avoiding its updates from the update system as well, i.e. not breaking any rule nor any previoous behavior but KB951847. About .msi renaming, is part of the simulation it was needed to achive results. No link I can provide, I developed this by myself.

Why do I not atomize NETWUFIXES.mst? for the confortability of managing everything in 1 single tiny file, plus this fixes refers to framework versions packed in redistributable packages. This way is how it was at first, until new requirements makes no longer possible to build everything in a single file. Why I don't pre-applied it? Sincerily I haven't thinked of it before because I didn't need it. Maybe I do it in the future, specially if I found benefits on it, but not for the next version.

I don't see any typo, at least in the last modified 2009 08 25 I've checked.

Cheers.

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:

change 2052 to current system language first.

Test I'm doing indicate you're right with .msi renaming, but if this .msi names are standard with original installers, they will be through installers of this script, less potential problems, and this should be the reason why I included it. I don't recall exactly every reason why I did each thing like I did it, but there would be one or I wouldn't have not included it, your questions is offering me the opportunity to clarify it; and, is .NET 2.0 langpack inapropriately pushed or are you just being methodic?

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.

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.

do you mean KB829019 is a SP0 language pack, too? then why not block it?

EDIT: just downloaded it, yeah it's SP0.

Because this is the first notice I have on it appering on non PT-BR language OS-2.0 langpack combo.

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.

So not new problem, the problem just seems to start because I'm just not covering the 2.0 langpack uninstall happening. OK. I'll check.

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?

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.

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

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

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.

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.

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

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?

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've edited post #342 above about the folders. I didn't remove dwsens.dll entries from debugger removing file, I suppose any other application can suscribe to SENS through this DW.

Work fine before versions 20090826b and 20090913 but now WU show KB829019 for 2.0 SP0 PT-BR langpack in optional.

0d

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).
Click to view attachmentClick to view attachment

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. Click to view attachment
and have you noticed the table "SensSubscription", don't you think dwsens.dll is relative to it?

2 0d14r3

Let's see that. NETWUFIXES containing that fix last changed in 2009 08 25 but the part referring to KB829019 fix was not modified. I suppose you are using installer containing 2.0 SP2 framework, and that is updated properly, otherwise you could received a message during installer building saying KB951847 will not be applied, and if that happened this should be the cause, because both fixes came in the same pack; check the installer too, uncompress it to see whether NETWUFIXES.mst is in the same forlder as INSTALL.cmd or not.
Is the following value in the registry?
HKLM\SOFTWARE\Microsoft\DevDiv\URT\Servicing\1.1\RED\1046\Install
It should be of type DWORD with value 1. (that's KB829019 fix)

2 YumeYao
Obviously SensSubscription is absolutely related to dwsens.dll functionality, it is used to suscribe office debugger to SENS, but apparently is not part of the office debugger itself. What I say is that this library may be used by other .NET software appart from office to suscribe to SENS later. Or maybe the software that use it came with its own copy to do that. That's what I'd like to know.

In your 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst you removed dwsens.dll and the custom actions related, that's in question. But you removed CreateFolder:
TARGETDIR CSharp_Watson20_Reg_Keys_____X86.3643236F_FC70_11D3_A536_0090278A1BB8
VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 Watson20_Error_Logging_____X86.364......
They are related to the components of the feature where office debugger resides that we concurred should not be removed. And in Directory:
VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 TARGETDIR .
In addition to its related CustomAction and XXXExecuteSequence entries.

In your 20SP2_REM_VC8.mst
I see your point removing sxs related folders left, and its related custom actions and XXXExecuteSequence entries.

And a trick to use Insted with .mst files, the time first you tell Insted where to save the .mst file is actually not saving anything until you make changes and then save, so does not present the window of related entries when you removed them, but when I opened Insted with a previously saved .mst it does it.

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.