strel

Updated. Enjoy.

Are similar.

I've got to review the guide, you're not the first to say it to me. A1: This means the script can handle updates of this types for 1.1, specifically of the types MS make available to us for 1.1 nowadays, all are in the list. A2 & A3: There's no SPs standalone, in every case it is the complete framework updated to that SP#. The script only admits one dotnetfx35.exe. Choose your update condition. If you use NetFx20SP1_x86.exe and any dotnetfx35.exe , you have to choose which of the 2.0 SP# versions contained in these packets you are going to process, the script cannot be fed with two different steps (SP#) of the same framework #.# , even not with the same step (SP#) of the same framework #.# from 2 different files. A4: To get FULL merged installer, apart of feeding the process with the correct frameworks you want (this is matching correct packets in the work folder with the settings in .ini file that triggers the process of the frameworks contained in it that you want), you have to set MERGE_FRAMEWORKS=full in the .ini file. Configuring the setting this way only build the full installer you want if you fed the process correctly, if not the merged installer would be partial only. In your list you repeat: NDP20SP2-KB958481-x86.exe NDP20SP2-KB958481-x86.exe ----> You need NDP30SP2-KB958483-x86.exe and: dotnetfx35.exe (231Mb) ... NetFx20SP1_x86.exe ---->Last version of 2.0 is 2.0 SP2 contained in dotnetfx35 (231 MB). You can delete this file or empty PROCESS_DNF2 not to feed the process with it. The script deletes automatically files generated in an incomplete or wrong, building process. A5: You can make full single switchless installer in one run. Another uncommon results like merged 1.1+2.0 + merged 3.0+3.5 needs 2 runs. Don't know of any combination requiring 3 runs. Is that Azerbajan, isn't it? Good luck.

You have various possibilities: 1. .NET Framework All In One x86 addon. 2. RogueSpear RunTime Collection, you have to register. 3. And my favorite Silent .NET Maker synthesized.

You'll find this method updated in Silent .NET Maker Synthesized. For now on you can build updated localized ad-hoc nlite add-ons with that in an automated process.

.NET 3.0 SP2 language (for some languages) There's problems when installing 3.0 SP2 from .NET 3.5 SP1 redistributable under some XP x86 localized versions: - If you install english version (dotnetfx35.exe /lang:ENU), windows/ms update prompts you to download 3.0 SP0 langpack standalone. - If you install some language to the english version windows/ms update prompts you to download the same 3.0 SP0 langpack standalone KB928416: ---> when installing dotnetfx35.exe normally, the installer downloads the language files, if you're connected, obviously ---> or when you install it from .NET 3.5 SP1 langpack standalone ---> or when you install it from a 3.0 SP2 language administrative install (aka SNM installers) generated from standalone langpack In all install scenarios of 3.0 SP2 under hungarian XP are the same. So, what's happening? I think there's a problem with 3.0 SP2 framework under some XP X86 (maybe 2003 too). It doesn't matter how you install it (with or without language), windows/ms update prompts you to download 3.0 SP0 langpack standalone. And if you're going to use SNMSynth 3.0 SP2 installers under some localized XP (and maybe 2003, this has to be checked) and you want to get freed of win/ms update prompting to install 3.0 SP0 standalone language KB928416, I recommend you to use the method described in the "Obtain a Clean or Customized DataStore.edb File" section of this guide. EDIT: I recommend to use the latests version the script that fixes this issue. At least until MS fix all this. Thx 4 your help fenyo. Anymore ideas?

These 4 are not present in many other langpacks with the same structure, and don't generate problems. I don't think they are culprit of anything.

Yes, correctly for updated complete set of .NET frameworks for XP or 2003. This merged installer should be used on first logon.

2.0 SP#, 3.0 SP# and 3.5 SP# are not SPs are full frameworks versions (each one) updated to this SP# (of its own). You probably are trying to build updated installers for XP. Download 3.5 SP1 redistributable and updates for 2.0 SP2, 3.0 SP2 and 3.5 SP1, you don't need 3.5 redistributable (2.0 SP1, 3.0 SP1 and 3.5) unless you want any of the versions outdated. You don't need need NetFx20SP1_x86.exe because you have one 2.0 in .NET 3.5 SP1 redistributable. OK? It's easy believe me.

3.5 SP1 packet=3.5 SP1+3.0 SP2+2.0 SP2, that's all. Better to include updates for this.

