How to Simultaneously Load a Beta and Production Version of the Same App? RRS feed

  • Question

  • I realize I can work around this with more VMs, but I would like to be able to run two versions of the same app on the same machine.

    I have <Prod_App_Name> at one version and the newer version at <Prod_App_Name-beta> as the name of the app at the newer revision.

    I have the two builds differing by:

    • Assembly Name
    • Assembly Product
    • Assembly version
    • Publish folder
    • Installation folder
    • Publish version

    The two apps will install separately and list themselves separately in the add/remove programs, BUT when calling My.Application.Info.Version, both apps return the same value and both share the same My.Settings.*

    There must be a single field which Windows uses to determine a distinct .Net assembly.  What is it?


    Denis Burke

    This is a .Net 3.5SP1 Excel document-level add-in in VB.

    Monday, September 10, 2012 3:21 AM

All replies

  • Your question about your Visual Basic app will be best answered by the VB developers in the VB forums, here:

    This forum supports installation and setup of the .NET Framework itself.

    Thank you for understanding.

    Monday, September 10, 2012 12:55 PM
  • Hi Denis,

    I am moving your case to the Visual Studio Tools for Office forum so that you can get better support.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, September 11, 2012 2:47 AM
  • Anyone have any idea?  I have tried changing every property that I could possibly see used to differentiate two apps, but it always seems to treat v1 & v2 of the app as the same app despite my attempts to make it think they are two different apps.


    Denis Burke

    Wednesday, September 12, 2012 2:17 AM
  • paste here full content of assemblyinfo.vb

    Wednesday, September 12, 2012 11:28 AM
  • Imports System
    Imports System.Reflection
    Imports System.Runtime.InteropServices
    Imports System.Security
    Imports Microsoft.Office.Tools.Excel
    ' General Information about an assembly is controlled through the following 
    ' set of attributes. Change these attribute values to modify the information
    ' associated with an assembly.
    ' Review the values of the assembly attributes
    <Assembly: AssemblyTitle("PID")> 
    <Assembly: AssemblyDescription("")> 
    <Assembly: AssemblyCompany("XYZ, LLC")> 
    <Assembly: AssemblyProduct("PID-beta")> 
    <Assembly: AssemblyCopyright("Copyright © XYZ, LLC")> 
    <Assembly: AssemblyTrademark("PID (TM)")> 
    ' Setting ComVisible to false makes the types in this assembly not visible 
    ' to COM components.  If you need to access a type in this assembly from 
    ' COM, set the ComVisible attribute to true on that type.
    <Assembly: ComVisible(False)>
    'The following GUID is for the ID of the typelib if this project is exposed to COM
    <Assembly: Guid("be2b3364-8312-42b7-a943-636f77a006d3")> 
    ' Version information for an assembly consists of the following four values:
    '      Major Version
    '      Minor Version 
    '      Build Number
    '      Revision
    ' You can specify all the values or you can default the Build and Revision Numbers 
    ' by using the '*' as shown below:
    ' <Assembly: AssemblyVersion("1.0.*")> 
    <Assembly: AssemblyVersion("6.246.*")> 
    'by commenting out AssemblyFileVersion, it will default to using the required AssemblyVersion for AssemblyFileVersion
    '<Assembly: AssemblyFileVersion("3.2.*")> 
    ' The ExcelLocale1033 attribute controls the locale that is passed to the Excel
    ' object model. Setting ExcelLocale1033 to true causes the Excel object model to 
    ' act the same in all locales, which matches the behavior of Visual Basic for 
    ' Applications. Setting ExcelLocale1033 to false causes the Excel object model to
    ' act differently when users have different locale settings, which matches the 
    ' behavior of Visual Studio Tools for Office, Version 2003. This can cause unexpected 
    ' results in locale-sensitive information such as formula names and date formats.
    <Assembly: ExcelLocale1033(True)> 
    <Assembly: SecurityTransparent()> 

    Wednesday, September 12, 2012 11:34 AM
  • ok, so try changing following:





    this all should be different between your beta and stabe products if you want then to work side by side

    • Marked as answer by Forrest GuoModerator Monday, September 24, 2012 12:34 PM
    • Unmarked as answer by burkeden Monday, September 24, 2012 12:47 PM
    Wednesday, September 12, 2012 12:58 PM
  • I don't think this is good practice. Even if you managed to do this, you get two different apps in the end.


    Forrest Guo | MSDN Community Support | Feedback to manager

    Monday, September 24, 2012 12:36 PM
  • This does not work for me.  When I change all of the properties above, the apps still share the same My.Application.Settings and also report the same version of the code (they report whichever was the most recently installed).

    There is obviously something else which Windows of the .NET framework is treating as the unique identifier to know which app is which.  Surprising to me even that even a different GUID does not seem to let them operate as distinct apps.

    Monday, September 24, 2012 12:47 PM
  • Agreed - not a good practice.  It is a short cut, but at times a practical one.  We have cases when it would be convenient to run both a production version and a beta version of the app on the same machine (or VM). 
    Monday, September 24, 2012 12:49 PM