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

[djanz]

Hey strel.. I just managed to modify your brilliant script so it created a x64 addon.. I will run some tests before I write instructions for what I did..

Btw .. There's atm only one thing I can point my finger at when it comes to your script..

When I do a clean install with a FULL (every hotfix possible) addon that's called from svcpack I see alot of leftover log-files from the .Net Framework installers.. They are:

NETFX11

NETFX11lng

NETFX20

NETFX20lng

NETFX30

NETFX30lng

NETFX35

NETFX35lng

Maybe there should be a cleanup subroutine included or is the leftovers there because of the design of the script? I.e. if something goes wrong?

One could just write something like:

del %systemroot%\*.txt

in the end of the install.cmd, right?

Or of course, since we have the names of the log-files just specifically delete each and one of them so nothing unwanted gets accidentally deleted...

Djanz

Edited September 10, 2009 by djanz

[strel]

Hi.

The logs are there in the same manner original installers left them in the %TEMP% folder, I just renamed and applied maximum verbosity to install logs only, uninstall logs are created automatically in the same folder by the installers, but are not renamed (I'm looking for a simple solution to do it from Add/Remove Programs but I'm not being able to manage msiexec.exe ... /l*v %TEMP%\NETFX##uninstall.log switch to work on the uninstall string). They are there to allow looking for errors in case it happened. I use a ccleaner scheduled task to remove them regularly on idle time. And of course you can use a del command to remove them.

About x64 add-on, maybe it's better you extract installers to test it, pay attention to the .mst files, Insted is your friend for doing that. Ask me if you have any questions.

EDIT: in fact the way install logs are stored is not exactly as the original one because install logs overwrite previous one for that framework/language, so there would less install .log files stored in the %TEMP% folder.

Edited September 15, 2009 by strel

[djanz]

I have now managed to build a x64 installer that installs the full .Net Framework..

Only thing I need to get around now is to prevent it from showing up on MU ..

Maybe I have to look into the mst stuff! Hoped I could have avoided it though hehe..

I will attach the modified script when I manage to get around MU ..

Further testing will be run in the weekend if I get time..

Once again.. Nice script you've made, its clean and simple, yet it manages to build the smallest installer possible..

I like the way you make people build their own installers.. Hate those premade "packs" with updates and installers..

You never know whats inside and maybe there's stuff in them you want to exclude/include in your own custom made Windows... Tsch..

Write you later...

Djanz

Edited September 11, 2009 by djanz

[strel]

Hi djanz.

OK. I don't know if regkeys or .msi database items to fix with .mst files have changed a lot from x86 version, if not you're lucky, otherwise it comes the boring part. You'll need to extract the .vbs files to understand what the CustomActions of .mst files do. The logic of the conditions to execute custom actions in the InstallExecuteSequence is a bit tricky. Ask me your questions.

[strel]

New version in da hood!

Managed to workaround the old 3.0 framework errors in the event viewer installing at T-13 (and later uninstalling), and managed to fix and to adapt YumeYao's method for slimming down 3.5 SP1 installers, among other things.

Enjoy!

Edited September 13, 2009 by strel

[kalaeimaigr]

Hello when i try to create a localized merged addon of 1.1,2.0sp2.3.0sp2,3.5sp1 plus updates and language packs, whith all updates present in my working folder, i get a message for NDP35SP1-KB963707-x86 that there isnt even if it is in the folder.Same for dotnetfx35langpack_x86.Ididnt get those errors whith the previous script .Any idea why this hapens.Thanks again and sorry for my english.

[strel]

Not getting that message. Please post your _SNMsynth settings and the file list in your work folder

Edited September 14, 2009 by strel

[kalaeimaigr]

My _SNMsynth.ini settings are

PROCESS_DNF1=YES

PROCESS_DNF2=YES

PROCESS_DNF35_DNF2=

PROCESS_DNF35_DNF3=YES

PROCESS_DNF35_DNF35=YES

PROCESS_DNF3_RGBRAST=YES

PROCESS_DNF3_WINIMAGING=YES

PROCESS_DNF3_MSXML6=YES

PROCESS_DNF3_XMLPSSC=YES

DNF_FF_ADDON=YES

PROCESS_LNG_DNF1=YES

PROCESS_LNG_DNF2=YES

PROCESS_LNG_DNF35_DNF2=

PROCESS_LNG_DNF35_DNF3=YES

PROCESS_LNG_DNF35_DNF35=YES

ADDON=YES

MERGE_FRAMEWORKS=yes

SILENT=

COMPRESSION_RATIO=

my file list is dotnetfx

NDP1.1sp1-KB867460-X86

NDP1.1sp1-KB928366-X86

NDP1.1sp1-KB947742-X86

langpack

NetFx20SP2_x86

NDP20SP2-KB958481-x86

NetFx20SP2_x86el

dotnetfx35

msxml6-KB954459-enu-x86

NDP30SP2-KB958483-x86

NDP35SP1-KB958484-x86

NDP35SP1-KB963707-x86

dotnetfx35langpack_x86el

[strel]

Still no luck. You didn't include file extensions, I hope they're right. No idea what's happennig with you. Can I have a screenshot?

In my case the process run smothly except 1 bug I found applying KB963707 introduced in the yesterday release, and one minor issue removing unexistent files. But nothing about script requesting files actually present in the work folder.

Bugs fixed now. Download the new version!

EDIT: I forgot to remove 3 pause commands I use for testing, I've updaloaded it again. The first 9 who downloaded it, excuse me for the inconvenience

Edited September 14, 2009 by strel

[cyberyeye]

Hi Strel !

First... thanks for your script

I had a question about the size of generated file dnf35sp1: DNF35SP1_lng.exe

(I'm not using dotnet 1.xx)

_SNMsynth.ini:

; _SNMsynth.CMD PROCESS SETTINGS.

PROCESS_DNF1=NO

PROCESS_DNF2=YES

PROCESS_DNF35_DNF2=YES

PROCESS_DNF35_DNF3=YES

PROCESS_DNF35_DNF35=YES

PROCESS_DNF3_RGBRAST=YES

PROCESS_DNF3_WINIMAGING=YES

PROCESS_DNF3_MSXML6=YES

PROCESS_DNF3_XMLPSSC=YES

DNF_FF_ADDON=YES

PROCESS_LNG_DNF1=NO

PROCESS_LNG_DNF2=YES

PROCESS_LNG_DNF35_DNF2=YES

PROCESS_LNG_DNF35_DNF3=YES

PROCESS_LNG_DNF35_DNF35=YES

ADDON=

MERGE_FRAMEWORKS=

SILENT=

COMPRESSION_RATIO=HIGH

My dir structure:

_SNMsynth.cmd << 20090913_SNMsynth.zip ( 67.22K )

_SNMsynth.ini

7za.exe

7zsd.sfx

35SP1SLIMMING.mst

dotnetfx35.exe << 231MB

dotnetfx35langpack_x86fr.exe << 30MB

KB963707FIX.mst

msxml6-KB954459-fra-x86.exe

NDP20SP2-KB958481-x86.exe

NDP30SP2-KB958483-x86.exe

NDP35SP1-KB958484-x86.exe

NDP35SP1-KB963707-x86.exe

NETWUFIXES.mst

NOFFADDONFIX.mst

REMFONTCACHEFIX.mst

Screen of the filesize generated by the script (DNF35SP1fr.exe > 7MB)

Should'nt be DNF35SP1xx.exe bigger than 7MB ?

Note: I got no error with the script

[strel]

I still haven't checked final filesizes, but if you didn't get errors, I think it's correct. It is the new YumeYao's slimming method integrated for 3.5 SP1. Try installing and uninstalling of 3.5 SP1 and its langpack. Moreover for the next version, this slimming method is going to be applied to the 3.5 SP1 langpack too, making 3.5 SP1 resultant installer, even smaller.

EDIT: I've checked it with the dutch installer. I was right. And if you don't touch COMPRESSION_RATIO to get max ratio (which should be doing everybody unless you have a pretty old machine with pretty low RAM), you'll get even smaller ones.

Edited September 14, 2009 by strel

[strel]

Hello when i try to create a localized merged addon of 1.1,2.0sp2.3.0sp2,3.5sp1 plus updates and language packs, whith all updates present in my working folder, i get a message for NDP35SP1-KB963707-x86 that there isnt even if it is in the folder.Same for dotnetfx35langpack_x86.Ididnt get those errors whith the previous script .Any idea why this hapens.Thanks again and sorry for my english.

By the way, as I don't know what happened with you, and I don't know if you read my PM, and just discard it, can you try changing at the beginning of script CALL :EMPTYVARS line with REM CALL :EMPTYVARS ? Edited September 16, 2009 by strel

[YumeYao]

Many thanks first.

[*]Avoid old problem with .NET 3.0 SP2 (but not with previous SP# versions of 3.0) generating errors, allowing clean install/uninstall operations. You'll avoid Event Viewer errors when installing at T-13, with SVCPACK.inf or with nLite add-ons (what is the same in essence). I found these errors begin with a bug in the "Font Cache Service" installer/uninstaller DLL from 3.0 frameworks, which "RemoveFontCacheData" entry point has a bug when looking for the CSIDL reference font cache file folder for pre/post-install removal of this font cache file. Not severe if not avoided.

yeah, i've catched the cause before and am just curious, did you totally remove this from InstallSequence?

I don't know how it'll behavior but there is a post by code65536, says at T-13 there are still some jobs to be done for fonts. So do you think what original .NET 3.0 install does will or will not be done by windows's later jobs on fonts?

APART, and not for building the installers, you should install to your OS the following hotfixes after .NET frameworks, you'll find inspiration in the installing section bellow:

- In case you install 3.0 SP#, KB971276 for XP or for 2K3 respectively.

you can take a look at what I posted along with the method.

•KB955450 replaced with KB971276. KB955450 is XPS printer in .NET 3.0. I also did some trick to make it installable on both xp and 2k3.

•WIC's update shell replaced for better compression. I copied spmsg.dll, spuninst.exe, spupdsvc.exe and update.exe, spcustom.dll updspapi.dll from KB971276, as 7z will combine same files.

These two are helpful and harmless. I've tested it on XP SP3 and 2k3 SP2, it worked perfectly.

and for KB971276, I suggest you to use that for 2k3, since KB955450 in .NET 3.0 is 2k3-branch(some files are with version 5.2.xxxx). and for the trick I use, you can follow these steps when you make changes to your script.

1. extract KB971276 to somewhere, for example: %temp%\KB971276. you can use this commandline:
   WindowsServer2003-KB971276-v2-x86-ENU.exe /x:"%temp%\KB971276" /q
   
2. copy SP2 branch to SP3(for xp sp3), that means, make a copy of "%temp%\kb971276\sp2qfe" in ""%temp%\kb971276\sp3qfe"
   
3. copy KB971276-v3.CAT and update_SP3QFE.inf to %temp%\kb971276\update from WindowsServerXP-KB971276-v3-x86-ENU.exe, you can make these 2 files within your script(they are quite small).
   
4. modify %temp%\kb971276\update\update.ver, just duplicate all existing entries and change sp2qfe to sp3qfe(for each line there are 2 "sp2qfe"s)
   
5. modify %temp%\kb971276\update\updatebr.inf, add 3=SP3QFE in [DefaultBranchesServicePacks], SP3QFE="update\update_SP3QFE.inf" in [sourceInfsBranches], update\KB971276-v3.CAT in [setupFiles.Common], then add section [setupFiles.SP3QFE] with entry "update\update_SP3QFE.inf".
   
6. modify %temp%\kb971276\update\branches.inf
   SP2QFE="%SP2QFE_NAME%",SP2QFE -> SP2QFE="%SP2QFE_NAME%",SP3BTA
   add SP3BTA="%SP3BTA_NAME%",SP3RTM in [FileBranchInfo]
   add SP3RTM="%SP3RTM_NAME%",SP3GDR in [FileBranchInfo]
   add SP3GDR="%SP3GDR_NAME%",SP3QFE in [FileBranchInfo]
   add SP3QFE="%SP3QFE_NAME%",SP3QFE in [FileBranchInfo]
   add SP3BTA_NAME = "SP3BETA" in [strings]
   add SP3RTM_NAME = "SP3RTM" in [strings]
   add SP3GDR_NAME = "SP3GDR" in [strings]
   add SP3QFE_NAME = "SP3QFE" in [strings]
   

the attachment contains all modified files along with KB971276-v3.CAT and update_SP3QFE.inf.

This method will not increase the size because 7z will archive same files only once.

the weakness of this is XP SP2 users may not get this installed properly(I haven't done a test yet)

the side-effect of this is both KB971276-v3.CAT & KB971276-v2.CAT will be installed on the user's system.(however it does not harm)

There may be a solution but I don't have too much time now for working it out. FWIW the current solution will satisfy most occasions.

EDIT: I mean the user can choose whether he want to replace KB955450 with KB971276, it's suggested for XP SP3 & 2k3 SP2 users, and for others, they can just choose not.

update.zip

Edited September 15, 2009 by YumeYao

[strel]

yeah, i've catched the cause before and am just curious, did you totally remove this from InstallSequence?

I've substituted the .dll custom action RemoveFontCacheData in the InstallExecuteSequence with 2 .vbs custom actions that removes the font cache data file effectively. Why 2? I wanted to replicate original installer behaviour and another RemoveFontCacheData_commit custom action referring to the same .dll and entry point arises when the first is run from InstallExecuteSequence to be executed after InstallFinalize, thus trying to assure the operation (if there wouldn't be a bug).

I don't know how it'll behavior but there is a post by code65536, says at T-13 there are still some jobs to be done for fonts. So do you think what original .NET 3.0 install does will or will not be done by windows's later jobs on fonts?

This issue is not related with the previous one. What code65536 says is that windows is not registering some legacy fonts at T-13 until (at least) user log on. What he points out (I think) is that if this behaviour is overcomed, if you open a terminal (or so) during windows setup wrong font will be displayed, but only during setup. I don't exactly know what fonts 3.0 is installing but don't seems they are going to be legacy, so I don't think windows setup is handling its hidden attribute in order to avoid them to be registered over windows setup.

Answering the rest of your post, thx for clarifying your method.

So you're building .NET installers that include KB971276 features, I suppose all features of KB971276 are applied to the installers with this method, thus if windows would need to install KB971276 later, all this wouldn't make sense.

For the XPS printer you're combining XP+2K3 KB971276 hotfixes, I don't like this for SNMsynth because I think it's better to build different installers to different windows versions to adapt them to version specific requirements, since SNMSynth installers could include another hotfixes that could apply exclusively to a specific windows version. Moreover you say there could be problems installing over XP SP2, that would be a great weakness.

EDIT: I mean the user can choose whether he want to replace KB955450 with KB971276, it's suggested for XP SP3 & 2k3 SP2 users, and for others, they can just choose not.

I don't know if I've understood you correctly but If you are saying something like an option to choose whether applying KB971276 or not, or whether applying XP+2K3 versions of it combined or not, would be a solution; then I agree with you, but only if this method apply all features from KB971276 hotfix(es), avoding the need to install it later.

For the rest of your modifications, as long as I think SNMsynth should be oriented to customization I think that giving the option to avoid to include VC runtimes in the resultant installer, allowing its install from another packs, is a good idea; as well as including options to allow .NET related windows hotfixes, like KB971314 and KB971276, to be included in the resultant installers, idea I deprecated until now because they don't have the form of .NET hotfixes and could easily be slipstreamed to a windows source, but I realize it makes a whole lot more sense if resultant installers are not meant to be used in a windows setup so a unique file with completion is a more interesting option. To avoid including WIC or MSXML, SNMsynth have options yet to do it. And of course documentation about what cases are this options useful to, needs to be included in the guide, now it's a grey area.

Cheers.

Edited September 15, 2009 by strel

[YumeYao]

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.

now you have explained your method so i see it's totally ok.

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.

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

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.

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

fow WIC, yes it's still gray area but i can confirm it's not installable on xp sp3. when you try to install .NET on-by-on without any passive or quiet parameter, you'll receive an error installing WIC on xp sp3, saying "the target service pack lever is higher" or something else.

I've worked at ryanvm.net for 3 years so i'm sure with how an OS hotfix behaviors.

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.

Edited September 15, 2009 by YumeYao