Caspean, you need to feed the process with only 1 SP# of each .NET #.# version. So you have to find the correct matching of packets-in-work-folder/settings-in-.ini-file that feed the process correctly. Only packets with it's original filename can be processed. Read carefully the notes in the .ini file that explain what trigger each setting.

7-zip SFX modified and msistub.exe are authored by Oleg_Sch who include the function of the second in the first, so it shouldn't be a problem.

I could check that both dotnetfx35langpack_x86hu.exe (SP1 version) and NetFx30SP2_x86hu.exe have the same structure in patch.cab inside ..\netfx30lp\WCF_HUN.msp ..\netfx30lp\WPF1_HUN.msp files resulting from both extractions of language packs above (3.0 SP2 portion is almost equal); patch.cab files that doesn't contain files correponding to these 2 pair of files respectively. Moreover NetFx30SP2_x86hu.exe lacks file XPSEPSCLANGPACK-x86-hu-HU-langpack.exe. This file is installed when 3.0 SP2 language is installed from dotnetfx35langpack_x86hu.exe (SP1 version) langpack. But the install size indicated under Add/remove programs is not affected by this file, thus 3.0 SP2 language installed from NetFx30SP2_x86hu.exe shows the same install sizes, 3,8 MB and 10 MB, installing it through admin install (aka SNM installers) or directly, respectively. So NetFx30SP2_x86hu.exe, is not offering any advantage, rather the opposite. But now this doesn't seem relevant to me since I could check there's other dotnetfx35langpack_x86XX.exe (SP1 version) langpacks that lacks the files of the first paragraph, for the 3.0 SP2 language portion, like turkish, italian, russian, chinese simplified... And installing 3.0 SP2 language from this langpacks, indicates the same install size when installed from admin install (aka SNM installers) as well as when installed directly from the langpack. So I didn't checked all langpacks with this structure, but it seems the wrong behavior only happens with hungarian language admin install for 3.0 SP2. Anybody want to add something? I should add that the file fenyo was prompted to download from MS Update, when 3.0 SP2 language is installed from admin install (aka SNM installers), this is, showing 3.8 MB installed; wasn't the same 3.0 SP2 language standalone, as stated before, but 3.0 SP0 language standalone. This happened only under hungarian XP, not under english XP (with .NET hungarian languages), to make things even more strange. EDIT: Check post #59 for updated info.

I think continually if we don't manage the way for they to appear in the admin install of 3.5 SP2 language from 3.5 SP1 langpack. And I don't think MS earns nothing with this. I though it was for updating stand alone 3.0 or 3.0 SP1 installations, but this doesn't explain the absence of some languages.

These 4 files exists only in the admin install of languages other than magyar, not after intalling in the OS. About the stand alone 3.0 SP2 langpack, to me it's a nonsense, why some languages have it and some others not? I'm not confident in any way with that packet.

Yes, until MS releases .NET 4.0, probably during this year.

Use intallers for all the frameworks in your unattended set. You can rarely use an application that needs 1.1 but if you want to be sure include all. You can use the full merged installer or individual installers, read the install rules.

Nop. I don't use it. But the basis of the script are the same old admin installs. After having a quick reading on HFSLIP basis, and take a quick look to the HFSLIP script, I think resultant installers from synthesized version should work too without problems in HFSLIP. Any of you using it can confirm it. So, please... I realize switchless feature is intended for using installers with HFSLIP, as I suspected. For future updates, I'll keep this feature to maintain compatibility with HFSLIP, but optionally, this is, people who don't use HFSLIP will can have unique set of installers that could be switched from silent to passive.

I thought this was an update, sorry. Well no idea why microsoft is releasing another language pack for 3.0 SP2, but it should be fine. Although the script don't support it at the moment. Let me do some test. But I really have no idea of what this last langpack is made for, and why it only exists for some languages.

I hadn't seen it. OK. I didn't know this update, but I think it is not included there, first, for size, and second, this update don't exist for spanish language but for danish. In danish I've checked these files are created in administrative install, and third, where are the MB lost among administrative install and normal install?. It's something with the hungarian 3.5 SP1 language pack.

I think these files are contained in the langpack for 3.5 SP1, but for some reason not extracted in the administrative install (which is the one used by this script). The update for 3.0 SP1 langpack is not for this version.

