Jump to content

strel

Member
  • Posts

    625
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Spain

Everything posted by strel

  1. If you manage to install 2.0 and 3.0 frameworks, there should be uninstall regkeys for 2.0 and 3.0 frameworks and its langpacks at least, and under %SYSTEMROOT%\Microsoft .NET Framework\ there should be folders for these versions too, as well as its logs under %TEMP% folder (if you don't installed it from windows setup T-13) Can you post your INSTALL.CMD? I'll post previous versions in the next minutes.
  2. No changes were made to 2.0 installers in the last versions, so I don't find any justification for such a bunch of errors. Waiting to see more info.
  3. Can you check 3.5SP1 and its languages are not really installed after looking for them on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} regkeys?, if they are not really installed, and if you have installed made the install out of a windows setup, is there any NETFX35install.log or NETFX35LNGinstall.log related to this installs (check date) in %TEMP% folder?
  4. I can't see that paragraph in english help file for 1.2 RC1 (build 715), nor in the english web section (which seems to be basically the same). It is only in the russian section.
  5. I've got a solution, I have to test it. About the error with the log files there are environment variables at T13, but not %TEMP%:
  6. Oleg, Gora, 2 ideas: What if besides the SetEnvironment config file parameter that let you define environment variables during execution in static way, one could set group of variables discretionally by the use of SetEnvironment# config parameters in combination with a -se# switch, resembling the behavior of the -ai# switch for AutoInstall# parameters? I'm thinking specially in script execution. And what about a switch to be able to define InstallPath from the command line? A lot of thx for the new release.
  7. New update released! It's NOT the release you're waiting for with the whole YumeYao's slimming method yet. This one will come soon. In this one a couple of bugs are fixed: 1. The one causing 0d14r3 and brazilian users not to block KB829019 that was inserted in 20090912. Something copying .mst files to .msi folder and executing them from there not worked; plus doing all this as a workaround for Karoly67 problems avoid removing of fixes applied on uninstall for this case, and only masks the real problem. 2. The one causing YumeYao and everyone, not to block KB829019 when removing only 2.0 SP2 langpack while keeping framework, and in general causing not removing the fixes applied correctly on uninstall. This bug was a typo inserted in inlay fixes removing scripts in NETWUFIXES.mst since 20090818. YumeYao, finally your KB829019 prompt was caused by not having installed the langpack while the fix is still applied. I've reviewed you Block script proposals they wouldn't work, NETWUFIXES.mst does the work very well, but yes probably I'll split it.
  8. So here you are removing the inf files that define the update branch, and copying the .NET 3.0 update shell files (for maximum compatibility, I suppose) to W2K3KB971276 for making it able to install on XP SP2, but I suppose this is making it too OS version and SP# level independent (among XP/2K3 supported), what's great.But I think there's an error in your draft, and correct if I'm wrong, you say update shell from .NET 3.0 framework should substitute the one in the .NET 3.0 langpack, right?, and I think this is redundant. OK, I see the point, you're downgrading this files. I'm working in the option to allow components running spupdsvc.exe to install at RunOnce. But I would like to understand the problem, at least to document it properly in the guide. I think you're saying that OS hotfixes running over GUI-Mode setup are scheduling its delayed actions to be executed by spupdsvc.exe at 1st logon RunOnce; but at this time spupdsvc.exe is making a mess with the all delayed actions it has to apply, that would lead to some customizations scheduled to be applied by the user at that time through spupdsvc.exe too on his unattended source fail, because they need to be applied in a specific order. Am I right? Thus, a user with this requirements would delay all OS hotfixes installing from GUI-Mode Setup to RunOnce, so that delayed actions for that hotfixes would schedule to be run by spupdsvc.exe on 2nd logon RunOnce. Have I understood it right?If affirmative, let me say that in my opinion the user better should seek another method to apply his customizations.
  9. Yes, but you're modifying the registry, take care, first make a copy of the registry to able to restore changes, then look for .NET entries and start removing but do it with care, i.e. start with the obvious, if you have any doubt a regkey doesn't bellow to .NET, keep it for later removing if necessary. Once you finished, try again with .NET cleanup utility, and after that try installing again. If not achived anything, repeat removing less obvious regkeys. I managed to solve a similar problem with .NET this way in the past.
  10. I'd try removing all .NET related entries in the registry manually, making a back-up previously.
  11. http://www.getpaint.net/ http://www.ranorex.com/products/ranorex-st...nvironment.html http://usa.autodesk.com/adsk/servlet/item?...amp;id=12433125 http://www.telerik.com/products/silverlight.aspx
  12. What does this mean? First, I'm looking for info about this file but I don't get light, I understand that this file triggers an update check on reboot, right? I think you're meaning that this check is made only over new (updatable) components installed, but only if this process is called. And it seems you're saying that all possible updatable components that install before logon, among the wide load of hotfixes and software someone could use in his unattended project, are not calling spupdsvc.exe except those you name. This is what I don't get, is that correct? I don't get this neither. This fix executes everytime SNMsynth 3.0 SP2 is installed/uninstalled under any circumstance, I think.
  13. 0d14r3 Can you please try to use the previous copy of NETWUFIXES.mst with the new installer?. In other words, uninstall 2.0 SP2 and its langpack, extract the new installer, substitute the copy of NETWUFIXES.mst with the one last modified 2009 07 30, run INSTALL.cmd, and last check the reg value I told you above. This way we can discard or not an error in the fixes file. But do this with an installer that don't include 3.5. I suppose you have the outdated copy of the fixes file, I can send you one if not. Thx
  14. This is the final file set, unless errors detected, what's possible though I browse all them 2 or 3 times: UPDATED 2009 09 21 16:18 UTC : Updated with changes proposed in the next post. If anybody find and error, specially in 3.5/3.5 SP1 languages slimming files, please report. REMOVED, go to the first post to get and donwload the script packet to get them
  15. Yzöwl. Your method based on NET seemed to be rock solid, I mean HKLM\Software\Microsoft\Windows NT\Current Version values could have been modified, and your method don't rely on that, isn't it? I'm going to use it to substitute the poor VER based one in Silent .NET Maker synthesized. Thx a lot.
  16. You think it is a virus, use an antivirus scanner from a bootable media to scan the HD for the virus, if you find it try to clean it. And be careful because the virus could be in the data backup you saved. I'd wait to use this data until I'd be able to clean any virus contained.
  17. 2 0d14r3 Let's see that. NETWUFIXES containing that fix last changed in 2009 08 25 but the part referring to KB829019 fix was not modified. I suppose you are using installer containing 2.0 SP2 framework, and that is updated properly, otherwise you could received a message during installer building saying KB951847 will not be applied, and if that happened this should be the cause, because both fixes came in the same pack; check the installer too, uncompress it to see whether NETWUFIXES.mst is in the same forlder as INSTALL.cmd or not. Is the following value in the registry? HKLM\SOFTWARE\Microsoft\DevDiv\URT\Servicing\1.1\RED\1046\Install It should be of type DWORD with value 1. (that's KB829019 fix) 2 YumeYao Obviously SensSubscription is absolutely related to dwsens.dll functionality, it is used to suscribe office debugger to SENS, but apparently is not part of the office debugger itself. What I say is that this library may be used by other .NET software appart from office to suscribe to SENS later. Or maybe the software that use it came with its own copy to do that. That's what I'd like to know. In your 20SP2_REM_OFFDEBUG_REM_DWSENSE.mst you removed dwsens.dll and the custom actions related, that's in question. But you removed CreateFolder: TARGETDIR CSharp_Watson20_Reg_Keys_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 Watson20_Error_Logging_____X86.364...... They are related to the components of the feature where office debugger resides that we concurred should not be removed. And in Directory: VC_Configurable.3643236F_FC70_11D3_A536_0090278A1BB8 TARGETDIR . In addition to its related CustomAction and XXXExecuteSequence entries. In your 20SP2_REM_VC8.mst I see your point removing sxs related folders left, and its related custom actions and XXXExecuteSequence entries. And a trick to use Insted with .mst files, the time first you tell Insted where to save the .mst file is actually not saving anything until you make changes and then save, so does not present the window of related entries when you removed them, but when I opened Insted with a previously saved .mst it does it.
  18. I've edited post #342 above about the folders. I didn't remove dwsens.dll entries from debugger removing file, I suppose any other application can suscribe to SENS through this DW.
  19. About debugger removing. You say it's convenient an option to remove debugger because there is ways to install updated versions than that inside .NET 2.0, but from your draft I see in the FeatureComponents table that removing all components of Watson Feature you're removing also C# debuggin and logging, should they remain or are they updated by OFFICE 11 SP3 too?
  20. For the debugger (only) removing file, the Property Custom Actions with target [WindowsFolder], [CommonFilesFolder] and [ProgramsFilesFolder], and its related entries in the XXXXExecutionTables, I'm dubious about removing them in the same manner as with that CA of the 3.5 slimming files. Is the same case? Any news around this? EDIT: I understood finally what's the logic in removing them, they are there only for supporting the creation of a folder tree where only resides a DW subfolder exclusively related with office debugging. In the case of the [XXXXX_folder] entries in 3.5 slimming files I ask you before, it's not the same case in my opinion, I have not see they are there for creating any uneeded forlder tree, in fact I still don't know it's function, if any.
×
×
  • Create New...