Tomcat76

It could be that an unsupported hotfix is causing the slipstreaming of Windows Update Agent to break but I can't see that because you stripped your log. When you open WindowsUpdate.log (located in the Windows folder), which files need to be updated according to it?

The problems are still there when only installing .NET 3.0 from SVCPACK.INF (RogueSpear's). Conclusion: .NET 3.0 just can't be installed at T-13. I updated the main post and the readme file in the script package.

Alright. I did the test with RogueSpear's installer. - the two errors for Windows Presentation Foundation are there - WebClient service fails So nothing that I'm doing differently from RogueSpear is causing this. In my situation, this leaves room for three possibilities: 1) .NET 3.0 can't be installed from SVCPACK 2) There's an unforeseen error in one or more of the .NET 3.0 applications 3) IE7 and .NET 3.0 don't get along very well (either the install order should be changed or one should be omitted; I installed IE7 from SVCPACK.INF after .NET 3.0)

I also have this problem with the WebClient service but thought it was because of my system. I had to reinstall Virtual PC 2004 recently because my NICs weren't properly recognized anymore by it so I assumed it was a "leftover" from those problems. This could take some time to debug. I'll start off with trying RogueSpear's silent installer to see if it produces the same problem. If not, I may have to abandon the admin install approach for the .NET 3.0 "wrapper"; the downsides of that will be: - future updates can't be slipstreamed - you can no longer customize the .NET 3.0 install That would really stink...

I am aware of those errors but am not sure why they are logged. Windows Communication Foundation (installed right before Windows Presentation Foundation) also calls the SHGetFolderPath function and it doesn't report an error. However, right after the SHGetFolderPath calls in the Communication Foundation log it's written that the needed info was found "by spelunking the registry"... which could indicate that the calls did fail but that there was a "backup method" (scanning the registry). I don't think that the Presentation Foundation installer doesn't have a backup method, otherwise the new fonts wouldn't be present in the Windows Fonts folder. So I guess the difference lies in the nature of the logging: report everything except "recoverable errors" for WCF, and report only errors for WPF. I'll have the WPF installer output a verbose log to verify that.

