9 Replies Latest reply on Apr 15, 2014 1:50 PM by homes32

    Issue building new package (No PROGRAM_FILESx86 common path?)

    gfraetis

      Hi All,

      I am creating a Custom Update Package for Citrix Receiver 3.4.

      I have it working fine with 32 bit systems, but i am having an issue detecting applicability on x64 systems.  Unfortunately, I am unable to reference the registry as i had hoped becuase this particular application doesn't have the path in the registry as you would assume.

       

      That said, I need to determine if the file at the following location exists and is less than version 3.4.0.29577

      PATH: C:\Program Files (x86)\Citrix\Receiver\Receiver.exe

       

      When i do this for the x32 version, i can simply use the Common Path or "PROGRAM_FILES" and use the Path value of "Citrix\Receiver\Receiver.exe" to determine its existence.

       

      However, when i try to create the package for a x64 system, where the path of the executable is "C:\Program Files (x86)\Citrix\Receiver\Receiver.exe",

      I get he following error in WindowsUpdate.log (verbose enabled) when i select Common Path of "NONE" and enter the full Path of "C:\Program Files (x86)\Citrix\Receiver\Receiver.exe" into the Path field.

      2013-01-25    08:16:51:905    1144    17b0    EEHndlr      EE: FileVersion expression: path=C:\Program Files (x86)\Citrix\Receiver\Receiver.exe, comparison=3
      2013-01-25    08:16:51:905    1144    17b0    EEHndlr      EE: FileVersion evaluated to Error!, return hr=0x80070002
      

       

      Where i believe this can be addressed is to have the x86 "Program Files" path available in "Common Paths".  Doing some research with packages i had created using SCUP, which has this feature and I used it heavily, prior to having procured Patch Manager, i was able to determine that this value is the equivalent of 'CSIDL="42"'

      Note that the PROGRAM_FILES value is "38" as i have confirmed in the XML view.

       

      2 questions:

      Can the Common Path of "PROGRAM_FILESx86" be added to the 'Common Paths" list somehow?

           Is there a config file i can add the entry into?

      Is there a means to altering the XML that can only be viewed on the "Applicability Rules" pane of the wizard?

       

      Thanks

        • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
          callidus

          Maybe this helps:

          you can use a "File Exists with Registry Value Rule" rule in combination with the Reg-Path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion" and the Reg-Key "ProgramFilesDir". In order to get "Program Files" on 32bit and "Program Files (x86)" on 64bit OS you have to check "Use 32-bit registry". On the 32bit OS the value is looked up in the above location, on 64bit "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion" is used.

          1 of 1 people found this helpful
          • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
            David Di Blasio

            The ProgramFiles(x86) common path identifier is not defined in the Microsoft SDP schema.

            Only ProgramFiles is defined, so this is the one you must use, and then parent-path to get to ..\Program Files (x86).

             

             

            Set commonPath = PROGRAM_FILES

            Set path = ..\Program Files (x86)\yourApplicationFilePath

             

             

            The reason you want to use commonPath in this way is because hardcoding the path at the root of C: then assumes that %ProgramFiles% is always on drive C:. It might not be, and your package would fail detection. By using the commonPath value in this way, your package is portable for when %ProgramFiles% exists on a different volumeID. (e.g. drive D:)

            1 of 1 people found this helpful
              • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                David Di Blasio

                Here's the original thread I found that information on.

                 

                Re: Problem with package

                • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                  callidus

                  Nice idea, but with a caveat: on older localized OS the path has not to be "Program Files". On german Windows XP it's name "C:\Programme" for example.

                    • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                      Lawrence Garvin

                      For language-specific rules and hard-coded paths, there should be appropriate conditional blocks defined with a Windows Language = <value> rule (just as there might be for a Processor Architecture rule when the registry keys differ on x86 and x64).

                       

                      The presumption in all of the above advice is that the package has been coded as English Only.

                       

                      Of course, if one is using the PROGRAM_FILES common path value, then it probably resolves to 'C:\Programme' on German-language systems. -)

                      If one is trying to get to the equivalent of "Program Files (x86)" on a non-English system, then those adjustments should be made in the "Set Path" value also.

                    • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                      homes32

                      "The ProgramFiles(x86) common path identifier is not defined in the Microsoft SDP schema.

                      Only ProgramFiles is defined, so this is the one you must use, and then parent-path to get to ..\Program Files (x86)."

                       

                      Really? because according to the msdn docs for the BaseApplicabilityRules Schema and the BaseTypes Schema the value of CSIDL="42" or ANY CSIDL value for that matter is passed directly on to Win32 SHGetFolderPath and the result is the correct folder. So there is no reason that that PROGRAM_FILESx86 common path should not be included in Patch manager as an option.

                       

                      +1 for this feature.

                        • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                          Lawrence Garvin

                          There are FOUR FIVE different variables at work here, Jonathan.

                           

                          The first is whether there even exists a documented CSIDL value for Program Files (x86).

                          CSIDL (Windows) does document this value, but does not specify to what it exactly refers, but I would say it's safe to assume that it refers to the %SystemDrive%\Program Files (x86) folder.


                          The second is whether SHGetFolderPath recognizes the value. According to the documentation it does not. See SHGetFolderPath function (Windows)


                          The second third is whether the Windows Update Agent recognizes the value and can extract it from the update metadata XML. Unfortunately, this has always been the weak link in the documentation process, and what the WUA does or does not recognize, or does or does not respond to, is a great unknown outside of the WUA team. Way back in the dark ages, all of the components were under the same Group Program Manager: WSUS, WUA, WU/MU ... but a while back the WUA got sent over to the Consumer OS group, and ever since then WSUS and the enterprise has been treated like the disowned stepchild.


                          The third fourth variable at work is whether the Software Distribution Package (SDP) schema supports the value. While the CSIDL may be passed directly to the shell, there still has to be a definition for it in the XML schema declaration so that SCUP, and other third party package tool developers, know that it's an authorizied value for use.


                          And finally, once all of the above three four conditions are met, it becomes practical for the Package Wizard of Patch Manager to define that value in a dropdown.


                          At this time, the only proven workaround for addresssing 32-bit installation folders on a 64-bit system is to define the common path as PROGRAM_FILES and then back-pathing to get to %SystemDrive%\Program Files (x86).

                            • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                              homes32

                              Thanks for taking the time to respond.

                               

                              #1:

                              It would be logical to assume so. Correct

                               

                              #2:

                              You are correct here. SHGetFolderPath may not recognize CSIDL_PROGRAM_FILESX86 on OS lower than VISTA

                              This appears to be the showstopper at least until support for XP and lower is dropped.

                               

                              #3:

                              see #4

                               

                              #4:

                              there are no restrictions on the value of CSIDL in the schema other than that the value must be an integer.

                               

                              BaseTypes.xsd

                              ----------------------------------------

                              <simpleType name="Csidl">
                                   <annotation>
                                   <documentation>A numeric CSIDL value, as would be passed as the nFolder parameter to Win32 SHGetFolderPath.</documentation>
                                   </annotation>
                                   <restriction base="int" />
                              </simpleType>

                               

                               

                              BaseApplicabilityRules.xsd

                              ---------------------------------------------

                              <element name="FileExists" substitutionGroup="sdp:ApplicabilityRuleElement">

                                      <annotation>

                                          <documentation>Checks for the existence of the specified file.  If Csidl is specified, the MSUS Client will call Win32 SHGetFolderPath to retrieve the CSIDL and prepend it to Path to form the actual path to the file.  Before checking the file, the Client will canonicalize the path to remove duplicate backslashes (among other things).  If other optional metadata are specified, such as Version or Size, they must all match for this applicability rule to return true.</documentation>

                                      </annotation>

                                      <complexType>

                                          <complexContent>

                                              <extension base="bar:FileExistsType">

                                                  <attribute name="Csidl" type="bt:Csidl" use="optional" />

                                              </extension>

                                          </complexContent>

                                      </complexType>

                              </element>

                        • Re: Issue building new package (No PROGRAM_FILESx86 common path?)
                          gfraetis

                          Awesome, thanks for the ideas. Much appreciated!