Visual Studio SP1 (or specifically VSTO sp1) Issue with config file location

Posted by NeverEndingJourney on 12/10/2011 at 10:01 PM

My issue is the same as Francois Lepinay's, i.e. a document-level customisation. Has anyone more info in this respect?

Posted by Francois Lepinay on 10/7/2011 at 9:00 AM

I'm having the same problem with a Document level not an Add-In. Since I don't have any Registry Key I'm not sure how I can fix this. Thanks

Posted by Vladimir Wrmakov on 6/9/2011 at 10:34 AM

The fix works fine for my Add-In for outlook. Maybe due to latest updates to VSTO 4.0 after this discussion.
Once add prefix to Registry key in MSI Project, and then application installed on test enviroment, then Wcf service from Add-in immediately got config file.
Nice fix. Thanks.

Posted by frank.halder on 5/24/2011 at 9:56 AM

The described fix (prepending "file:///" to path) does not work on my system: The Addin fails to load.
I can reproduce the Addin working correct if I copy the Addin configuration file to C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.exe.config.

Posted by RobHarris on 4/5/2011 at 12:03 PM

Thanks. That did the trick. I believe the article you just linked was what I used to build the deploy project as well..

Posted by Microsoft on 4/5/2011 at 9:14 AM

You'll need to make the change in your deployment project, not in the .vsto or .manifest files. Specifically, you need to change the string written in the "Manifest" registry value. For example, the walkthrough in this article directs you to set the "Manifest" value to "[TARGETDIR]ExcelAddIn.vsto|vstolocal": http://msdn.microsoft.com/en-us/vsto/ff937654.aspx. To satisfy the new URI scheme requirement for Fast Path loading, you actually need to set the value to "file:///[TARGETDIR]ExcelAddIn.vsto|vstolocal".

Philo

Posted by RobHarris on 4/4/2011 at 7:57 PM

I'm not sure I follow. The vsto and manifest files are generated from builds. So the way to create a setup is to manually edit these files now? The blog post you cite just mentions the fast path feature but doesn't really get into any details. Is there some place I can make this change once or am I now stuck editing the file by hand for every build?

Posted by Microsoft on 4/4/2011 at 5:40 PM

Hi, thanks again for taking the time to provide feedback. The problem you're seeing is actually a known issue caused by a requirement introduced by the new Fast Path add-in loading functionality in the SP1 version of the VSTO Runtime (http://blogs.msdn.com/b/vsto/archive/2010/11/30/performance-improvements-coming-soon-to-a-service-pack-near-you-stephen-peters.aspx). When an add-in is loading via Fast Path and relying on a *.dll.config file, the manifest path provided for the add-in must be a complete, well-formed URI, including a URI scheme. For Fast Path add-ins, this means prepending "file:///" to the path to the locally-installed .vsto file. This new requirement is related to the refined security process for Fast Path loading, and helps ensure that only trusted files are loaded.

We’re aware that this new requirement was not communicated adequately before SP1 was released, and that it may cause existing add-ins to stop working when machines are upgraded to the SP1 Runtime. We’re working to update the documentation and provide guidance as soon as possible. Meanwhile, please try prepending prepend "file:///" to the manifest path and let us know if you have any further issues.

Thanks,
Philo
VSTO Dev

Posted by RobHarris on 4/1/2011 at 2:08 PM

Looks like others are having the issue too. This describes the issue exactly:
https://connect.microsoft.com/VisualStudio/feedback/details/655549/breaking-changes-for-vsto-outlook-addins-that-use-wcf-with-vsto-4-0-sp1-runtime#tabs

Posted by RobHarris on 4/1/2011 at 2:04 PM

I'm wondering if I'm better off opening a support ticket for the issue. I've been able to work around it for now by uninstalling VSTO sp1 and reinstalling the older version of VSTO on the client machine. This will work fine until something outside of my control updates the client machine to the newer VSTO and then I'll be back to it not working.

Posted by BikeMike on 4/1/2011 at 12:18 PM

