strel

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

Now seems to work, you were right from the beginning, it was the test version of the script I'm using, I didn't notice it was inserting the property in the command line. Install errors from .msi with sxs tables removed were caused because the sxs binary was no removed as predicted.

I though this key could be the cause, but seems not to be causing the problem

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.

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.

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

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.

Wait!!! not that fast, I'm removing both properties in the .mst files and preapplied them to .msi, do admin install, and get .msi with both properties removed, checked, ready to install, but after install now SystemComponent reg value is set to 1, and this regkey was removed from registry in the previous uninstall, again checked. EDIT: Strange, that's only happening for 3.5 sp1 .msi not for langpack or for 3.5 or its langpack. There's still hope.

I don't use anyone but noticed The Great Unattended Project that may interest you, though from what you said I suppose you're looking for a wider spectrum one.

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?

It's almost equal than mine, except I divide, slimming, and removing VC9 in 2 files, and for slimming, I haven't removed the properties, nor MsiSFCBypass nor SxsMsmGenComponents tables, just empty them because of that install errors I told you, but I'll keep testing, nor the Binary SxsUninstallCA (I haven't seen it, maybe it's the cause), and I'm still dubious about all that folder related CAs apart from that related with the FeatureExtensionData entry removed, they just set properties, and I have not checked they are not used at all in the process. And I suppose you're right with no NOVSUI property once removed it and with ARP related properties on install command. EDIT: I edited the resultant .msi files and removing of both variables are working as you expected, I obviously did something wrong, I should be crossing some tests in one install. I'm going to update the .mst file set and scripts to achieve that. EDIT: Read my next post.

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.

I don't know how do you apply this new update of your method to the .msi file; me just like SNMsynth, making .mst pre-applying .mst, making admin install, installing. Well, with the new update of your method I cannot make ARPSYSCOMPONENT property to write its regkey to 0 (again), I need to fix the reg after install. Moreover I don't see the point in using INSTALLLEVEL, I mean, this setting is meant to set what features run and what not depending of its install level; well I don't know if using it over the .msi when your are installing makes sense (I hope it isn't just bloat) but the way I use it with SNMsynth, i.e. for pre-modifying the .msi prior to make the admin install, it makes no difference. Or in other words I expected I could avoid the execution of whole NetFX35_EXP_enu_x86_net_SETUP feature with INSTALLLEVEL property while making the admin install, thus getting a slimmed down output with far less pre-editing the .msi files through the .mst files, but I cannot manage to do that, and I've tested deeply. I'm comming back to my previous .mst set to include the rest of the new changes that will improve it. Cheers.

It should be in %SYSTEMROOT%\SoftwareDistribution\Download but if the file is somewhat corrupted, you should be able to install the same packet manually downloaded directly from the web.

If you remove NetFX35_EXP_enu_x86_net_SETUP in FeatureExtensionData table, I suppose CSetupMM_NetFx35_x86.3643236F_FC70_11D3_A536_0090278A1BB8 should be removed in Directory table. And I'm only one of the authors of SNMsynth, I don't deserve this treatment.

Nonsense proposal (mine in this post before I edit)

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

I don't have it in this machine to check, but maybe to do aiming I'm pressing an ad-hoc key in mouse or so, but anyway possible.

You can notice the file you're looking for in %SYSTEMROOT%\Installer through the tooltips or through Properties/Summary. About your errors installing (haven't seen uninstall logs yet) 1704: Read this 2755. 1601: Read this and this to see if any of them match your case. About the first one, could installer be in an encrypted folder?, are you encrypting any folder around? Uninstall logs would be valueable too.

In %TEMP% you should find the logs. Not the logs you posted before. If you just try install/uninstall operation the last log in that folder is what you look for and it should have a random name MSIxxxxx.log. It would be of great help to understand what happens. By the way, have you checked if the .msi file for the framework version you were trying to uninstall is cached in %SYSTEMROOT%\Installer folder? If yes try msiexec /x %SYSTEMROOT%\Installer\thatfile.msi .

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

Too late.

But if your restrictions are to not use any external method than manual, and if you don't need any of the features that this method has, you can avoid embroilment by simply using the original installers in the windows setup process. The guide of this method can be useful to you, in this case to understand how to avoid potential problems, as what the guide says about .NET applies to the original installers.

Wait, I was wrong in one thing, XP SP3 OS has no .NET framework installed but there's one .NET 1.1 framework ready to install in the CD. Don't cruise the whole thread, all the information you need is in the first post. And if you want to know how things are done you only have to cruise the script (and maybe the .mst files if you want to know something about the fixes this method apply). And if you do this and have questions, simply ask.

Something like this is what I suppose Yzöwl is talking about.