none
Exception: Customization could not be loaded because the application domain could not be created - (Excel Add-in VS2012/Office Proff. Plus 2010)

    Question

  • I've developed and Add-in for Office Proffessional Plus 2010 in VS2012. The Add-inn works fine in the development computer but it will not load in the client computer.

    The log file:

    Customization URI: file:///F://QuickMatch/

    Exception: Customization could not be loaded because the application domain could not be created.

     

    ************** Exception Text **************

    Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException: Customization could not be loaded because the application domain could not be created. ---> Microsoft.VisualStudio.Tools.Applications.Deployment.DeploymentInnerException: Downloading file:///F://QuickMatch/TranMatchAddIn.vsto did not succeed.

    at Microsoft.VisualStudio.Tools.Office.Runtime.SolutionInstaller.Install(ClickOnceAddInDeploymentManager clickOnceAddInDeploymentManager, OfficeAddInDeploymentManager officeDeploymentManager, AddInInformation& info)

    at Microsoft.VisualStudio.Tools.Office.Runtime.SolutionInstaller.ProcessInstallerOperation(ClickOnceAddInDeploymentManager clickOnceAddInDeploymentManager, OfficeAddInDeploymentManager officeAddInDeploymentManager, AddInInformation& info)

    at Microsoft.VisualStudio.Tools.Office.Runtime.SolutionInstaller.ProcessInstallerOperation(ClickOnceAddInDeploymentManager clickOnceAddInDeploymentManager, OfficeAddInDeploymentManager officeAddInDeploymentManager, Boolean showUIDuringDeployment)

    at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.GetAssemblyDataFromManifests(String solutionLocation, String manifestLocator, String documentName, Boolean showUIDuringDeployment, CustomizationType customizationType, OfficeVersion officeVersion, IHostServiceProvider interopServiceProvider)

    at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, Boolean useFastPath, IntPtr& executor)

    --- End of inner exception stack trace ---

     

    ************** Loaded Assemblies **************

    mscorlib

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

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

    Microsoft.VisualStudio.Tools.Office.Runtime.v10.0

    Assembly Version: 10.0.0.0

    Win32 Version: 10.0.40302.0

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Office.Runtime.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Office.Runtime.v10.0.dll

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

    System

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll

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

    System.Core

    Assembly Version: 3.5.0.0

    Win32 Version: 3.5.30729.5420 built by: Win7SP1

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll

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

    Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0

    Assembly Version: 10.0.0.0

    Win32 Version: 10.0.40302.0

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0.dll

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

    System.AddIn

    Assembly Version: 3.5.0.0

    Win32 Version: 3.5.30729.5446 built by: Win7SP1GDR

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.AddIn/3.5.0.0__b77a5c561934e089/System.AddIn.dll

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

    Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0

    Assembly Version: 10.0.0.0

    Win32 Version: 10.0.40302.0

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0.dll

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

    Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0

    Assembly Version: 9.0.0.0

    Win32 Version: 9.0.30729.5806

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0/9.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll

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

    Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0

    Assembly Version: 10.0.0.0

    Win32 Version: 10.0.40302.0

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0.dll

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

    System.Windows.Forms

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5460 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

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

    System.Drawing

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5462 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

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

    System.Deployment

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Deployment/2.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll

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

    System.Configuration

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

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

    System.Xml

    Assembly Version: 2.0.0.0

    Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll

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

     

    Thursday, December 06, 2012 1:18 AM

