strel

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

1,004 posts in this topic

I've tried to use this property without success before, but I may be mistaken.

Don't forget /qn switch. Don't know if it would make a difference but you can try modifying it as system policy (REG_DWORD values):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\DisableRollback

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer\DisableRollback

You can try to do it too with an .mst, setting the the property with a custom action of the required type, and inserting an instance of the custom action in the InstallExecuteSequence table, search a verbosity logfile for DISABLEROLLBACK property before sequencing, to get an idea of what position to use in the sequence.

Anyway I'm dubious about the possibility of success. Tell us your progress.

0

Share this post


Link to post
Share on other sites

Yeah, I perused a verbose log file and saw that an "OEM" instance will always trigger a DisableRollback.

I had tried setting those registry keys before, but that didn't work. I set the registry keys, and then changed the permission on them to prevent the "SYSTEM" account from writing to them, and that didn't work either.

The only option I can think of would be to remove all of the checks from the MSI itself (via MST or otherwise), but then I have a feeling that the installation of the frameworks will fail because of its inability to commit custom actions.

And yeah, I use /qn. My previous post only showed what public properties I was setting. The full command line would look something more like this (in a batch file):

msiexec.exe /qn /l*v+ "%SystemRoot%\RSRTerr.log" /i "%~dp0dotNET20SP2\Netfx20a_x86.msi" ADDEPLOY=1 ARPSYSTEMCOMPONENT=0 ARPNOMODIFY=0 ARPNOREPAIR=0 REBOOT=ReallySuppress FASTOEM=1 ALLUSERS=1 DISABLEROLLBACK=0 CURRENTDIRECTORY="%~dp0dotNET20SP2" MEDIAPACKAGEPATH="%~dp0dotNET20SP2" ROOTDRIVE="%~d0"

I'll play with the MSI a bit and see what I can do.

On a side note, using the "+" directive for the logging switch does append the log file, but it seems to be inserting a NULL as every other character. I have to do a regex find/replace for \x00 (hex value for NUL). Any idea why it does that? Is there a specific encoding that you know that I should be using when creating that file? I'm only asking because you seem to know your way around MSI deployment; figured you might know.

0

Share this post


Link to post
Share on other sites

Are you using the latest windows installer for your OS? I'm reading the 3.1 version solves an issue about logging null characters used in a registry value marker or a service dependency.

0

Share this post


Link to post
Share on other sites

Yeah, I'm using 4.5.6001.22159.

If I let MSIEXEC create the log file, then this doesn't happen, even when subsequent installations append to it. It's only when I create the log file beforehand. Maybe it's an encoding issue. Anyway, it's not a big deal. I just figured I'd ask you in case you knew. It's something I can easily overcome just by making a few adjustments to my installation routine.

0

Share this post


Link to post
Share on other sites

EDIT: About encoding maybe you're wondering if I changed something on the .msi files to apply the transforms or so. That's not the case. For the next version some tricky operations changing encoding setting on the .msi files will be done to apply some transforms to langpacks, but encoding setting will be reverted inmediately after this. So I don't think this method is causing any encoding problems for the version you're using (nor for the next one), if any, may be there before.

Nevertheless, I'm not a guru of anything. You should try in appdeploy.com message boards, sure there you'll get more detailed information about this, if any.

Edited by strel
0

Share this post


Link to post
Share on other sites

New update released:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=491874d4-5eea-4545-9b7d-3861857c862e

0

Share this post


Link to post
Share on other sites

Ugh. I can't figure out what WUFIXES.MST does, exactly, so I can modify it to support the newest update. I got the update applied to the MSI just fine, but I don't know what changes need to be made to WUFIXES.MST. :\

0

Share this post


Link to post
Share on other sites

George King

A lot of thx. I've included it in the guide.

Dumpy Dooby

NETWUFIXES.mst (in the latest release) contains ad-hoc fixes to block some hotfixes for not to appear in win/ms update, because of its absolut nonsense (the case of langpacks for SP0 versions, not even installed) or because they are not really needed unless you use this piece of software, though ms pushed them to you as if they were required (that's the case of .NET 3.0 and .NET 3.5). I have yet to install the new hotfix to see if there is any surprises that would require an extra fix to correctly apply it, but I don't expect that. The script process this new hotfix seamlessly, so no changes needed there about it.

Edited by strel
0

Share this post


Link to post
Share on other sites

Oh really? I thought you and YumeYao were doing something with the MST that required an update every time there's a new hotfix release. If what you're saying is correct, then awesome. I'm all set then.

I was able to export the data from the MST, by the way. I saw the VBS files. I actually just got them extracted from it and I was looking to see what I needed to modify to make it work right. I'm glad I decided to stop by this thread first because I've now learned that I don't need to change anything! Yay!

Thanks for the info.

0

Share this post


Link to post
Share on other sites
George King

A lot of thx. I've included it in the guide.

This does not work for me, I'm sorry. :no:

I added KB974417 yesterday when I rebuilt my silent .Net packages (2.0SP2, 3.0SP2 and 3.5SP1) for T-13 installation (doing my WIndows setup with hfslip) witn SNM of 20090922, but afterwards this patch was still listed as missing in Windows resp. Microsoft Update... :( For some reason it is not recognized as installed.

Can anybody confirm this? Can I help somehow in debugging? Thanks in advance!

Regards,

Tomalak

0

Share this post


Link to post
Share on other sites

I've added too KB953297 for 1.1 fx with a "not supported" advice as well as to KB974417.

Checking...

0

Share this post


Link to post
Share on other sites

I can confirm.

After applying the patch:

msiexec /p NDP20SP2-KB974417.msp /a Netfx20a_x86.msi

...and reinstalling Windows completely with integrated .NET Frameworks,

I get this:

50c23f1318a3df52ccec2041117d6e0d0a5b4b1a.png

Edit--

I don't install Microsoft .NET Framework 1.1. So there may or may not be updates that show up once that's installed.

Edited by Dumpy Dooby
0

Share this post


Link to post
Share on other sites

I can verify that the following files are actually getting copied over:

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscordacwks.dll

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorlib.dll

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorwks.dll

They are receiving the GDR update from the MSP.

So it's just a matter of manually telling WU that the hotfix is installed, right?

0

Share this post


Link to post
Share on other sites
I can verify that the following files are actually getting copied over:

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscordacwks.dll

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorlib.dll

- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorwks.dll

They are receiving the GDR update from the MSP.

So it's just a matter of manually telling WU that the hotfix is installed, right?

i think it's the same as KB951847 when we had to add a few reg keys to supress MU.

i'm actually in midst of a looooong manual install straight off of MU to see what is required.

**** only spare pc i had was a PII800, i cant remember taking hours to install.

unless someone has the keys already...

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches

HKLM\SOFTWARE\Classes\Installer\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches

Edited by user_hidden
0

Share this post


Link to post
Share on other sites

There seems to be an issue with applying the hotfix.

Here's a program that utilizes one of the files. Just drag and drop an EXE onto this program (it's written by a fellow community member; the program reduces the privileges of an EXE) and it should work. Test it without the latest hotfix slipstreamed into .NET FW 2, and you'll see that it works. Then test it after the hotfix has been slipstreamed, and it will say it can't find that file.

http://xp.xpdnc.org/RunRestricted.exe

So something's not right.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.