Home Dashboard Directory Help
Search

ConfigurationManager.OpenExeConfiguration Misbehaves on some platforms by brucef


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


10
0
Sign in
to vote
Type: Bug
ID: 290821
Opened: 8/3/2007 8:22:01 AM
Access Restriction: Public
Duplicates: 331365
5
Workaround(s)
view
18
User(s) can reproduce this bug

Description

Two problems:

1. Adding a Manifest file using mt.exe causes Windows 2003 to try to open the wrong config file (myprog.config instead of myprog.exe.config).

2. Windows Home Server always tries to open the wrong config file (myprog.config instead of myprog.exe.config)

See:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1948877&SiteID=1&mode=1
Details
Sign in to post a comment.
Posted by JerGC on 7/18/2008 at 10:47 AM
This problem started happening for us when adding the Vista manifest via MT.exe.
We've used both VS 2005 and 2008 with the same results.
I will attempt to use an external manifest file to see if the problem persists.
Posted by Hauk on 4/11/2008 at 8:12 PM
I also have a problem with this. I upgraded my VC++ 2005 project to Visual Studio 2008 and I can run it fine on my development machine but on a Windows 2003 server (R2 std) it looks for the <app>.config file instead of <app>.exe.config file. I've verified this with Process Monitor (from former SysInternals). If I rename my config file then my project works because it can then find the config file.
Facts:
- Visual C++ 2008 project that calls a managed assembly over COM that communicates to our architecture framework. This managed COM component is the one opening the <app>.exe.config file using GetSection/GetConfig.
- Manifest embedded
- VC++ runtime (CRT) in private folder (not using vcredist)
- Windows service, tested under different user accounts

What I found out is that if the manifest is not embedded (ie the <app>.exe.manifest is deployed) then it works. I also found that if I install the vcredist for CRT 9.0 then it works, so it only seems to happen when using private folders for the CRT components.

/Hakan
Posted by heikosch on 10/3/2007 at 9:15 AM
Forgot to mention that this problem doesn´t occur in our mixed mode applications that are writte in C++ CLI and probably start as normal native apps before the .NET runtime is started.
Posted by Microsoft on 8/6/2007 at 12:45 AM
Thanks for your feedback, we were unable to repro the bug with the steps provided on Visual Studio 2005 SP1. If you still see this issue occurring we would like to investigate this issue again. Please provide the exact steps/actions to reproduce the problem or a zipped project file and we will re-investigate.

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 8/5/2007 at 5:00 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com).

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by ScottRebel on 8/20/2010 at 2:44 AM
andrejj, I think you're correct.
http://blogs.msdn.com/b/junfeng/archive/2006/08/09/692996.aspx suggests the same workaround
Posted by Andrej_at_work_live on 6/4/2009 at 12:18 AM
I think not all workarounds would help e.g. with EnterpriseLibrary Logging, another issue is that a separate (UAC) manifest file will not always work outside of standard windows folders.
The workaround I using now is to add the assemblyIdentity node to the manifest. This gives me magically a consistent behavior under XP/2003/Vista/2008/Win7 and NET20SP1/NET20SP2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
     <assemblyIdentity
             name="MyCompony.myprog"
             version="1.0.0.1234"
             processorArchitecture="x86"
             type="win32"
             />


     <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
     <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
     </ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
Posted by JerGC on 7/18/2008 at 11:26 AM
If you are using VS 2008 there is an new option under the project settings (Application tab) called Manifest.
It allows you to "Embed manifest with default settings", "Create application without a manifest", or select a specific manifest file. If you let VS do the manifest via project settings rather than using MT.exe in a post build step it works.
Posted by Hauk on 4/11/2008 at 8:13 PM
Link the project without embedding the manifest (setting under Project Settings) and deploy the manifest as a separate file.

Also installing the VCRedist installation is a workaround.
Posted by brucef on 8/3/2007 at 8:23 AM
Explicitly open the executable file with

ConfigurationManager.OpenExeConfiguration(system.windows.forms.application.ApplicationExecutablePath)