strel

Seems OK.

KikiBurgh ALSOINSTALLERS=YES takes effect only if one or both of T13ADDONS=YES and/or ROEADDONS=YES are present. In this case also output installers (.exe file(s)); add-on(s) setting(s) =YES normally don't give them as output (because you can extract them from the add-ons); with no add-ons settings =YES script gives installers (.exe file(s)) output. Everybody I'm interested in knowing if any of you use an OS (host or target) without Workstation service running, or with this service removed completely, as this method, in the last versions, is relying in this service to determine OS version (host and target) for building process and resultant installers/add-ons (except during setup process) respectively. May this require a change.

New version released. Bugs fixed and new features added, specially support to build RunOnceEx add-ons. Let me know if you find bugs. Enjoy! Kiki Burgh You better use new version. It seems you are in the right path with your process. I'm not a user of HFSLIP, but I think it need switchless installers for HFSVCPACK, so you'll need .exe installer(s) only. And 1.1 superseeded 1.0 SP3.

The script set all possible/needed settings not defined by .ini file to be able to run if the .ini file is not present. I recently fix the script for the .ini file to adapt to .ini standards but didn't fix this issue, i.e. after ; the setting is now bypassed in the .ini file but the script set default value later anyway. I'll change this for the next version. About NetFx20SP1_x86.exe & NetFx20SP2_x86.exe, keep them if you want to, along with dotnetfx35.exe, but then change .ini settings to process 2.0 framework only from one source (single or redistributable). Both 2.0 framework process settings are yes at the same in the original .ini file, because It is not expected the user to download 2 different sources (single and redistributable) to process 2.0 framework from (and in that case an error message is displayed). It is intended for the user to be able to start the process without changing the .ini file for the general use. I'll keep it.

Don't use ; before settings in the .ini file, the script makes all possible settings yes by default unless the .ini file set another value (empty included), this was probably causing you errors when you put NetFx20SP1_x86.exe and/or NetFx20SP2_x86.exe along with dotnetfx35.exe in the work folder. I should change this. Apart from that, when I set correctly a 2.0 framework to be processed from one possible source, the script process 2.0 hotfixes without problems in my case. I'm getting messages: Processing NDP20SP2-KB958481-x86.exe... Processing NDP20SP2-KB974417-x86.exe... About KB951847, yes is an ad-hoc update for 3.5 family, but this family includes KB958481. And you're right KB971111 is a 2K only hotfix.

Any NDP20SP2-KB*.exe present should be processed if any 2.0 framework is being processed, is it not your case? Better you include NDP20SP2-KB971111-x86.exe or it will appear in the update system.

NetFx20SP1_x86.exe and NetFx20SP2_x86.exe are not going to be processed if 2.0 SP# framework is being processed from dotnetfx35.exe.

You are building an add-on for nLite-RVMI, for HFSLIP you need a switchless installer I think, you can extract it from the add-on. You didn't include 2.0 regular hotfixes so they will appear in the the update system in addition to KB951847 because KB958481 is not being applied.

It is quite obvious you have PROCESS_DNF20 and PROCESS_DNF35_DNF20 to choose, anyway will be clarified for next version. If you want to process all the frameworks you can get rid of NetFx20SP2_x86.exe and to process 2.0 from dotnet35.exe without changing the .ini file. Settings under PROCESS MAIN PACKAGES marked to YES only work if the related package is in the work folder, no matter the setting unless you have the packet. If you have NetFx20SP1_x86.exe and NetFx20SP2_x86.exe in the work folder and PROCESS_DNF20=YES, 2.0 SP2 is processed and you are advised by the script (add a prefix e.g. -NetFx20SP2_x86.exe and NetFx20SP1_x86.exe will be processed). For dotnetfx35.exe, both versions have the same filename, you have to rename the one you don't want to process for both to be in the work folder.

My2GirlsDad Oops, I used the pre-checking setting to trigger 3.5 SP1 family frameworks processes, bad idea. It only affects this case. Will be ready for next version, I'm testing now. Thx for the heads up. Killgore I claimed victory over KB951847FIX atomization too soon. I'm testing a new version fixing this now. Thx for you help. Kiki Burgh Your problem is simple, you have put 2 different .NET 2.0 framework sources in the work folder. The .ini file is set to process both what is not possible, but it is intended that you have only one of them in the work folder or you to change settings. You have to choose which one to process from.

fdv's guide may help you.