Answers

  • Hi Albert,

    Glad to hear that you were able to resolve the problem.

    For those who might stumble into this thread, here's a more thorough follow-up:

    We have recently discovered an issue where add-ins deployed using the ClickOnce method will, under certain conditions, try and fail to install an update, and thereby disable the add-in.  For document-level customizations, the stack trace provided by Damian will be shown; for application-level add-ins, the add-in will be disabled silently.  This was only discovered last week, and we are hard at work on providing a fix.  We don’t have a publicly-available timeline for when we can release the fix yet, but we are aware of the severity of the issue, and are doing everything in our powers to get this out to customers as quickly as we can.

    As a preventative measure until we can distribute a fix, we would recommend that developers re-publish their add-ins with updates set to "Never check for updates", as described in my earlier response to Albert (from Saturday, December 08, 2012), or to a very large number of days.  This way, users who haven't experienced the issue yet won't experience it again.  Of course, disabling automatic update checking does mean that users would need to be explicitly notified about your next update.  Once we provide a fix to the VSTO Runtime, you can set automatic updates back to enabled, but users will still need to explicitly install the first auto-updating version of your add-in, after the fix.  Again, our sincere apologies for the inconvenience!


    For users who are already impacted:

    If the install location is still accessible (and/or if the developer puts a new version into the same location)
    1. Re-run setup from the original network share.  
    2. Re-enable the Add-In / Doc-Level Customization from within the Office application, as described below.

    If the install location is NOT accessible (e.g., network share permanently down, or file was installed off of a USB stick which has since been removed)
    1. Launch “regedit.exe” from the start menu / start screen.  Navigate to Computer ==> HKEY_CURRENT_USER ==> Software ==> Microsoft ==> VSTA ==> Solutions.
    2. There should be several entries there, identified by GUIDs.  Click on each entry and check the “ProductName” data until you find the Add-In that you’re trying to re-enable.
    3. For the Add-In that’s having problems, double-click on UpdateEnabled.
    4. Change the “Value data” to 0 and press “OK”.  This will disable Update Checking (and hence cure the problem) until a new version of an add-in is explicitly installed, or until the user repeats the same steps, and sets “UpdateEnabled” to “1”.


    After editing the Registry, the user should re-launch the Office App (e.g., Excel), and go through the usual steps of re-enabling the add-in (see below).

    The usual steps of re-enabling the add-in: (required in either case for any user with currently-disabled add-ins)
    1. Open the application’s options (e.g., “Excel Options”) and navigate to the Add-Ins tab.
    2. Select “COM Add-ins” from the “Manage” dropdown.
    3. Press “Go…”.  A window will open.
    4. Enable the checkbox for the Add-In(s) that you’d like to re-enable.
    5. Click “OK”.




    After performing the above steps, the add-in / document-level customization should re-activate in the host application, and also show up in the Control Panel’s “Add or Remove Programs” list.

    I will keep this thread updated once a fix is available.  Again, apologies for the inconvenience, and please let me know if you have any questions.


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Wednesday, December 12, 2012 8:45 PM
    Moderator
  • Hi Thomas,

    As I said, we are aware of the severity of the issue, and we are working on a solution with all due haste.  If you follow the thread through to the top, you will see that we acknowledged the issue, reproduced it in-house, and had workaround steps literally within two days of the first report.

    In the corporate scenario, I think you certainly do have options, especially if the add-in is installed on a central location (e.g., file share, internal IIS server, etc).  Remember that the issue only manifests itself when an add-in tries and fails to fetch an update -- so for desktop computers on a corporate network, for instance, it's a moot point.  If you are seeking a preventative approach, the best thing for you as a developer might be to re-release the add-in with updates either disabled, or set to be checked every some-large-number of days.  If users are installing off of the network, the distribution channel for such update is virtually painless.

    Also, please note that the workaround above is only for those users who are already impacted.  Moreover, if the install location is persistent, users will be able to just re-run setup.exe without any registry hacking (though they will still need to re-enable the add-in).  If you place a new version of the add-in in place of the old one, this will achieve two goals simultaneously:  you will both get users un-stuck, and get them to upgrade to a version that will not exhibit the problem.

    I will certainly keep the thread posted once we have a software update available for customers.  As I said, we're working hard on a fix.  Thanks for your patience.

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Thursday, December 13, 2012 10:03 PM
    Moderator
  • UPDATE:

    There is now a NEW VERSION of the VSTO Runtime that fixes the issue.  If you're using the web bootstrapper (for add-ins developed using Visual Studio 2010), the bootstrapper will automatically chain in the latest version, so no action is required on your part, or on that of your users.  If you're deploying from Visual Studio 2012,  you'll need to enable the bootstrapper functionality manually:  please see http://blogs.msdn.com/b/vsto/archive/2012/12/21/creating-a-bootstrapper-package-for-an-office-2013-vsto-add-in-with-visual-studio-2012.aspx.  Users can also download the latest runtime from http://go.microsoft.com/fwlink/?LinkId=140384 or from Microsoft Update.

    Installing the new Runtime is a preventative measure, and we highly recommend that all of your users do so!  However, this will not fix add-ins that may already have gotten disabled due to the issue.  Thus, for add-ins that are already experiencing an issue, see the steps provided on December 12 (or just search for "For users who are already impacted" on this page).

    Thanks for your patience, everyone!


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office


    Saturday, December 22, 2012 1:18 AM
    Moderator

