strel

Hi. In your "Support discontinued" list, you should include .NET 2.0 SP2. I found that, though not officially supported as stated in the download page, it actually works on windows 2000.

joaco, I think you still have to edit SFX-MSD.ini as stated in point 3 of the Issue 02 section. Good news are that you have the URLs you need in MSDownloads.ul file inside MSDownloadsESN.ulz Suerte.

Link is in the instructions section bellow in the guide, and is apparently working. Thx for your interest.

Updated. Enjoy!

karmatron, first I didn't know this article, I'll see what can I do with it. Thx. But SNMsynth's add-on you used (if made with latest version of the script) include a fix to avoid win/ms update to push KB951847, and this update is what it is going to install 3.0 SP2+3.5 SP1+regular hotfixes for both (and for 2.0 SP2 if you didn't apply them)+langpacks for both, in your case. This fix makes win/ms update think the previous set is installed. If you apply that "BlockSP" reg key, you're applying 2 different fixes to avoid intalling 3.5 SP1 through KB951847 at the same time. And I suppose this should be the cause KB963707 is being pushed, because there's a fix included in that add-on too, for making win/ms update think KB963707 is installed (as it is thinking 3.5 SP1 is installed, so that KB963707 should be applied), that seem not to be working when you apply that reg key. And again, I suppose you're referring to WU and not WUD (Windows Update Downloader) that is another piece of software not related with all this. EDIT: While doing my tests I remembered I was playing time ago with this regkey when looking for the KB951847 fix and I finally discarded it but I've forgotten the reasons that led me to this. Now I realized the reason why I did it. Using the block regkey is not a perfect solution from the point of view of consistency. While it is far simple to use that regkey than to simulate that absent frameworks (from the group of KB951847) + their regular hotfixes + their langpacks (matching OS language), are installed (method used by SNMsynth installers), it doesn't allow to happen things like this: Imagine you use SNMsynth installer to install .NET 2.0 SP2 + its regular hotfixes + its langpack (matching OS language), i.e. making KB951847 fix applies simulating 3.0 SP2 and 3.5 SP1 + their regular hotfixes + their langpacks (matching OS language) are installed, thus removing KB951847 prompting you to install this framework versions from win/ms update; then you remove 2.0 SP2 langpack, at this moment you should be prompted by win/ms update to install 2.0 SP2 langpack through an ad-hoc KB951847 update, but if you use that block regkey method, you won't be prompted to do that.

Hi karmatron. I didn't understand you first time, you mean I can substitute second and third regkeys with first one. Is it that? I think it is not enough to avoid KB951847 as the fix included do in case you are not having all 2.0 SP2+3.0 SP2+3.5 SP1 installed, but anyway I'll give it a go. This fix makes win/ms update (not WUD that's another useful piece of software) believe the whole set are installed, and this should cause update system to push KB963707 if another fix avoiding this were not being applied. And thx for your interest.

There's a bug processing 1.1 and 2.0 SP2 hotfixes, write KB instead of kb in the filename and you won't get this error. I'll release the update soon. Cheers.

20something letters in the alphabet, hope I don't have to waste all. Doh! =) Fixed now.

An error fixing the error, not my day, douh! Fixed now.

I found incomplete checkings of 2.0 SP2 hotfixes when the source is the 3.5 SP1 package. If you were not applying KB958481 you may have been getting problems with KB951847 being pushed by update system, without advetence during the building process. You may have got too dialog windows errors if you were applying the latest 2.0 SP2 restricted hotfixes. Now it's fixed in the released new update. Enjoy!

I usually do that kind of things with ccleaner, and have it scheduled to execute regularly.

Seems like the same error in the same second. The script avoid waiting to idle time to execute the process of compiling assemblies, what the installers normally do. That's what this process does, including errors, is not an issue of executing at T-13 you'll get these errors at any time of setup and out of setup. Don't worry, doesn't harm install, and in case something was missed, compiling will complete later in idle time. And you can always install updated XML out of the .NET install. 2 all I updated the realease version in the header of the script without renewing version. Those of you who downloaded first can change it manually to 20090820. No more changes.

2 bruno32600 You're right, in addition to the %'s, one parenthesis was missed. Thx a lot. 2 peoman 1. I discovered a bug detecting the OS setting from _SNMsynth.ini, but in your case is not affecting at all. 2. I've made my test and the installers work perfectly with the same conditions you posted. I think you have not checked Task Manager to see if there was installations running because the installer is absolutely silent and takes some time to finish. Check your Add/Remove Programs too, and refresh from time to time, you'll see the frameworks appearing as they get installed. Thx a lot. EDIT: Sorry forgot to mention I did the test after fix bugs bruno pointed. That's what's failing for you too. New update released! Enjoy!

I'm interested in registry hive patching. The download link is unavailable.

You've got SNMsynth sticky above in the forum.

New update issued! All previous bugs fixed and added new features. I've tested it deeply but maybe something is missed, let us know. Enjoy!

Didn't know about its existance since it is not pushed by update system and it isn't a restricted hotfix, but I bet you can apply it with actual, SNMsynth. Thx.

That late... As long as you don't mind receiving dialogs in english, it's optional. I'm testing now the next update...

As I said above that's the process of compiling assemblies, the only difference is that you are now seeing what the process does, it's the result of ngen.exe /executequeueditems command execution for processing the queue inmediately, not waiting to idle state. There's nothing there a vanilla install process wouldn't do, except to avoid waiting. The installer assemblies tables points to some void entries causing that errors, you're not supposed to see them, so I don't know if there's a reason for them, but sure it doesn't make any harm.

mooms, are you sure you were not playing with the addons? I'm lost, CA_KB928416FIX2 is only supposed to execute on uninstall because of an execution condition. And I didn't get those results in the past (I'm not using a non-english windows to test conditions like this now). By the way you can test with this:Uncompress the addon to a folder, then the installer under SVCPACK folder, and in the remaining forder substitute NETWUFIXES.MST with above one. This new file doesn't change anything but slightly modify the execution conditions about detecting install/uninstall process in a equivalent way, for them to be more restrictive. Last, install through INSTALL.CMD and tell me whether event viewer keeps showing that error. About the error messages arisen when showing the install window, they are simply the result of the execution of pending assemblies compiling tasks without waiting to idle state. That's how the installer is made, ask MS, there's some entries in the installer pointing to void, maybe there's some reason for it, I don't know. But they don't make any harm and don't generate errors in the event viewer nor the install/unsintall logs.

Look here: http://7zsfx.info/en/

This is for PDA and mobile devices. Theutlass, what dev stuff are you referring to?

You can try making an administrative install and then applying the patch files. Something similar to this: msiexec /a adobereader.msi TARGETDIR=..\destinationpath msiexec /p dbeRdrUpd814_all_ce_incr.msp /a ..\destinationpath\adobereaderadmininstalled.msi msiexec /p AdbeRdrUpd815_all_incr.msp /a ..\destinationpath\adobereaderadmininstalled.msi msiexec /p AdbeRdrUpd816_all_incr.msp /a ..\destinationpath\adobereaderadmininstalled.msi

My browser sorry.

I don't see them since yesterday.