We are running in to the same issue. I am using Visual Studio 2010 SP1 and Office 2010 (x86) with an Outlook add-in(Outlook 14.0.4734.1000) on Windows 2008. Running the add-in using Visual Studio appears to work fine in Debug mode. However, building an MSI, installing the MSI, then launching Outlook which in turn loads the add-in is not working when making a call to retrieve config values:

ConfigurationManager.AppSettings["myValue"]

However, moving the values down to applicationSettings, then using the following does work:

Properties.Settings.Default.myValue

Posted by RobHarris on 3/29/2011 at 1:43 PM

I created a console application.
Added a reference to a wcf service & added the endpoint information to the app.config file.
Confirmed it was working in debug mode in the VS IDE.
Added a setup deployment project & added the output of the console app project.
Built both.
Copied the setup.exe and msi files to another machine and installed.
Ran the console application with fiddler2 running and could see it making the call to the WCF service without an issue.

Just to be clear. The Outlook addin worked correctly until I installed VSTO 4.0 sp1 (and it still works correctly in debug mode on my development machine). Now it isn't checking the application install folder for the application.exe.config file.

Also, just as an experiment. On my x86 XP machine that I deploy to for testing, I uninstalled VSTO sp1 and reinstalled VSTO 4.0 (10.0.21022.1) and now that machine works again. We tested following the same steps on a Windows 7 machine and did not have any success.

Posted by Microsoft on 3/29/2011 at 11:38 AM

Rob,
I was not able to repro your issue at my end with Office 2007 outlook addin targeting .NET 4.0/3.5 trying to access a WCF service. Now that being said, it seems like this is a setup issue at your end, so unless we know how your setup is laying down the files on the client machine, it's hard to repro the issue and investigate it further.

What I would suggest is, in order to narrow down the issue please try one of the following:
So rather than outlook addin, can you create a simple console application trying to access the same WCF service when installed using your setup project?
This will be a step further in narrowing down the issue if this is related to VSTO addin or in general with WCF configuration.

Posted by RobHarris on 3/28/2011 at 9:50 AM

We are using Office 2007 x32 & Visual Studio 2010 sp1. My development machine is x64 but the addin runs on a x86 environment. The addin simply takes the selected email and does a lookup in our ERP based on the email address of the sender via a WCF service call. This was working correctly and reading the local config file until I installed VS 2010 sp1 which included VSTO 4.0 sp1. Afterwards, it stops looking for the config file in the install folder of the addin and as Jarle points out, if it doesn't find the endpoint information in the config file for Office, it throws an exception. It never gets to the point of actually calling the service because it isn't getting the endpoint information out of the config file.
I am using a setup project to deploy the addin (NOT clickonce publishing). Also, when running local in debug mode, it works correctly and reads the config file. It is only once it is deployed to another machine that it doesn't work. (That is critical to understand for reproducing the behavior)

Posted by Microsoft on 3/28/2011 at 3:27 AM

Hi,
Unfortunately, we are unable to reproduce the issue with the steps you provided.

Could you please provide us with the following information?

1) Office Version 2010( x86 or x64) or 2007
2) Os version and architecture (x86/x64)
3) Is office upgraded to Office 2010 SP1
4) Is there any custom code running prior to invoking the WCF service.

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thanks again for your efforts and we look forward to hearing from you.

Posted by Jarle Roti on 3/25/2011 at 4:49 AM

It looks like this version of VSTO does not read the AddIn config file. A sort of work-around is to copy <my addin>.dll.config file to C:\Program Files\Microsoft Office\Office14\ and rename it to Excel.exe.config. However, I guess this will lead to other problems and it also make it impossible for mulitple AddIns to have their separate config information. Also, this location is protected, so it is not possible to automatically edit or deploy the file there. My impression is that this is a serious bug and our application stops working from the very moment our install automatically download the latest VSOP package, which already has happend.

Posted by Microsoft on 3/25/2011 at 12:29 AM

Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.

Posted by Microsoft on 3/24/2011 at 4:14 PM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

Visual Studio SP1 (or specifically VSTO sp1) Issue with config file location by RobHarris