locked
Interaction with other application RRS feed

  • Question

  • Can some one point out how a sequenced App-v application can interact with a non-appv installed application such as Adobe reader or java. For example, if a App-v application wants to run Adobe Reader and Adobe reader is isntalled on the machine as a standard installation. How about Java interaction? Would the App-v sequenced application look for Adobe reader on the system automatically? I am looking for some general concept outside of the scope of Dynamic Suite Composition (DSC) in Microsoft Application Virtualization 4.5    because DSC is an interaction with other App-V installation.
    Thanks for any help.
    Tuesday, October 6, 2009 10:20 PM

Answers

  • It's rather simple really:

    Any and all locally installed applications are visible to applications coming from App-V packages, in the very same way as your other locally installed application would use each other. In other words, sequenced app would see Adobe Reader installed locally on the system, but in reality what that sequenced application likely does is to ask Windows to invoke application that handles PDF files it wants to open. This is btw the exact same thing as built-in capabilities in App-V Client are able to provide on behalf of sequenced applications as well, namely the ability to register file associations for virtual applications.

    So your sequenced application highly unlikely will go looking for AdobeReader.exe but rather used PDF registration. But, if it does indeed look for EXE file, it would see that since Adobe Reader in your scenario is installed locally and nothing is preventing virtual applications from seeing local applications.

    For Java (JRE) interaction, I'm not too familiar how Java program execution is handled vis the Java runtime, but as I see it, there's two options:

    - You execute your Java application directly from JAR file by giving it as parameter to java.exe coming from runtime installation
    - You could have Java -written application in the "bootstrapper" -executable, which internally handles this invoking of java.exe with appropriate parameters

    For locally installed Java runtime and virtual Java -requiring application this is pretty much the exact same as with Adobe Reader -example: if the Java app in in self-contained EXE file (which your OSD points to in App-V package), this EXE will find JRE by looking at path (?) and/or some environment variable set by JRE, and will then launch correctly using local JRE installation. If you sequenced Java application is coming from JAR file, you most likely have to specify path to local java.exe in the FILENAME attribute of the OSD or depend on JRE's bin -directory being in the system's path so that you can specify just java.exe in the FILENAME. The JAR file itself needs to be as parameter to this local JRE executable which will then be lauched in the package's "bubble" and is able to execute requested JAR (and the Java application).

    br,
    Kalle
    • Proposed as answer by znack Tuesday, October 13, 2009 10:01 PM
    • Marked as answer by Ment van der PlasEditor Sunday, October 18, 2009 10:31 AM
    Wednesday, October 7, 2009 6:51 AM
    Moderator

All replies

  • It's rather simple really:

    Any and all locally installed applications are visible to applications coming from App-V packages, in the very same way as your other locally installed application would use each other. In other words, sequenced app would see Adobe Reader installed locally on the system, but in reality what that sequenced application likely does is to ask Windows to invoke application that handles PDF files it wants to open. This is btw the exact same thing as built-in capabilities in App-V Client are able to provide on behalf of sequenced applications as well, namely the ability to register file associations for virtual applications.

    So your sequenced application highly unlikely will go looking for AdobeReader.exe but rather used PDF registration. But, if it does indeed look for EXE file, it would see that since Adobe Reader in your scenario is installed locally and nothing is preventing virtual applications from seeing local applications.

    For Java (JRE) interaction, I'm not too familiar how Java program execution is handled vis the Java runtime, but as I see it, there's two options:

    - You execute your Java application directly from JAR file by giving it as parameter to java.exe coming from runtime installation
    - You could have Java -written application in the "bootstrapper" -executable, which internally handles this invoking of java.exe with appropriate parameters

    For locally installed Java runtime and virtual Java -requiring application this is pretty much the exact same as with Adobe Reader -example: if the Java app in in self-contained EXE file (which your OSD points to in App-V package), this EXE will find JRE by looking at path (?) and/or some environment variable set by JRE, and will then launch correctly using local JRE installation. If you sequenced Java application is coming from JAR file, you most likely have to specify path to local java.exe in the FILENAME attribute of the OSD or depend on JRE's bin -directory being in the system's path so that you can specify just java.exe in the FILENAME. The JAR file itself needs to be as parameter to this local JRE executable which will then be lauched in the package's "bubble" and is able to execute requested JAR (and the Java application).

    br,
    Kalle
    • Proposed as answer by znack Tuesday, October 13, 2009 10:01 PM
    • Marked as answer by Ment van der PlasEditor Sunday, October 18, 2009 10:31 AM
    Wednesday, October 7, 2009 6:51 AM
    Moderator
  • what about having the local app talk to the app-v bubble?
    Jay Parekh
    Thursday, May 20, 2010 2:33 PM
  • You could also explore the use of local interaction you simple add the below to your OSD files.

    Edit under the section <VIRTUALENV TERMINATECHILDREN="TRUE"> TAG

    <POLICIES
    <LOCAL_INTERACTION_ALLOWED>TRUE</LOCAL_INTERACTION_ALLOWED>
    </POLICIES>

    Virtualization can prevent locally installed applications from interacting with a virtualized application, scenarios include situations where some applications are installed locally and others are virtualized. 

    LOCAL_INTERACTION_ALLOWED can introduce application conflicts so it is best that you only implement this if absolutely necessary, and be sure to test in your environment before rolling out a package that uses this tag.

    I’m working on a large project converting existing MSI based packages to APP-V 4.6 and we are finding we are using the solution more and more.

    Java has not been a problem we have sequenced around 30 runtime environment versions and simply added the Dynamic Suite to the dependant application.

     Rgds Mike.

    Friday, May 21, 2010 12:31 PM