[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

This post has been edited by djanz: 10 September 2009 - 09:40 AM

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

This post has been edited by strel: 15 September 2009 - 04:22 PM

[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

This post has been edited by djanz: 11 September 2009 - 02:13 AM

[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!

This post has been edited by strel: 13 September 2009 - 02:56 AM

[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

This post has been edited by strel: 14 September 2009 - 12:48 PM

[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

This post has been edited by strel: 14 September 2009 - 04:26 PM

[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:

Quote

; _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:

Quote

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

This post has been edited by strel: 14 September 2009 - 05:26 AM

[strel]

kalaeimaigr, on Sep 13 2009, 10:04 AM, said:

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 ?

This post has been edited by strel: 16 September 2009 - 02:43 AM

[YumeYao]

Many thanks first.

strel, on Dec 26 2008, 03:50 AM, said:

[*]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?

strel, on Dec 26 2008, 03:50 AM, said:

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.

• extract KB971276 to somewhere, for example: %temp%\KB971276. you can use this commandline:
  WindowsServer2003-KB971276-v2-x86-ENU.exe /x:"%temp%\KB971276" /q
  
• copy SP2 branch to SP3(for xp sp3), that means, make a copy of "%temp%\kb971276\sp2qfe" in ""%temp%\kb971276\sp3qfe"
  
• 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).
  
• modify %temp%\kb971276\update\update.ver, just duplicate all existing entries and change sp2qfe to sp3qfe(for each line there are 2 "sp2qfe"s)
  
• 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".
  
• 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.

Attached File(s)

•  update.zip (16K)
  Number of downloads: 14

This post has been edited by YumeYao: 14 September 2009 - 10:19 PM

[strel]

YumeYao, on Sep 15 2009, 06:10 AM, said:

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

YumeYao, on Sep 15 2009, 06:10 AM, said:

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.

YumeYao, on Sep 15 2009, 06:10 AM, said:

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.

This post has been edited by strel: 15 September 2009 - 05:46 AM

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

This post has been edited by YumeYao: 15 September 2009 - 05:52 AM

[strel]

YumeYao, on Sep 15 2009, 01:49 PM, said:

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.

Just my terrible headache this morning, I misunderstood him. And now I realize what are you referring to. Really have no idea on how font caching behaves about hidden file attribute on fonts, but I don't have any reason to think that problem is reproducing with font cache service.

YumeYao, on Sep 15 2009, 01:49 PM, said:

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.

OK, so I misunderstood your method, but why doing that? it seems 2K3 installer is Version2 and XP is Version3.

YumeYao, on Sep 15 2009, 01:49 PM, said:

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

But may you concur with me that if resultant installers are not meant to be used in a windows setup it makes more sense to include it.

YumeYao, on Sep 15 2009, 01:49 PM, said:

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.

Nice info, to remove them you simply remove Windows folder in 3.5 SP1 portion, is that right?

YumeYao, on Sep 15 2009, 01:49 PM, said:

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.

It's done yet, 3.5 SP1 framework+hotfixes+langpack around 5 MB. I'm just deciding to include or not some extra modifications in the next version.

EDIT:

YumeYao, on Sep 15 2009, 01:49 PM, said:

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

Never tried it.

This post has been edited by strel: 16 September 2009 - 04:41 AM

[YumeYao]

1. yeah but they are all font related issues.
there are still many unknown mysteries of windows installation even we think we have know enough.

2. 2K3-V2 means it's newer than 2k3(-V1), and XP-V3 means it's newer than XP-V2 and XP(-V1). they are seperate branches, so you can't say XP-V3 is newer than 2K3-V2.

3. KB971314 can be applied on a living system without .NET installed, although it's needed after .NET is installed.
Additionally, it's not true that KB971314 isn't needed if .NET 3.0 is not installed. for example, KB948046, which address an printer issue, has already included an updated unidrv.dll, therefore it will also cause the issue descripted in KB971314 - PCL printer driver not signed.
so KB971314 is better included in an updatedpack for integration onto windows install source.

4. to remove VC 8 and VC 9 runtimes, removing entries in msi is also needed. If you are not sure how to do that, feel free to ask.

5. ok, glad to hear it so i don't have to help my friends do a slimmed .NET 3.5 language pack for each language they use.

[strel]

YumeYao.

This one seems to work. [ OUTDATED FILE ] Prior to approve it, I'd like to have your opinion after checking the database as you've done this before and me not.

Thx in advance.

This post has been edited by strel: 20 September 2009 - 11:02 AM

[YumeYao]

sorry for not replying in time but my schedule is suddenly ful-filled and it will last several days.
yesterday it was too late when i saw you post and first .mst file. yeah it obviously wouldn't work at one sight of transformed msi.

this time i'm not sure whether it really work since i don't have much time to test it. but i removed more entries than you did.

in brief:
Binary: SxsUninstallCA
CustomAction: SxsUninstallCA & SxsInstallCA
InstallExecuteSquence: SxsUninstallCA & SxsInstallCA
-------These 5 entries are used for installing VC runtime while Uninstall means uninstalling existing old VC runtime.

others seems all ok but just curious: can't an mst file drop a table instead of empty it? I mean, MsiSFCBypass and SxsMsmGenComponents are empty. don't mind since it doesn't matter.


and it seems you've forgot to remove VC8 in .NET 2.0 install package.
and in .NET 2.0 there is still a junk besides VC8, that's OFFICE 11 debugger.(office 11 SP3 contains newer version of debugger than .NET 2.0)
so attachment is what i did for .NET 2.0. it's based on the msi generated by your SNM. and i believe you can handle .NET 3.5 yourself now.

Attached File(s)

•  remove_vc8_in_dotnet20.mst (29.5K)
  Number of downloads: 10

[strel]

Yes, I was focusing only in 3.5 frameworks, I'll make files for 2.0 frameworks too, but I see yours is almost neat, that's going to save time.

My test revealed that removing those empty tables cause installation to abort, it surprised me, don't know if I did something wrong.

A lot of thx YumeYao.

This post has been edited by strel: 16 September 2009 - 08:19 AM