I have my doubts about your second post. On an existing Windows installation, %TMP% refers to %USERPROFILE%\Local Settings\Temp. During Windows setup, %TMP% refers to %SYSTEMROOT%\Temp as there are no user profiles yet (provided that Windows setup actually recognizes the %TMP% variable -- haven't tried it yet). If your addon copies something into %TMP% during Windows setup, it will be located in %SYSTEMROOT%\Temp so there's no point in trying to delete it from %USERPROFILE%\Local Settings\Temp afterwards. By the way... Windows setup purges the %SYSTEMROOT%\Temp folder right before the final reboot so you actually don't need to do anything. Just leave everything in %SYSTEMROOT%\Temp and Windows setup will do the rest, heheh

And add support for every possible .NET 1.1 executable name? Or force people who don't use this script to name it DNF11.exe? I don't think that's really feasible... Why don't you just rename the output file(s)? It's easy... 1_DNF20.exe 2_DNF30.exe 3_DNF11.exe

It isn't possible. Any CD/DVD can be copied. And you only need a LITTLE bit of computer knowledge to work your way around hidden files....

BTW... The newest version supports your msxml6-KB927977-ita-x86.exe...

Don't know if this is your problem, but it's been said a few times that .NET 3.0 won't install if you installed .NET 1.1 first without rebooting. This will not work: .NET 1.1 .NET 3.0 This will work: .NET 1.1 <reboot> .NET 3.0 This will also work and it's done if you merge 1.1 with 3.0 (but I can't test thoroughly if there are any side effects): .NET 3.0 .NET 1.1 I just updated the main post so it's explicitly stated there too.

Yes. The script expects msxml6.msi, not msxml6-KB927977-xxx-x86.exe, as explained in the instructions...

Glentium already asked this (see my second post on this page if you're using the default posts per page setting). But it doesn't really matter. A .NET 3.0 installer made with this tool will only replace existing MSXML6 binaries during installation if the existing ones are older (unlike what happens if you install the original dotnetfx3.exe normally).

I'm sorry to hear that, gaiabeliever, but -- as one of the code maintainers -- I can't see how HFSLIP can damage your system in such a way. The only thing I can think of is that you downloaded a "suspicious" hotfix or program which you allowed HFSLIP to slipstream (ie, the file damaged your system when HFSLIP accessed it). I can't give you any suggestions either because I only have experience with reconstructing missing partition tables and quick-formatted drives.

Just for kicks... What if you first try to get rid of this?

If you're using Win2K, you need full paths. %SYSTEMROOT%\REGEDIT /S IZArcFileAssocs.reg

I don't see why there should be any issues. I've been going on past experience for .NET 1.1, some useful info posted by S3pHiroTh for .NET 2.0 (the ADDEPLOY variable) and an MSDN doc for .NET 3.0. But... you shouldn't really ask me. The only program I use that requires .NET is Sound Forge 8. It's working, though. Just know that if you install .NET 1.1 and .NET 2.0 in one go, the system requires a reboot before .NET 2.0-dependent programs can be installed. Workaround: don't install .NET 1.1.

Thank you ! I forgot to tell you that in the .ini file has an option that can merge into one executable for 1.1 and 2.0 net framework, you can read that option in the first post of this topic You can also merge .NET 1.1 with .NET 3.0 The results and /or idea of the script may be, and the Tomcat76's effort and methodology is as usual to be commended. There is however nothing amazing about the script.Us speak a different lingo...

The latest version uses hidcon.exe. Is that OK too?

@daddydave Please try the latest version. You can change the compression ratio with it. Try COMPRESSION_RATIO=MED and if that doesn't help go with COMPRESSION_RATIO=LOW. @S3pHiroTh Windows Cardspace is installed when using the installer on an existing Windows system. I'll do a test later to see if it works from SVCPACK too. @glentium The problem with the msxml6 package in .NET 3.0 is that it's older than the KB927977 hotfix *and* will overwrite the newer file versions that you slipstreamed. You basically have two options: 1) slipstream the binaries from KB927977 into Windows and create a silent .NET installer that doesn't include msxml6 (PROCESS_DNF3_MSXML6=NO) 2) do not slipstream KB927977 into Windows but place the msxml6.msi file from it in the SNM working folder The end result is the same.

If you want to exclude .NET 2.0 from the .NET 3.0 package, simply set PROCESS_DNF3_DNF2 to NO in the answer file. I won't make this the default behavior because .NET 2.0 is part of the .NET 3.0 package you download from Microsoft. Well... Don't really know what to say to that.I don't see it in the .NET 3.0 package and can't find any info on how to deploy it either (provided it's hidden somewhere in .NET 3.0)...

I don't really know how much RAM is needed and how big the pagefile should be for this sort of stuff. I was using 2x512MB sticks for a long time and now have 2x1024MB sticks. The pagefile has been on 2GB all this time. My timings: * create admin source for DNF11 and langpack + slipstream patches = 24 seconds * create admin source for DNF20 and langpack + slipstream patches = 16 seconds * create DNF11.exe from admin source = 43 seconds * create DNF20.exe from admin source = 64 seconds I know that the process of making the EXEs requires quite a bit of memory and that the amount of memory does have a say in this, but your timings are really extreme. I suppose mine are too but it shouldn't be too much slower. Set your pagefile to a fixed 1024MB or 1536MB (identical min & max) and see if that helps.

It isn't normal. How much memory do you have? Are you creating these installers in a VM? [script updated again - see changelog for details]

New version

Dotnet3 is such a beast.... And Windows Communication Foundation, Windows Presentation Foundation and Windows Workflow Foundation won't install if .NET 1.1 is installed in the same go. Next version: - support for dotnet3.exe (not yet the language pack, though langpack2.exe is supported) - optional answer file (install or ignore specific components, set some file names, and merging .NET 1.1 with .NET 2.0) - fix potential problem with Win2K if reg.exe is slipstreamed (not sure if that really is a problem) - installers can be tested on an already installed system - overwrite msxml6.msi from .NET 3.0

With that size the language pack can never be part of it. Is it called langpack.exe?