locked
DSC Version Checking RRS feed

  • Question

  •  

    Hi I searched around and I couldn't seem to find an answer for this.  I hope I'm plugging this into the right category.

     

    Our situation is this: One application requires JRE 1.4.02_05 to run.  If I were to sequence the two separately and use DSC for the application to run properly, when I update JRE will the application check to see if the correct version of JRE is installed or will it just take whatever is in the dependency section of the OSD and run?

     

    Thanks.

    Tuesday, July 15, 2008 8:49 PM

Answers

  • I think this topic is pretty much explained in a different thread.

     

    The primary application will always stream down the latest version of the dependency application (based on it's GUID not on the HREF filename). So if you were to open the JRE for upgrade (during sequencing) and register it as a new version in the management console, the new version will be streamed to the client.

     

    If you for some reason want both JRE versions to work independent of each other (for example App1 needs JRE 1.4 and App2 needs JRE 1.5) you have to sequence them as two different applications. The OSD of App1 will reference JRE 1.4 as its dependency while App2 will reference JRE 1.5 as it's dependency.

     

    Regards,

     

    Ment 

     

    Wednesday, July 16, 2008 7:52 AM
    Answerer

All replies

  • I think this topic is pretty much explained in a different thread.

     

    The primary application will always stream down the latest version of the dependency application (based on it's GUID not on the HREF filename). So if you were to open the JRE for upgrade (during sequencing) and register it as a new version in the management console, the new version will be streamed to the client.

     

    If you for some reason want both JRE versions to work independent of each other (for example App1 needs JRE 1.4 and App2 needs JRE 1.5) you have to sequence them as two different applications. The OSD of App1 will reference JRE 1.4 as its dependency while App2 will reference JRE 1.5 as it's dependency.

     

    Regards,

     

    Ment 

     

    Wednesday, July 16, 2008 7:52 AM
    Answerer
  • How does version handling work for DSC? - For example, Dependency App B is installed prior to sequencing Main App A because there is no option to open Dependecny App B while\before sequencing so you have to install it.  Application B puts down DLL ABC.dll version 1.5.  Main application A is installing but *requires* DLL ABC.dll version 1.0.  Due to installer rules the higher version is not overwritten but is it redirected into the VFS? 

     

    Is there any documentation on file handling within SoftGrid\App-V in gereral?

     

    Also, is it still that Microsoft only one supported DSC link?

     

    Kind Regards.

     

    Wednesday, August 20, 2008 12:35 PM
  •  Doink06 wrote:

    How does version handling work for DSC? - For example, Dependency App B is installed prior to sequencing Main App A because there is no option to open Dependecny App B while\before sequencing so you have to install it.  Application B puts down DLL ABC.dll version 1.5.  Main application A is installing but *requires* DLL ABC.dll version 1.0.  Due to installer rules the higher version is not overwritten but is it redirected into the VFS? 

     

    If the installer doesn't change or add file during monitoring, it doesn't go to VFS. So in your case if App A is unable to replace ABC.dll during sequencing as dependency application [that has been installed on the sequencer before monitoring] has newer version of it on the system, no ABC.dll will get included in the package. So when running this combination on the client with DSC, App A sees 1.5 from App B. When running App A alone, it sees - naturally - no ABC.dll at all. What you could do of course is to replace that DLL manually while sequencing App A and then it would be included into package.

     

    Also note that DSC doesn't really handle [filepath and registry entry] conflicts on the runtime and by that I mean the sum of all VEs is what gets loaded in what order (if I remember right, subordinate packages first and main package last). So even if one package has alternate version of some dll from another package that then gets suited in as one VE, what application will see is "last loaded wins".

     

    /Kalle

    Thursday, August 28, 2008 9:20 AM
    Moderator
  •  ksaunam wrote:
     

    Also note that DSC doesn't really handle [filepath and registry entry] conflicts on the runtime and by that I mean the sum of all VEs is what gets loaded in what order (if I remember right, subordinate packages first and main package last). So even if one package has alternate version of some dll from another package that then gets suited in as one VE, what application will see is "last loaded wins".

     

    /Kalle

     

    correct on "last loaded wins", but primary app loaded first and then dependencies

    Thursday, August 28, 2008 3:42 PM