New version released!! 2 minor bugs removed. mooms Thx a lot!!! You helped me a lot finding one of the most slippery bugs I have had with this method. I dropped a wrong single digit in 30SP2LNG_KB951847FIX.mst causing your (and everybody's using 3.0 SP2 langpacks) problem. What's happening is that it was failing to remove 1 regvalue used as KB951847 fix for 3.5 SP1 family langpacks, only in the case 3.0 SP2 langpack was the last langpack from this family to be uninstalled (tricky). But the error appears not only in that circumstance, because it is triggered when the script to execute is not found, whether it has to be executed or not. What's curious is that it seems the error dialog is only showed sometimes because only sometimes makes the langpack removing fail (go figure), what's your case, or at least is what your log says, though you say you could managed to remove it successfully. That's not my case for example, though the error was in the uninstall log, it didn't make the uninstall fail (log says), hence didn't show the error dialog. thnx4thepen Sorry I think I linked 3.1 version instead of 4.5, I fixed it. About your freezing, what can I say, I think it is something with your windows installation. It is not happening to me. Had you restarted after installing windows installer and before installing .NET? Anyone over with the same problem as thnx4thepen ????

Then generate a verbose log. Do this: - Install 3.0 with its langpack. - Open a command line a type: msiexec /x{0BD83598-C2EF-3343-847B-7D2E84599128} /l*v %TEMP%\DNF30LNGFRuninstall.log And then attach %TEMP%\DNF30LNGFRuninstall.log.

I don't see anything strange in process data. None of those logs is the uninstall log we're searching. It should have the form of MSIXXXXX.log, mine has 417KB. Should be generated by 3.0 langpack uninstall, you can identify it easily if you go to the end of the log. One of the last lines should say something like: (s) (C4:B8) [20:24:35:494]: Produit : Microsoft .NET Framework 3.0 Service Pack 2 Language Pack - FRA -- Suppression effectuée.

It seems you have a lot of space, what about this?

I cannot recreate it. I created a 3.0 SP2 installer with fr langpack, installed it, uninstall 3.0 langpack and no error is showed. Looking for the error reference, this reference means "Custom Action not found in binary table stream", that means that there's an executing action in the .msi installer database that doesn't find the built-in script it has to execute for this action, that's why I though any of the .mst (transform files, i.e. some of the fixes this method applies) that transform 3.0 fr langpack .msi installer, would had a bug, what's pretty feasible (too many files I've made), but doesn't seem to be the case, at least with the latests files I'm using. Have you overwrited all previous files when you extracted 20091104c packet? Can I have the uninstall log file? %TEMP%\MSIXXXXXX.LOG, check date and hour. Can you attach .\OUT#\processdata.txt ?

What error? About not being able to uninstall? About not finding msi installer? About font cache (ShGet... or GetFont... or something similar)? The 3.0 you have uninstalled with error had been built with the latest version or with a previous one and then you used a 3.5 of the latest? Anyway if there's no trace I think you may even not find it again if you repeat. I am not having this error. Anyone else?

thnx4thepen I can do it without errors for the same files. It is a problem with your windows installer. Try this: open a command line and run: msiexec /unregister then msiexec /regserver and then try repeating the building process. If this don't work try reinstalling windows installer by running: msiexec /unregister then reinstalling windows installer and restarting and then try repeating the building process.

No, you have to use both if both .NET 2.0 SP# and 3.5 SP# are used. Both runtimes are complementary and prerequired for their respective framework versions. You can only choose to install them from the .NET frameworks (outdated) or to remove them from .NET to preinstall them from external packets (updated for the files in VC file group of supported files list). About this, I have not tested Code65536's nor Kel's runtime packs with SNMsynth installers/add-ons with VC removed. I suppose both are OK with this method, but any experience anyone have on this is welcome to confirm.

New version released!! Uninstall bug fixed. mooms I inserted 2 wrong lines when reverting cached installers renaming removal of 3.5 SP1 from 20091029, and this seemed to be the problem. I was experiencing this problem but I though it was a problem with my engineering system as nobody was complaining even when I specifically asked about it, posts ago. Thx a lot for your help. Raoul90 Yes, this is an updated source, and as it is marked to be processed, it will update MSXML6 for 3.0 framework. XPS (XML Printing Specification) is a printing architecture for printing natively XPS format, a somewhat similar to postscript or PDF vector document format from MS, that I suppose it is being integrated as a native format on printers (as postscript) and printer drivers is being made for it. XPSESPC (XPS essential pack) is the subcomponent annexed to .NET 3.0, it server as a framework for XPS printing drivers. You can update it with the ad-hoc hotfixes in supported files list. Obviously don't harm. Another 3.0 subcomponent, WIC (Windows Imaging Component) handle images for XPS format. About the combined VC installer you made, this is exactly what RogueSpear's combined installer is (in supported files list). It uses switches to choose passive/silent mode. I tested with it the .NET without VC installers, and worked fine.

Prego. What packet(s) have you used to preinstall VC?

If I do exactly what you do, with the same settings (except compression-ratio) and the same files in work folder, the update and SP3QFE folders are appearing in XPS folder. Do this: Set the .ini file to process only 3.0. Open _SNMSYNTH.cmd and replace the line @ECHO OFF at the beginning, with @ECHO ON Open a command line in work folder and run _SNMsynth.cmd > process.log 2>&1 (I edited this command, use this instead, sorry) Attach OUTPUT.TXT after process finish. Revert line replacement. Use latest version to do this. May XCOPY not be available for some reason?

thnx4thepen Can you confirm this file is where it is supposed to be? I mean try uncompressing the installer and look for this file in its folder. Has the building process output showed "Updating XPS driver with latest files from XP+2K3 KB971376..." message?

Fixed minor bug (not harming at all) putting some not needed fixes in the .\TMP folder. New version released! Glowy I made a fresh test and KB951847 is not appearing in win/ms update for me. I need more data.

Good point Kurt, forgot to include the target os in name for T13 add-ons. Fixed now. New version released!