Problem with VSTOInstaller.Config RRS feed

  • Question

  • Hi!

    I have a problem with a developed application due to the VSTOInstaller.Config file. I have found the origin of the problem; for this reason I wish to understand the differences between:

    • Microsoft.Office.BusinessApplications.RunTime.DeploymentAction.HttpFbaRequestCreator
    • Microsoft.Office.BusinessApplications.Fba.HttpFbaRequestCreator

    I have not found some documentation about those lines contained in the VSTOInstaller.Config file.

    I want also to know/understand If I delete/rename the configuration file, will be there problems with other Microsoft applications?

    Thanks in advance for your help!


    --- Miguel-Angel

    Monday, October 20, 2014 1:24 PM

All replies

  • Hello Miguel,

    Why do you thin the issue is related to the config file?

    Could you please describe your initial issue instead?

    Anyway, you may find the Outlook addin developed for Office 2010 can not install using clickonce on office 2013 forum thread helpful.

    Monday, October 20, 2014 2:43 PM
  • Hi !

    Thanks for your answer. I think that the issue is related with the config file because if I replaced the references to "...BusinessApplications.Fba...." by "...BusinessApplications.Runtime.DeploymentAction...", the installation works fine!.

    For example, I replaced the line

    As result, I don't get the message:

    "The value of the property 'type' cannot be parsed. The error is: Could not load file or assembly 'Microsoft.Office.BusinessApplications.Fba, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependancies. The system cannot find the file specified. (C:\Program Files (x86)\Common Files\Microsoft Shared\VSTO\10.0\VSTOInstaller.exe.Config line 10)"

    Thanks for your comments and your help!


    --- Miguel-Angel
    • Proposed as answer by learner1999 Thursday, February 8, 2018 1:19 AM
    • Unproposed as answer by learner1999 Thursday, February 8, 2018 1:19 AM
    Monday, October 20, 2014 3:16 PM
  • Hi Miguel,

    As far as I know, the VSTOInstaller.Config doesn't exist by default. And the Microsoft.Office.BusinessApplications.Runtime, which is a SharePoint runtime library assembly. Please remove it if you don't use this library.

    Please check the same topic thread below to see whether it is helpful:

    Best regards


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, October 21, 2014 9:43 AM
  • As far as I know, the VSTOInstaller.Config doesn't exist by default. And the Microsoft.Office.BusinessApplications.Runtime, which is a SharePoint runtime library assembly. Please remove it if you don't use this library.

    That might sound like a solution, but it really isn't. This problem occurs on multiple client machines who seemingly installed some Microsoft product which added the config file. Maybe removed the program again, which makes the failure understandable from a developer point of view.

    However, this problem happens to a lot of our customers, mostly people using our product downloaded from our web store. If they never get it installed, they will never are going to use it. And they are definitely not going to remove the file on their own, they will just skip the product, and move on.

    Tuesday, October 21, 2014 10:59 AM
  • Fei,

    That's exactly what I mentioned in my reply above.

    Tuesday, October 21, 2014 11:51 AM
  • Hi All,


    Thanks for your contribution on this thread:)


    Since this issue is complex, I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.

    Sorry for any inconvenience and have a nice day!

    Best regards


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, October 24, 2014 7:35 AM
  • Miguel,

    It appeares that some machines may contain this VSTOInstaller.Config file where it (in a clean install) should not be there. Obviously, in the real world where machines have older installs or applications installed this seems to be just a fact of life so we must think of a workaround.


    - VSTO Teams adjusts their installer and removes the file

    I seriously doubt that they would want to implement that option as the origin of the file might not be determined and will imply that certain risks are in place doing so

    - Pre-check on installation of your addin to see if the file exists and either remove it yourself (like option 1 not advised) or present a dialog where you explain the issue and propose to uninstall VSTO, delete the containing file/folder and reinstall VSTO.

    - Add it to a known issues document that you add to your installer/put on your website

    Overal this is one of the burdens we software developers encounter each and every day :-( Non clean machines with all sorts of previous installed software packages and configurations.

    As said by Fei, the file should not be there in the first place but it simply is not that easy to solve it. I'd suggest to go for options 2 and/or combine it with option 3 while the VSTO PG can break their heads to decide if and how they can solve this for future releases.

    Software Engineer * MVP-Visual Developer-VSTO

    Friday, October 24, 2014 9:20 AM
  • I don't think your proposed solutions make sense.

    1. "VSTO Teams adjusts their installer and removes the file" > No, not really. The file is there for a reason, I suspect the Sharepoint SDK to be the problem here. I guess that for some reason, the referenced assemblies disappear, and that's the reason the installer fails;

    2. "Pre-check on installation of your addin to see if the file exists and either remove it yourself" > Not a real solution, since you need admin access to delete that file, and most enterprise users don't have that. Clickonce runs using user privileges, so it is really a bad thing to change that to workaround this bug.

    3. "Add it to a known issues document that you add to your installer/put on your website" > People don't read it, and if they do, they will hardly understand it. Net effect: they will never use the product.

    4. "the file should not be there in the first place" > Tell that to the Sharepoint team who apparently thinks it should.

    Friday, October 24, 2014 9:35 AM
  • Sure, I agree. The options that I proposed are however IMO the only real world solutions to think of at this time. We need to think in solutions not in problems.

    All of your suggestions are 'said in a nice way' in my first option. There was a reason I ended with my comment: "while the VSTO PG can break their heads to decide if and how they can solve this for future releases" :-)

    Fei forwarded the issue to the PG (Product Group) internally for them to look for a solution. From my experience this will take some significant time as the right team needs to be identified to research and solve the issue when the cause is identified.

    As said for -now-, thinking in solutions, your only options are option 2 and 3 while Microsoft is trying to get this fixed.


    Software Engineer * MVP-Visual Developer-VSTO

    Friday, October 24, 2014 9:54 AM
  • I have found that even on clean installs this file is present (we always use a clean vmware to test and even in those machines, Windows 7 32/64 bit, Office 2013 32/64 bit) it appears.

    Reproduction scenario:

    1. Install some W7 edition + all updates

    2. Install O2013 professional + all updates

    3. Start clickonce product which uses VSTO (installs dependencies automatically).

    4. Error

    So this problem even occurs with clean installs. Alternative is to either stop using clickonce and switch to msi which allows a developer to execute code with elevated privs to remove or adapt the file. Or document it in a separate file or startup program (which we've learnt is almost never read... users....). ClickOnce offers no possibility as far as I know to execute some code before the error is raised.

    Friday, October 24, 2014 10:07 AM
  • Have you checked between each step configuring your image at what stage the file is inserted? Hell of a job to find out at what time/where it is inserted.

    With the latest version of VSTO you can execute custom actions, even with ClickOnce:


    You can even combine projects, so you could for instance create a dummy project in front of your current project that will do the checking and warning stuff.

    Software Engineer * MVP-Visual Developer-VSTO

    Friday, October 24, 2014 10:18 AM
  • But the installer doesn't even get to reading the manifest, so you can't do something before the error.
    Friday, October 24, 2014 10:29 AM
  • If that is the case, even with the combined projects in a single installer, then your options are down to either .MSI or adding the "Known Issues" statement on your web.

    Software Engineer * MVP-Visual Developer-VSTO

    Friday, October 24, 2014 10:38 AM
  • So your solution is "don't use ClickOnce, use MSI". Okay...
    Friday, October 24, 2014 11:50 AM
  • If you are locked on your ClickOnce installation MSI is your alternative option. For instructions see this link:


    Software Engineer * MVP-Visual Developer-VSTO

    Friday, October 24, 2014 11:58 AM
  • Eugene, Patrick, Maoroshdez,

    I'm a Program Manager on VSTO, and had this thread forwarded to me by Maarten van Stam (below).

    We'd like to understand the issue a little more, so we can reproduce it in-house and assess the possibility of a fix.

    Could you describe the system configuration where you're seeing this VSTOInstaller.config file get installed?  E.g., what versions of Office do you have on the box?  Do you have any SharePoint or BCS (Business Connectivity Services) components installed?  What version of VSTO and .NET does your application target?...   Basically, do you have information on how to set up an environment similar to yours, so we can experience your pain?


    - Michael

    Michael Zlatkovsky | Program Manager, Visual Studio

    Thursday, October 30, 2014 6:26 PM
  • Thanks a lot for your answer!

    This problem occurs when the configuration file (VSTOInstaller.Config) exists and it contains:


    This problem occurs with Windows 8.1, Microsoft Visual Studio tools for Applications x64 Runtime 3.0 Versión 10.0.40220.

    The installation of VSTO is required for our application.

    We have found if the VSTO for 64 bits is installed (but not registered) and the Configuration file exists in the directory for VSTO for 64 bits, the installation and the registration of VSTO for 32 bits are asked.

    We installed the VSTO for 32 bits. After, we observe that the VSTO for 32 bits uses the Configuration file installed in the directory for VSTO for 64 bits!

    The solution adopted for us was:

    1. delete the directory for VSTO 64 bits

    2. delete the configuration file if it exists in the directory for VSTO 32 bits because our application does not require this file.

    Thanks a lot for all your answers and help!


    --- Miguel-Angel

    Thursday, October 30, 2014 7:44 PM
  • We are also experiencing the same issue with ClickOnce deployment (this time for PowerPoint add-in). 

    Error occurs after user launches setup file. The setup spends some on obtaining the customization manifests and then shows this error. The error occurred on Win 7 + office 2010 and Win 8 + office 2013 (fresh). Feel free to try running setup from here

    Notably, we had experienced this error a while ago, but fixing references seems to have solved the problem. For that time. 

    • Edited by herrpuqq Friday, October 31, 2014 1:25 PM
    Friday, October 31, 2014 1:23 PM
  • First of all, thanks Michael for actually picking this up. This issue is very annoying to a lot of our customers.

    I am trying to reproduce this issue from a clean installation, but I can't seem to succeed while I previously did.

    I have some notes though on my experience. Here the config of two machines:

    PC1: Windows 7 VM, 64 bit, .NET 4.5.1, Office 2013 PP with some language packs installed (installed some time ago, no metrics)

    PC2: Windows 8.1 with update 1 VM, .NET 4.5.2, Office 2010 Pro

    PC3: Windows 8.1 with update 1 VM, .NET 4.5.2, Office 2013 PP with Dutch language pack installed

    1. On installation of Office on PC2, it didn't create the VSTOInstaller.exe.config file. Nor did it after all the updates.

    2. On installation of Office on PC3, it instantly creates the config file. Also it adds the Microsoft.Office.BusinessApplications.Fba.dll assembly in the GAC, although the version is off compared to the config file. (Config =, assembly = 15.0.4420.1017)

    3. On PC1, there was a config file already, but the assembly is missing from the GAC.


    So I wonder. Was there a security update for Windows 7 removing the 'bad' Microsoft.Office.BusinessApplications.Fba.dll or something like that? What causes the assembly to appear in the GAC or not?

    Friday, October 31, 2014 4:05 PM
  • Chipping in as well, we ran into this issue with a single client about a month ago. We have an Excel add-in tested for Excel 2007+, using ClickOnce for deployment.

    After trying a couple of basic steps (repairing VSTO 2010, Office) we tried re-naming the VSTOInstaller.exe.Config to 'hide' it from the installation and it appears to be working. Client then re-named the file back as a precaution, in case anything else was using this file.

    I believe client was using Win 7 / Excel 2012, but can't confirm for sure. Other clients (including clients at the same company) on a variety of setups have had no issues with the installation. I'm not sure if they have the .exe.config file or not.

    I noticed on my machine that I have a VSTOInstaller.config file (Note, not *.exe.config, as seen from client). Not sure if that's relevant or not.

    Would be nice to know what the origin of the .exe.config file is; is it a part of vsto / office? Does it come from Microsoft or not? It is safe to remove? What applications might be dependent on it? etc. etc.

    Monday, November 3, 2014 6:17 PM
  • i2ellis, Patrick, herrpuqq,

    Thanks for your replies and providing the information. Based on the info in this thread, I have reached out to a few folks on my team who have experience with VSTOInstaller.exe.config, and we are currently investigating what might be going on here.  We have a few guesses, and are working on confirming them.

    I will reach out back to this thread once we have more info, or if there's additional information we'd like to check with you on.


    - Michael

    Michael Zlatkovsky | Program Manager, Visual Studio

    Monday, November 3, 2014 8:37 PM
  • Keep us posted :)
    Thursday, November 6, 2014 3:41 PM
  • Any news?...
    Monday, November 10, 2014 9:20 AM
  • This clarification may help:

    Apparently, VSTOInstaller.config is present after standard installations of some Office products, at least under "Program Files\..." on a 64-bit machine. When present, it references "Microsoft.Office.BusinessApplications.Runtime.DeploymentAction.HttpFbaRequestCreator". This is *not* a problem.

    On *some* machines (I also have customers with this problem) there is, in addition to VSTOInstaller.config, a file VSTOInstaller.exe.config.  This file takes preference over VSTOInstaller.config when it exists. In *this* file (VSTOInstaller.exe.config) the reference is to "Microsoft.Office.BusinessApplications.Fba.HttpFbaRequestCreator" and *this* is the case that fails.

    So someone needs to find out who is installing VSTOInstaller.exe.config, *not* who is installing VSTOInstaller.config.

    This should definitely be handled as a highest priority bug at Microsoft, since this is currently *killing* Office Add-In businesses, and any workaround which involves Administrator priviledges is *not ok*, since that goes against the entire Add-In business model, which says any user can install.

    Tuesday, November 11, 2014 11:42 AM
  • Hello Michael,

    any news on this issue? Regards, Guido

    Tuesday, November 11, 2014 3:35 PM
  • Still looking for an update on this, does it make sense at this point to log a bug?

    Let us know if there is anything we can do to help out :)

    Monday, November 17, 2014 7:57 PM
  • Hi i2ellis, Guido, Robert, herrpuqq,


    Our investigation is still in progress (and not to worry, we do have an internal bug tracking this), but I wanted to share a bit of news with you.  Per initial investigations, the VSTOInstaller.exe.config file is laid down by Business Connectivity Services, which is part of the Office "ProPlus" SKU.  That should account for the difference of why some computers have it, some do not.  The trickier part is understanding when does the presence of that file cause issues – because generally, it should not (in fact, it is needed for BCS to work correctly).  This is the part that we’re currently working on.


    Very broadly, VSTOInstaller.exe.config points at some files in the GAC that get loaded alongside VSTO to fulfill BCS scenarios (but because the file is global, they get loaded for other add-in installation as well). This should “just work”.  However, if the assemblies referenced by the config file are missing from the Global Assembly Cache, that’s where you get this issue.  I believe a repair of Office may put those files back in place, but obviously, that’s still not a very adequate workaround.  The same goes for the workaround that other folks have suggested (remove or rename the offending config file) – while it does solve the problem, that’s ultimately not the right thing to force users to do.  What we are trying to understand is *what* makes the files go missing from the GAC, and if there’s any sequencing that forces the issue to appear (for example, could the order of installation of .NET vs. Office be causing this?)


    If folks have thoughts on the matter – or concrete steps for when the issue does or does not appear – we would be delighted to hear these!  I’ll keep you posted as we dig further into this.



    - Michael Zlatkovsky | Program Manager, Visual Studio

    Michael Zlatkovsky | Program Manager, Visual Studio

    Tuesday, November 18, 2014 10:23 PM
  • Thanks for the update Michael,

    What you've described seems to line up with our observations here. It looks like the VSTOInstaller.exe.config has priority, and is pointing to GAC files that the user does not have. I can't tell for sure whether the user never had these files, or whether the user had them at one point and they have been removed.

    As mentioned, during our initial investigation, we had our client do a repair of Office and it did not bring back the assembly. Our solution was to (temporarily) rename VSTOInstaller.exe.config, but as you've mentioned, that shouldn't be the solution. The GAC file appears to be related to Sharepoint.

    I will add that we use ClickOnce's automatic update to push an update to our Excel Add-In recently. So far, our client has not reported an issue, although since we did not update very much between versions it's possible that the user failed to update silently and hasn't noticed they are on an old version. I believe the .exe.config file still exists on their computer (or at minimum we haven't removed it)

    I could try and get more information about the client's machine, but would prefer not to provoke a client at this point (our add-in is "working", and I don't want fix what isn't broken).

    Will continue to monitor this thread and add anything relevant. :)

    • Edited by i2ellis Thursday, November 20, 2014 6:46 PM Touch-ups
    Thursday, November 20, 2014 6:44 PM
  • Hi Michael,

    thanks for your update. Is there any other way as a workaround that we can offer customers to repair their GAC for BCS? Office update does not seem to fix it.



    Tuesday, December 9, 2014 1:36 PM
  • Saludos, 

    Hoy se me presento ese inconveniente, y ya pude resolverlo.

    Richard Vera G.

    Wednesday, December 10, 2014 3:02 PM
  • Is there any news on this bug? I am running it often during Office 2013 deployments.
    Thursday, January 22, 2015 9:11 AM
  • Any update on this?

    We are also running into this issue testing for Office 2013 compatibility of our Add-In.  A little more info I can contribute:

    In preliminary test of Office 2013 installed on top of 2010 didn’t see the problem, but did still have some 2010 stuff remaining on the machine, so suspect still had the remnants of 2010 that were needed.

    Now, in testing on a “clean” machine – (re-imaged with Windows 7, install Office 2013, all updates), then run our vsto’s.  Our main vsto installs fine (and installs dependencies such as .NET 4.0).  We see the problem with a second vsto that is installing some BCS stuff.   It’s the same error about the BusinessApplications.Runtime version 14.0.  I had noticed that the version in the GAC is 15.0.  I tried manually changing the VSTOInstaller.exe.config file’s 14.0’s to 15.0’s, then everything matches in the GAC, but then I got an error on running the VSTO that the “solution cannot be loaded because the .NET Framework 3.5 is not installed:”  ????   (.NET Framework 4 is installed, needed for earlier version).

    Both of our vsto’s use BCS/SharePoint stuff, but I think our main vsto succeeds, as BusinessApplications.Runtime is only a dependency in the manifest, whereas the BCS vsto is actually trying to do a postAction with entry point into BusinessApplications.Runtime.

    Deleting the config file does not work for us, and when I run the bcs vsto, it recreates the config file.

    So far we don’t have a workaround for this.  Any upcoming fix?  Or other suggestions for us to be able to workaround this?  Thanks very much!

    Friday, February 13, 2015 8:39 PM
  • I ran in this too. I need to publish an addin for a part of our german goverment computer with Windows 8. Believe me, there are no admin rights. There's a rumor that someone has heared about someone who thought he has admin rights, but actually nobody has it.

    Is it realistic to count with a solution till 2nd march?


    VB.NET & C#.NET

    Tuesday, February 24, 2015 3:51 PM
  • Many of our customers are receiving exactly the same issue.

    Could we get an update on when this will be fixed?

    Wednesday, March 4, 2015 3:59 AM
  • Hi,

    We are also experiencing the same issue for RMXOutlookAddin2007..any one solved this issue??


    Wednesday, March 18, 2015 7:35 PM
  • "The value of the property 'type' cannot be parsed. The error is: Could not load file or assembly 'Microsoft.Office.BusinessApplications.Fba, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependancies. The system cannot find the file specified. (C:\Program Files (x86)\Common Files\Microsoft Shared\VSTO\10.0\VSTOInstaller.exe.Config line 10)"

    maoroshdey issue reproduced with the app NodeXL (http://nodexl.codeplex.com/downloads/get/806203 download and launch) run as “normal” user on Windows 8.1 x64 workstation (6.3.9600.0) with Office 2013 Pro Plus x86 (15.0.4569.1506). The workaround is “run as admin and then run as the user”.

    Here some details of the initial state of the workstation (before doing anything)

    1 – the GAC does not contain any Microsoft.Office.BusinessApplications.Fba,

    2 - VSTOInstaller.exe.config is present in x86 path (C:\Program Files (x86)\Common Files\Microsoft Shared\VSTO\10.0) but not in x64 (C:\Program Files\Common Files\Microsoft Shared\VSTO\10.0)

    Other remarks

    1 – After having run the installer as admin I found Microsoft.Office.BusinessApplications.Fba v14.0.0.0 registed inside the GAC

    2- monitored installation process running as admin, found there are calls to c:\windows\systems32\consent.exe

    • Edited by ol9981 Thursday, April 16, 2015 3:56 PM
    Thursday, April 16, 2015 3:51 PM
  • Any update or workaround for this issue ?

    It totally prevents us from releasing an installer for our VSTO plugin to our customers.

    Wednesday, May 13, 2015 1:01 PM
  • We are also looking for a solution for this problem.

    Are there any news from the development team?
    Is the fix already sheduled?


    Wednesday, June 3, 2015 4:02 PM
  • Micheal any update

    Friday, June 5, 2015 12:44 AM
  • Hi Michael,

    are there any news from your team about this issue?
    We are still waiting for a workaround to fix it.

    Thanks for your help,


    Wednesday, June 24, 2015 8:41 PM
  • Hello Mr. Zlatkovsky,

    Has any progress been made on this issue?

    It appears that you've let this issue go despite recurring requests over the last 6 months.



    Monday, July 27, 2015 4:11 PM
  • Some pingbacks cq. scripts to fix it (or just delete the file as Administrator, Microsoft does not seem to care about a resolution for it's business partners):

    StackOverflow: The value of the property type cannot be parsed.

    Magimetrics: business partner advice

    GoToMeeting: advice to it's customers.

    BIBA: advice to it's customers.

    Fruux Zendesk: advice to it's customers.

    Batchfile suggested. Thx
    • Edited by Guido Leenders Thursday, August 27, 2015 7:36 AM added batch file
    Thursday, August 27, 2015 7:35 AM
  • We've made available "Fix It" functionality in all of our products (especially the NON-VSTO :-). You can detect and fix this VSTOInstaller.exe.config problem with for instance the Diagnostics window in the Help menu of the free Invantive Query Tool. See https://www.linkedin.com/pulse/vstoinstallerexeconfig-causes-many-office-add-ons-fail-guido-leenders
    Friday, August 28, 2015 6:58 AM
  • Has an official fix for this been released by Microsoft yet?  This topic has been going on for a year now.  Our customers are experiencing the same issue.  Most of the time renaming the config file works, but for a few machines, we still have the issue.

    What is the status??

    Jeremy May Sr Software Engineer "The Cake, She's a LIE!"

    Friday, October 23, 2015 4:55 PM
  • (A year later..)

    Has an official fix for this been released by Microsoft yet ?

    This bug has been rattling around for 2 years now....

    Our users have permissions for installing Excel Addins, but not enough permissions to remove/rename files in their "C:\Program Files (x86)\Common Files\microsoft shared\VSTO\10.0" directory.

    Tuesday, November 15, 2016 11:04 AM
  • I have problems too several times with VSTOInstaller.Config file installing a NodeXL addon, I found the directory in error message, and change the config file name to .old... then I execute the installer and work. I hoppelly that work for others case.
    Tuesday, April 25, 2017 8:05 PM
  • Many thanks, sir!  Removing that file solved the issue I was having with an Outlook plugin that was not installing correctly.  
    Monday, July 24, 2017 4:39 PM
  • Thanks a lot. At least someone cared about this problem.
    Thursday, October 19, 2017 7:17 AM
  • Year 2018 - Microsoft still hasn't fixed this issue. :/ 
    I just pushed an update to my vsto addin and it failed in exactly this way

    My colleagues are not fortunate enough to own an admin account, so renaming the file is not an option for me. 

    Wednesday, January 17, 2018 12:04 AM
  • Can you explain what you did to fix the issue here?
    Wednesday, January 17, 2018 12:07 AM