[ponghy]

I've changed my mind to pack the .NET 2.0 Framework. due to the 'null success' of this post.

Therefore, I've decided to do an admin install patched with KB917283. I'm doing the following:

install /a -> to do the main admin install.
msiexec /p aspfix.msp /a netfx.msi -> to patch the netfx.msi against the KB917283 hotfix.

To install the product, I run install.exe from a wrapper written by me (note I'm not using direct MSI install with MSIEXEC).
Everything was fine, except when uninstalling the product. If I click on the Remove button of Add Remove Programs, Installer exists with severe serror (prompts me to send an error report to Microsoft). I've investigated the problem and I've found that install.exe copies all source files to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0, but the 'cached' netfx.msi is DIFFERENT from the patched netfx.msi. Indeed, the patched netfx.msi occupies about 3MB apart from install directories ("Program Files", "Windows"), and the 'cached' MSI (the MSI located on that folder) occupies about 24MB (this has no install directories, I think this stored distribution is the same as the original .NET 2.0). I suspect this MSI is the original, not the patched one.
I'm pretty certain that when MSI files are different, Uninstall process cannot be done. The question is : how to workaround this? (save the proper files when installing, not the original ones).

If this is not clear, my goal is to integrate .NET 2.0 + KB917283 in one pack, automated install from the shipped install.exe (more secure than installing the MSI file directly for several reasons). Installation is driven by a wrapper written by me, that calls install.exe with the proper arguments.

I hope you guys can help me this time

This post has been edited by ponghy: 17 July 2006 - 07:27 PM

[MagicAndre1981]

I also had this problem. The uninstaller crashes and wants to send a report. Go to your modified netfx.msi and rightcklick on the file and select "Uninstall". This workes for me.

[Coolsights2000]

I had issues trying to get the bloody thing to integrate the normal way like version 1.1 and sp1 did.........

So I just decided to do separate installs on each......

when you intergrate them the normal way only the plain version 2 installs.......

and it says you still need the update

So who knows..........

[T D]

Due to a lot of ppl saying stuff about KB917283 not being installed ( http://www.msfn.org/...showtopic=78856 , Xpainity's response) and other threads, I say this is a bug on the M$ side.
I tried to contact them but no go

[ponghy]

Ok, thanks very much for your feedback

Mmmm, I'm studying the Windows Installer technical reference, and I've found this public property:

REINSTALLMODE=<value>

The reference claims if REINSTALLMODE=v, Windows Installer recaches the source package. I've not checked it out yet but it is interesting...

Another question, more off-topic: I see in my profile a Warn message (with value 0%). Have I violated any forum rules? Any moderator can answer to this? I've tried to accomplish the rules all the moment...

This post has been edited by ponghy: 18 July 2006 - 01:40 PM

[mikesw]

Coolsights2000, on Jul 18 2006, 08:35 AM, said:

I had issues trying to get the bloody thing to integrate the normal way like version 1.1 and sp1 did.........

I patched .NET v2.0 with the KB patch the same way as the poster did. I noticed that it
created alot of subdirs i.e. "win", "windows", "program files" in the c:\temp directory that I used to
do the merge in. I wasn't sure how the "install.ini" and "manifest.ini" would merge together (note the
manifest.ini was extracted from the KB patch). To test the patch before putting it on a slipped Win XP disk.
I just selected "install.exe" since if I selected the patched "netfx.msi" it said to use the "install.exe".
I saw that the .NET v2.0 and KB# hotfix appeared under the "add/remove programs" selection.
However, when I did "Microsoft Update", it came back with a recommendation to install the KB patch #
that the "add/remove programs" said was already there. Moreover, I searched the registry for the
KB# to see if it was there and it was. So I redownloaded the KB# and installed it just to keep
microsoft update happy.

To comments:
a). I didn't dump the registry after doing the .NET v2.0 with patch and then redump the registry after
using Microsoft download and doing a repatch with the KB #. Then, comparing the two registry
dumps to see what's different in the registry.

. Do I need all those created subdir's in the c:\temp directory?

c). I didn't notice any version number update to the .NET v2.0 software when patched. It still
shows v2.0.50727 whereas the properties on the patch show version v1.0.93.243 on the KB file.

d). How, to repackage the extracted files back into a form that the Win XP Cd can use.
I assume the eula txt and dll's that contain the language code pages are needed along with the
".msi" and " install.exe" file etc. Once I repackage it (how???) I'd put it in the components/dotnet
or "dotnet" directory on the Windows XP CD for easy reinstall. Currently they show the
"dotnetfx.msi" only which I assume contains all the other stuff mentioned above.


How to do the v1.0 and v1.1 .NET with patches so they can be included on the Win XP CD?
They don't have a ".msp" file to patch with.

[ponghy]

Hi Mikesw, I will try to answer some questions:

Those folders ("Program Files", "Windows") are needed for the administrative install of .NET Framework. They are the result of the 'expansion' of the original netfx.msi. You can install the Framework directly with the MSI in the following manner:

msiexec /i netfx.msi ADDEPLOY=1

Notice the public property ADDEPLOY. This is necessary because the MSI was designed to work with the install.exe program. With this directive, we force the installation through the MSI, without the wrapper. But be careful, installing in this way is NOT recommended. Install.exe stops the Windows Installer service and performs several sanity checks that Windows Installer doesn't.

The recommended way is this:
Copy the install.exe, install.ini and install.*.res files to the administrative installation. Also copy unicows.dll and EULA.*.txt files. So, you can install the administrative install point with the original installer, by simply running install.exe (it is more secure, believe me).
Note: If you are going to use only the english language, you can get rid of the install.*.res and EULA.*.txt. Only copy install.1033.res and EULA.1033.txt.

