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

[strel]

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.

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.

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.

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

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.)

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.

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.

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

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.

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:

EDIT: from what i read from XPS Printer's install package, it's not installable on Windows 2000, is that correct?

Never tried it. Edited September 16, 2009 by strel

[YumeYao]

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.

[strel]

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.

Edited September 20, 2009 by strel

[YumeYao]

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.

remove_vc8_in_dotnet20.mst

[strel]

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.

Edited September 16, 2009 by strel

[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.

[strel]

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

Edited September 18, 2009 by strel

[YumeYao]

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.

Edited September 18, 2009 by YumeYao

[strel]

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

Edited September 18, 2009 by strel

[YumeYao]

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.

extractandmodify.cmd

[strel]

Nonsense proposal (mine in this post before I edit)

Edited September 18, 2009 by strel

[YumeYao]

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 ) ) ) )

Edited September 18, 2009 by YumeYao

[strel]

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.

Edited October 1, 2009 by strel

[YumeYao]

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.

[strel]

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?

Edited September 19, 2009 by strel