dotnet_x64.rtiz Script Problem?

[TerryM]

All is/went well with seven_x64_sp1.rti (June 27, 2016) however, ran into an issue with a .Net Framework update dotnet_x64.rtiz (May 25, 2016) that forced AP6 into the Unofficial state:
NDP1.1sp1-KB2833941-X86.exe' was found, but not mentioned by any RTI
NDP1.1sp1-KB867460-X86.exe' was found, but not mentioned by any RTI!

[Whatacrock]

@ TerryM --- moved topic to appropriate forum

Have made alterations to the 2 updates in question. They have been relocated to dotNET_x86-x64 files, logic being that these 2 are common to both architectures.
The modules likewise been updated to reflect the change.

A note to all that have both dotNET x64 and x86, this creates a situation causing Autopatcher to become Unofficial (need assistance from TheAPGuy) to remedy. For now run Sweeper after completing the downloads.

[TerryM]

Thanks, for moving this. Still learning the ropes.

Sweeper gave the option to delete these files, decided not to do this, thinking they were needed but not aligned with the script. I suppose I could have manually deleted these and checked for status but ... what should have been done with the Sweeper result?

[TerryM]

Ok, manually moved (i.e. deleted) the extra files, downloaded the new .NET Framework Addon Pack x64 (June 27) and ran AP6 to check/install the updates. AP6 now back in Official status.

[ChrisJ]

Thanks, for moving this. Still learning the ropes.

Sweeper gave the option to delete these files, decided not to do this, thinking they were needed but not aligned with the script. I suppose I could have manually deleted these and checked for status but ... what should have been done with the Sweeper result?

Yeah, those updates now were in the wrong folder and seen as extra. They're needed but not knowing where to put em you were in a spot. If you want to dig deeper next time -> consult the updated script after Wac posts it, view it in a browser tab, search for the KB #s or the changes, in this case you would've noticed the KBs were moved from \dotNET-x86_files\ to \dotNET-x86-x64_files\. It might seem risky but if the folder didn't exist -> add it -> then drop the files in it -> then download the latest script to finish up -> and then sweeper to confirm or cleanup. BTW, If you don't have .net x86 you likely still have an empty folder, Sweeper should want to delete it.

Ok, manually moved (i.e. deleted) the extra files, downloaded the new .NET Framework Addon Pack x64 (June 27) and ran AP6 to check/install the updates. AP6 now back in Official status.

If you only have .net x64 there may be an emtpy folder - \dotNET-x86_files\ - Sweeper should clean it up. It will get created if you add .net x86 to \modules. If you have files in there, I'd leave it be.

The bottom line, running the updated script after Wac's edit would have been a good test to determine if all goes as planned -> the files get moved -> 2 updated apm(s) and an updated rtiz are added to the release. Deleting the files only added downloading the KB.exe(s) again, no big deal on fast connections. OTH, I have dialup and I would've figured out the edit to save the 26+MB and hours of downloading. The great thing is you fixed it... I always encourage users to get in there and mess around, only way to learn... and, after messin' around -> download the latest script to verify your work -> then run Sweeper to confirm it or clean up any mess

All this just FYI - no need for a response

[Whatacrock]

Sorry people, made an error when creating the rtiz file,corrected and uploaded. No date change !!