The issue of non-recogntion of KB917283 is well known in this forum, and people think is a Microsoft bug (I agree). Don't worry, if you did this:

msiexec /p aspfix.msp /a netfx.msi

Your netfx.msi will include the necessary modifications given by the KB917283 patch.

You can substitute the Setup.exe file contained in the WinXP CD (DOTNETFX folder) in a simple manner:

Follow the steps given in this post.
When done, copy the file install.exe from original dotnetfx.exe (extract with WinRAR, for example) to the administrative install point of .NET Framework 1.x and you're done. You can install the framework by running install.exe. If you pass it the /Q switch will perform a silent installation. Again this is the recommended way due to the issues mentioned above.

Hope this helps

This post has been edited by ponghy: 19 July 2006 - 02:05 AM

[mikesw]

Thanks for the info. I'll try it out.
The link you posted from 4/2005 was great although I did find a more general but
similar post al the way back in 2004 on this list. In the last step they did this vs. SFX.


You can compress these with iexpress. Command to be executed:
msiexec /qb /i netfx1.msi


BTW, can all of this information be combined and made into a sticky on the topics main page?
That is, your comments, the links, along with the batch files by others that replied to the post that
you specified in your link. It would eliminate alot of going back through 19 pages of history and
trying to sort through the facts. Sort of a lessons learned summarization.

This post has been edited by mikesw: 19 July 2006 - 06:17 AM

[ponghy]

I think I've found the problem: It's a bug on the administrative install of patch KB917283.

If you do the admin install without the patch (install /a) and install the framework, you can uninstall without problems from Add or Remove Programs. But if you "slipstream" the KB917283 patch in the usual way:

msiexec /p [extracted_msp_file_from_patch] /a netfx.msi

The patch would be integrated with the main install, but you could NOT uninstall the framework in Add or Remove Programs. If you attempt it, you'll receive a severe error (Microsoft ask you to send an error report), and the uninstall process will FAIL.

Anyone can reproduce this bug and confirm it?

Thanks and regards.

This post has been edited by ponghy: 19 July 2006 - 12:59 PM

[ponghy]

I've downloaded the integrated version of the RyanVM site. Apparently is similar to mine, but RyanVM's works perfectly. I'd like to know what are the exact steps he has made to make the package (skip the steps to compress in 7-zip).

Thanks very much.

[mikesw]

ponghy, on Jul 17 2006, 09:16 PM, said:

I've investigated the problem and I've found that install.exe copies all source files to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0, but the 'cached' netfx.msi is DIFFERENT from the patched netfx.msi. Indeed, the patched netfx.msi occupies about 3MB apart from install directories ("Program Files", "Windows"), and the 'cached' MSI (the MSI located on that folder) occupies about 24MB (this has no install directories, I think this stored distribution is the same as the original .NET 2.0). I suspect this MSI is the original, not the patched one.

Here's some info on how to properly recache the .msi file on your computer for future repair after
the msi file has been patched.

Quote

To patch installations using an administrative image:

1.
Create the administrative image, if it does not already exist, with the following command line:

msiexec /a <path to the MSI>\package.msi


2.
Update the administrative image by running the following command-line option:

msiexec /a <path to administrative image>
\package.msi /p <path>\patch.msp


3.
This update changes the *.msi on the administrative image by directly applying the patch.

4.
Update users' computers by running the installation of the application from the administrative image using one of the following command-line options:

msiexec /fvomus <path to administrative image>\package.msi
REINSTALL=ALL
msiexec /i <path to administrative image>\package.msi
REINSTALL=ALL REINSTALLMODE=vomus



If you know all the features that the patch will affect, you can set REINSTALL to the complete list of features (delimited by commas) to affect only those features. This is likely to decrease the time the update operation takes. For more information about the REINSTALL property see the Windows Installer SDK, which is available from the Web Resources page at http://www.microsoft...s/webresources/

Applying a patch to an administrative installation modifies the original *.msi. The "v" argument is required in this situation to cache the modified *.msi to the local system. Failure to cache the *.msi prevents the application from performing maintenance operations. The consequences of this are discussed in the following paragraphs.
Important: A patch changes the package code of an .msi file. To allow Windows Installer to perform maintenance operations such as adding, removing, or repairing an installation, the package codes for the installed application and the source must match. Therefore, a computer that still has the original package code installed cannot be maintained by using a patched administrative image until you update the computer.

If the deployment of the patched administrative image of an application is an update, not a new installation, and it takes a considerable amount of time to reach all target client computers, it is recommended you take one of the following actions:

• Create a new administrative image for the application and apply the patch to it. You can then distribute this new source to the appropriate systems. After you upgrade all systems, you can remove or patch the original administrative image to provide a redundant source.

• Patch the clients directly on a local computer, as described in "Applying Patches to Installed Software" in this paper. This method does not modify the .msi cached on the local system, and therefore the .msi in the administrative image and on the local system remain identical.


Either of the two preceding methods can prevent the application on the client computer and the source administrative image for the application from becoming unsynchronized. If the client computer and source administrative image for an application become unsynchronized, Windows Installer cannot perform maintenance operations for the application, such as adding, modifying, removing, or repairing an installation.

Important: To remove a patch that you have applied, you must remove the entire application, and then reinstall the application without the patch. There is no way to roll back the changes a patch applies to the original package.

Here's the link that has alot of good info for you to read, and where this info came from.

http://www.microsoft.com/technet/prodtechn...ity/winmsi.mspx

Quote

The changes made by the patch persist on the administrative image. However, these changes are not automatically propagated to existing installations. The application must be reinstalled by using a command with the following arguments: REINSTALL and REINSTALLMODE properties.

This post has been edited by mikesw: 21 July 2006 - 07:09 AM