These files you point are not in question, they are present in spanish and danish versions too. The problem is with that I told you. You can find them in administrative installs of 3.5 SP1 langpack except for magyar.

fenyo, I found differences in installers including 3.0 SP2 magyar language, with installers in other languages (specifically with spanish and danish with which I compared). When processing magyar language these 4 files doesn't exist in the installers: DNF30\LNG\Win\Microsoft.NET\Framework\v3.0\WCF\MUI\040E\ServiceModel.mfl DNF30\LNG\Win\Microsoft.NET\Framework\v3.0\WCF\MUI\040E\ServiceModel.mfl.uninstall this files exist in other languages, in its correponding folders (...\040E\... , the name of this folder depends on language used); and DNF30\LNG\Win\Microsoft.NET\Framework\v3.0\WPF\NlsData000a.dll DNF30\LNG\Win\Microsoft.NET\Framework\v3.0\WPF\NlsLexicons000a.dll exceding 9 MB each one.

2 Belak51 I'll review all this in the next update, soon. About 2.0, I suppose you're meaning removing 2.0 SP1 packet, I can't, it's needed for win2K. 3.5 redistributable and 3.5 langpack (not SP1) are better candidates for removing. Thx. 2 jweetje 64 bit stuff is removed from the installers. Thx 2 U, happy 2009. 2 0d14r3 I supposed it. Thx 2 U. 2 fenyo I got the same results. But, what do you exactly mean when you say Microsoft Update don't recognize it, does it offer to you 3.5 SP1 langpack for downloading? This is not my case. I don't know why this happens. All I can say is I don't see errors installing, and checking the building process, it ends up without errors, apparently. I'll keep searching. Thx. 2 Jediron Depends on the software you run. .NET is only for software that is made for using this frameworks ("managed code" in MS jargon). Not all software use .NET and not all software that use .NET, use the same #.# version. Maybe the software you use, needs only 2.0, but for ongoing updates of that software, the developer may update the code to a later .NET version. For example, paint .NET have changed its framework needs from 2.0 to 3.5 in recent versions. Up to you. Thx.

You see the script supports the processing of different packets with different versions of 2.0 built-in. The script is set for you to chose only one packet source to process 2.0. What source? the one you need based on the version of 2.0 you want, for example, if you want the more updated version of 2.0 for win2K3, then you need .NET 3.5 SP1 redistributable packet with 2.0 SP2 built-in and set the PROCESS_DNF35_DNF2=yes in the .ini file, but if at the same time NetFx20SP1_x86.exe is present in the work folder and PROCESS_DNF2=YES in the .ini file, you'll get an error. To disable a setting in the .ini file you can empty the value or add whatever you want, it only recognize "yes", case insensitive, as working value, read notes inside .ini file. About languages, to process the language for some framework version, you have to process it from the langpack related to the packet from which this framework version proceeds, even though the language for this version is contained too in another langpack. In the .ini file, settings to process languages only works if the correponding langpack is present in the work folder (obviously), and the framework related is being processed. So no crossed source packets of languages and frameworks are allowed to be processed, unlike Tomcat' original script, as notes inside .ini file states. Again, read it. Differences among flavours are obvious, as described in the guide. The silent installers are absolutely silent, if you use this silent installers over and installed windows, you'll need to open Task Manager to monitor the unzipping and installing processes or you may not notice it; while loud installers shows progress bar boxes for unzipping and installing processes. You have to match packets present in the work folder, with the setting that triggers the processing of a framework built-in it, to feed the process with a specified framework, see notes inside .ini file. You can merge 1.1 with the 2.0 SP# you want, the process is a lot flexible. You can even use MERGE_FRAMEWORKS=fuLL to do this, not feeding the process with 3.0 and 3.5 versions. If you want 1.1 and 2.0 merged, and 3.0 and 3.5 in single installers or merged apart, you have to run the process, at least, 2 times. If you didn't feed the process with 2.0 but only with 1.1 and its langpack and set MERGE_FRAMEWORKS=12 you should get DNF11xx.EXE. If you want to merge 3.0 and 3.5, set MERGE_FRAMEWORKS=fUll and feed the process only with 3.0 and 3.5, do it disabling PROCESS_DNF35_DNF2 as dotnetfx35.exe (containing 2.0 SP#) needs to be processed. You can merge all frameworks in one installer. You can use all resultant installers during unattended setup or over an installed windows.