How to integrate KB928365 into .NET 2.0

[ponghy]

Hi all:

I'd like to know how to integrate the new KB928365 hotfix into the .NET 2.0 installation files. I've tried the following, but no go:

1) Uncompress the dotnetfx.exe package.

2) Apply the the MSP patch file to the Netfx.msi file (msiexec /p ...)

3) Do an administrative install to another directory.

4) Repack the files installed in step 3.

Also, I tried swapping steps 2 and 3 (e.g., first, do the administrative install and then, apply the patch to the extracted files).

The integration appears ok (no errors are shown), but Windows Update shows me 3 security updates, including KB928365 (which replaces KB917283 and KB922770).

My question is: Is there any way to REALLY integrate the KB928365 patch to the installation files? And please, don't suggest me any third-party packs, like silent installers and so on. I want to know how to achieve this myself. The method above it worked to integrate KB917283 and KB922770, but not for KB928365.

Thanks very much

Edited July 15, 2007 by ponghy

[Tomcat76]

Switching 2 and 3 should've worked. What are the complete commands you used?

[ponghy]

@Tomcat76:

I do the following:

1) Extract dotnetfx.exe with WinRAR (it's not necessary to extract with the /t switch, WinRAR it does well) to the dotnetfx directory.

2) Extract the MSP file from the EXE patch (KB928365) with WinRAR too.

3) Apply the patch to the extracted installation:

msiexec /p KB928365.msp /a dotnetfx\netfx.msi

The patch makes some folders with the new versions of the files in the dotnetfx directory. Note netfx.msi is NOT an administrative image at this point.

4) Now, I perform the administrative install:

dotnetfx\install.exe /a

to a target directory, such as c:\temp. The administrative installation point is created with the patch applied.

This method it worked for KB917283 and KB922770, but not for KB928365. Very strange...

If I switch steps 3 and 4, the administrative image is properly generated, but the netfx.msi file in the source cache subdirectory (\Win\Microsoft.NET\Framework\URTInstallPath\CSetupMM\netfx.msi) is NOT updated. Be careful with this, because no repairs can be made if the netfx.msi of this subdirectory is not properly updated. Therefore, I don't reverse steps 3 and 4.

But, all my theories don't work for KB928365. Have you integrated KB928365 in the .NET 2.0 administrative installation point. How? Please, help.

And thanks very much for your interest. I know this issue is not easy to workaround...

Edited July 15, 2007 by ponghy

[ponghy]

@Tomcat76:

Okey, it worked reversing steps 3 and 4, but I have the problem said above:

If I switch steps 3 and 4, the administrative image is properly generated, but the netfx.msi file in the source cache subdirectory (\Win\Microsoft.NET\Framework\URTInstallPath\CSetupMM\netfx.msi) is NOT updated. Be careful with this, because no repairs can be made if the netfx.msi of this subdirectory is not properly updated. Therefore, I don't reverse steps 3 and 4.

As a result, if you try to repair the existent installation through Add or Remove Programs (click "Modify or remove" and then select "Repair"), .NET Framework 2.0 Setup finalizes with an irrecoverable error. I'm completely sure this issue is because the netfx.msi file in the source cache subdirectory is not properly updated. Check out this and you'll agree. If this issue is true (and it is, believe me), I'm wondering if replacing the netfx.msi file in the CSetupMM subdirectory with the updated version (the NON-administrative image) and hacking the netfx.msi file (the administrative image, located on the root directory of the package) with Orca (I have experience modifying MSI files with the Orca editor) can workaround the problem. May be changing the size and hash values in the File and FileSaid tables? The last problem is, how can I compute the new hash of the updated netfx.msi?

Of course, the irrecoverable error does not occur if CSetupMM contains the updated version of netfx.msi. .NET 2.0 Setup expects the updated version in the cache repository.

Thanks again. I hope we can solve this issue together. It may be useful for your Silent .NET Maker, if you didn't realize the source cache issue.

Edited July 16, 2007 by ponghy

[ponghy]

Tomcat76, are you there? Anyone?

[X-FoRcE]

Tomcat76, are you there? Anyone?

I'm inspect Ryan's old package. And use ryan's method to new Dotnet2 Package.

Include all hotfixes : KB917283 ; KB922770 ; KB928365

http://rapidshare.com/files/44031129/Dotnet20.exe.html

Sorry my bad english.

[ponghy]

Ok, I checked it out that package and Ryan removes the source cache feature. This is the way I've repackaged my version, but it's not the better solution (may be the only one). The repair capability is missing from Add or Remove Programs. The original package from Microsoft can be repaired with its installer, but not this one.

Thanks anyway for your reply.

Edited July 20, 2007 by ponghy

[Tomcat76]

ponghy

The uninstallation issue is worked around if you use Silent .NET Maker (even its first version) via a registry hack:

[HKEY_CLASSES_ROOT\Installer\Products\D6461317C3DC4F04799BDCE9E42626FE]

"PackageCode"="FE8E5CFB041CA454B974EE7CA3A4BAF3"

[ponghy]

Uninstallation? My problem is that the repair process (not the uninstallation feature) from Add or Remove Programs don't work (It "works", but restores the original version of .NET 2.0, removing the update). Did you read my previous posts?

[Tomcat76]

I thought it was the same problem but I see the difference now.

I don't have experience with patching .NET before making an administrative installation so I can't comment on why it doesn't work.

[ponghy]

@Tomcat76:

Again, thanks for your interest. As I said before, this issue is not easy to workaround, and I think has no solution...

The method I said above it worked perfectly to integrate KB9172383 and KB922770, including the repair capability (believe me, and to achieve that it is necessary to perform steps 3 and 4 in that order). That is, initially I could install .NET 2.0 with the entire source cache feature, containing the updated netfx.msi on the CSetupMM subdirectory (the package took more space in the compressed form, about 40M, because it included the Netfx.msi file with 24M in size on the CSetupMM subdirectory). Therefore, uninstallation and repairing from Add or Remove Programs it worked seamlessly. Windows Update did not show the udpates after repairing, the process was consistent. But all these things don't work with KB928365....

Finally, I suspect that KB928365 has something broken when doing and administrative install or when applying to an administrative image. Only Microsoft knows this.

Check out the repair feature in your Silent .NET Maker, because you should remove it. If not, when an user clicks the "Modify and repair" button on ARP and then selects "Repair" from the install wizard, the program may crash if you have not updated the netfx.msi file on the CSetupMM subdirectory. If you don't include the CSetupMM subdirectory (I think you've choosen this way, as RyanVM did), make sure you substitute the default uninstaller (install.exe) with the MsiExec.exe command and the /X and [ProductCode] arguments, in an entry in the Registry table of the Netfx.msi file like this:

[systemFolder]Msiexec.exe /X [ProductCode]

This command removes .NET Framework 2.0 from the system. You must include the NoModify and NoRepair DWORD values in the Registry table (target key in the Windows Registry is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductName]) also, if not included yet. If you don't include these values, Windows will show in ARP the "Modify or Remove" button instead of "Remove" and if you pick support information, you will see the "Repair" button in the dialog too. Of course, this button will not work as expected.

Hope this helps for your .NET maker.

Regards.

Edited July 21, 2007 by ponghy

[Tomcat76]

SNM does not remove the CSetupMM directory and I don't plan to do so. But I'll look into updating it with the latest files.