All replies

  • do you have proper vsto runtime installed on that machine?
    Thursday, December 06, 2012 7:47 AM
  • Yes, VSTO Runtime is installed in the target machine.


    Albert

    Thursday, December 06, 2012 10:29 AM
  • Hi Albert,

    Thanks for posting in the MSDN Forum.

    I suppose your create the publish package via right click on project and select the "Publish" Item on the menu. Then you get publish wizard, fill the physical path of the add-in content files instead "publish\" in "Specify the location to publish this application" filed. The key problem lays here. Please use default value of the wizard in this section.

    If I have misunderstand anything please feel free to let me know.

    Have a good day,

    Tom 


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, December 07, 2012 7:21 AM
    Moderator
  • Thanks for your input Tom. I should explain a bit more about the project: the deployment is done with InstallShield Limited Edition.

    The Add-in installs without problems but can not be loaded into Excel.

    All Files, Registry Keys and setting are as recommended by Office Solutions documentation in MSDN for VS2012 and Office Plus 2010.

    I have also tried the same project with VS2010 and Office Plus 2010 and I have the same problem

    I would appreciate any help you can provide

    Albert Soffici (MSDN Subscriber)

    Evolucion Pty Ltd


    Albert

    Friday, December 07, 2012 12:59 PM
  • if possible, show us vsto file for your add-in and vstor version (for example screenshot of Programs and features with that vstor selected).
    Friday, December 07, 2012 2:16 PM
  • Hi Albert,

    The error in the stack trace actually looks like a ClickOnce error.  This might be related to a recently-discovered issue where add-ins deployed using the ClickOnce method will, under certain conditions, try and fail to install an update, and thereby show the error you described, followed by disabling the add-in.  This was only discovered a few days ago, but we’re aware of the issue, and are hard at work on providing a fix.  We don’t have a publicly-available timeline for when we can release the fix, but we are aware of the severity of the issue, and are doing everything in our powers to fix it and get it out to customers.

    From a developer's perspective, the solution, for now, is to disable automatic update checks.  In your project properties, go to the “Publish” tab and click “Updates…”  In the window that opens, choose the “Never check for updates” option.  See screenshot below.  When you're done, re-publish under an updated version number.

    If your users are able to see your program in Add/Remove Programs, simply have them uninstall the old one and re-install the new one.

    If the add-in is show in Add/Remove Programs, but for some reason does not load in the Office host program, the user may need to re-enable it (Office automatically disables Add-Ins that threw an exception).  This can be done by going to the Office program's "Options" --> "Add-Ins".  Find the "Manage" dropdown at the bottom of the screen, and choose "Disabled Items".  Click "Go".  In the window that pops up, select the add-in that you'd like to re-enable, and click "Enable".  Click "Close" when you're done.  You may need to re-start the host Office program, but the Add-In should now be enabled.  Hopefully this fixes the issue (though whatever triggered the add-in to get disabled may happen again, if you don't turn updates off.  Hence, I would recommend you give your users a new version of your add-in, that has the update-check disabled).

    I hope this solves your problem, and please us know me know if you're still experiencing issues.  My sincerest apologies for the inconvenience this caused to you and your customers.


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Saturday, December 08, 2012 2:11 AM
    Moderator
  • Thank you for your response.

    After different attemps the problem could not be fixed and I decided to do a "repair" of the Visual Studio installation. That resolved the problem.

    Thanks again for your help.

    Albert Soffici


    Albert

    Tuesday, December 11, 2012 4:51 AM
  • Hi Albert,

    Glad to hear that you were able to resolve the problem.

    For those who might stumble into this thread, here's a more thorough follow-up:

    We have recently discovered an issue where add-ins deployed using the ClickOnce method will, under certain conditions, try and fail to install an update, and thereby disable the add-in.  For document-level customizations, the stack trace provided by Damian will be shown; for application-level add-ins, the add-in will be disabled silently.  This was only discovered last week, and we are hard at work on providing a fix.  We don’t have a publicly-available timeline for when we can release the fix yet, but we are aware of the severity of the issue, and are doing everything in our powers to get this out to customers as quickly as we can.

    As a preventative measure until we can distribute a fix, we would recommend that developers re-publish their add-ins with updates set to "Never check for updates", as described in my earlier response to Albert (from Saturday, December 08, 2012), or to a very large number of days.  This way, users who haven't experienced the issue yet won't experience it again.  Of course, disabling automatic update checking does mean that users would need to be explicitly notified about your next update.  Once we provide a fix to the VSTO Runtime, you can set automatic updates back to enabled, but users will still need to explicitly install the first auto-updating version of your add-in, after the fix.  Again, our sincere apologies for the inconvenience!


    For users who are already impacted:

    If the install location is still accessible (and/or if the developer puts a new version into the same location)
    1. Re-run setup from the original network share.  
    2. Re-enable the Add-In / Doc-Level Customization from within the Office application, as described below.

    If the install location is NOT accessible (e.g., network share permanently down, or file was installed off of a USB stick which has since been removed)
    1. Launch “regedit.exe” from the start menu / start screen.  Navigate to Computer ==> HKEY_CURRENT_USER ==> Software ==> Microsoft ==> VSTA ==> Solutions.
    2. There should be several entries there, identified by GUIDs.  Click on each entry and check the “ProductName” data until you find the Add-In that you’re trying to re-enable.
    3. For the Add-In that’s having problems, double-click on UpdateEnabled.
    4. Change the “Value data” to 0 and press “OK”.  This will disable Update Checking (and hence cure the problem) until a new version of an add-in is explicitly installed, or until the user repeats the same steps, and sets “UpdateEnabled” to “1”.


    After editing the Registry, the user should re-launch the Office App (e.g., Excel), and go through the usual steps of re-enabling the add-in (see below).

    The usual steps of re-enabling the add-in: (required in either case for any user with currently-disabled add-ins)
    1. Open the application’s options (e.g., “Excel Options”) and navigate to the Add-Ins tab.
    2. Select “COM Add-ins” from the “Manage” dropdown.
    3. Press “Go…”.  A window will open.
    4. Enable the checkbox for the Add-In(s) that you’d like to re-enable.
    5. Click “OK”.




    After performing the above steps, the add-in / document-level customization should re-activate in the host application, and also show up in the Control Panel’s “Add or Remove Programs” list.

    I will keep this thread updated once a fix is available.  Again, apologies for the inconvenience, and please let me know if you have any questions.


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Wednesday, December 12, 2012 8:45 PM
    Moderator
  • Hi Michael,

    good, that you at least acknowledged the fact that there is a bug. Your proposed workaround works, but is useless, because cannot be done. As you know the key is unique to each user, so we cannot use any tool we have to do a bulk change in our network environment.

    I will not tell 1000+ users to go to their registry and change one value and when you release the patch, do to the same.

    Do you have some solution we can use in corporate environment ?

    Thank you

    Tomas


    Tomas Paulas MCP,MCSA,MCSA-Messaging

    Thursday, December 13, 2012 8:03 PM
  • you can write logon script in powershell or custom app that will modify needed registry value
    Thursday, December 13, 2012 8:20 PM
  • Hi Thomas,

    As I said, we are aware of the severity of the issue, and we are working on a solution with all due haste.  If you follow the thread through to the top, you will see that we acknowledged the issue, reproduced it in-house, and had workaround steps literally within two days of the first report.

    In the corporate scenario, I think you certainly do have options, especially if the add-in is installed on a central location (e.g., file share, internal IIS server, etc).  Remember that the issue only manifests itself when an add-in tries and fails to fetch an update -- so for desktop computers on a corporate network, for instance, it's a moot point.  If you are seeking a preventative approach, the best thing for you as a developer might be to re-release the add-in with updates either disabled, or set to be checked every some-large-number of days.  If users are installing off of the network, the distribution channel for such update is virtually painless.

    Also, please note that the workaround above is only for those users who are already impacted.  Moreover, if the install location is persistent, users will be able to just re-run setup.exe without any registry hacking (though they will still need to re-enable the add-in).  If you place a new version of the add-in in place of the old one, this will achieve two goals simultaneously:  you will both get users un-stuck, and get them to upgrade to a version that will not exhibit the problem.

    I will certainly keep the thread posted once we have a software update available for customers.  As I said, we're working hard on a fix.  Thanks for your patience.

    - Michael


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office

    Thursday, December 13, 2012 10:03 PM
    Moderator
  • UPDATE:

    There is now a NEW VERSION of the VSTO Runtime that fixes the issue.  If you're using the web bootstrapper (for add-ins developed using Visual Studio 2010), the bootstrapper will automatically chain in the latest version, so no action is required on your part, or on that of your users.  If you're deploying from Visual Studio 2012,  you'll need to enable the bootstrapper functionality manually:  please see http://blogs.msdn.com/b/vsto/archive/2012/12/21/creating-a-bootstrapper-package-for-an-office-2013-vsto-add-in-with-visual-studio-2012.aspx.  Users can also download the latest runtime from http://go.microsoft.com/fwlink/?LinkId=140384 or from Microsoft Update.

    Installing the new Runtime is a preventative measure, and we highly recommend that all of your users do so!  However, this will not fix add-ins that may already have gotten disabled due to the issue.  Thus, for add-ins that are already experiencing an issue, see the steps provided on December 12 (or just search for "For users who are already impacted" on this page).

    Thanks for your patience, everyone!


    Michael Zlatkovsky | Program Manager, Visual Studio Tools for Office & Apps for Office


    Saturday, December 22, 2012 1:18 AM
    Moderator