library configuration file not copied to referenced project RRS feed

  • General discussion

  • I've got a solution with two projects; a class library and a windows app. The windows app project references the class library and has the Copy Local attribute set to True. Visual Studio/MSBuild is not recognizing that the class library has a configuration file and does not copy it over to the windows app's bin\debug folder causing the app to crash because the library needs to look up setting in the configuration file. 

    Does visual studio or msbuild have the ability to copy the configuration file without having to resort to post-build events?

    • Changed type Wesley Yao Tuesday, August 4, 2009 2:31 AM
    Monday, July 27, 2009 10:48 PM

All replies

  • Hello,

    I tried it but the .config file was copied, below steps are what I did:

    1. Create a C# console project and library project separately.
    2. Add reference to the library project in console project.
    3. In library project of the solution, click xxx.config file, change its "Copy to Output Directory" property to "Copy always".
    4. Build the solution, the xxx.config got copied to the output directory.

    Did I misunderstand your question?  Please feel free to let me know if it still cannot work.

    Please mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, July 29, 2009 4:04 AM
  • Change the status to "General Discussion"
    We are changing the issue type to "General Discussion" because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to “Question” by editing your initial post and click the button "Change Type" at the top of the post. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.

    Thank you!

    Please mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, August 4, 2009 2:30 AM
  • I don't think you understand the problem. I don't want the app.config file copied to the output directory of its own project. I want MyApp.exe.config file copied to the project referencing it. Visual Studio or msbuild has code somewhere to identify that a project has an application configuration file and during the compile process it makes a copy of that file as <OutputName>.<exe/dll>.config in the projects output directory.

    So given project A is a library project and contains an app.config file we wind up with the following after compilation which is what we expect:

    Project B is a windows app and has a file reference to A.dll. The problem is that A.dll.config does not get copied to project B's bin\Release directory as seen below. This will cause the application to crash because its configuration is missing.

    Again I need to know how to make this happen without post build events or using links. We use Team Foundation Build at a large company and we don't allow post build events during the builds and links are not a good work around because it will cause management nightmares for the hundreds of developers involved who all have references to each other's projects. The copying of a referenced assemblies configuration files should be automatic.

    Monday, August 10, 2009 10:15 PM
  • I too am experiencing this issue.
    My end project is a web service application, but strangely enough, it is not crashing. I am using the Settings class, which means the library is built with the default values. While this is fine for testing, it is not for release when i will need to modify the connection string, and perhaps other settings, to point to the production environment.
    Fortunately my project is small and i don't have the same issues as Joey regarding a large number of developers, however, i too would like the <library>.dll.config file copied to my end project's bin folder.
    Tuesday, October 13, 2009 10:12 PM
  • Any update to this?  I have the same question as Joey.

    Friday, June 18, 2010 9:08 PM
  • I do have an update to this.

    In Joey's example, file A.dll.config will never, and should not be, copied to B's output folder.

    What you need to do, is populate B's app.config with A's configuration. This is a manual process, but can mostly be achieved with copy/paste. Just be sure to add any configuration section definitions too.

    Then when you build B, it's app.config contains A's configuration.

    Another option is to create another file in B which is A.config. I have not tried this approach, but articles i've read indicates that .net apps will process ALL .config files in the executable directory. This means in project B, you have A.config and app.config. Both files should be essentially appended. I'm not sure what would happen if there are overlaps - again, i haven't tried this.

    Let me know how you go with this. I'd experiement, but I don't have much time to do so at the moment.

    Good luck!

    Wednesday, June 23, 2010 11:17 PM
  • My experience is a 15 library project with only 1 executable that uses all of them.

    I tried various ways but the only one that worked is to use a link, or to copy the cotnent of the A.dll.config to B.exe.config (app.config)

    I understood that during runtime, even if the assembly that searches for settings is in a dll, it is always used the app.config file of the executable.

    I didnt' succeed, as woodaeng says, to make all config file to be processed.


    Tuesday, September 14, 2010 9:23 AM
  • JoeyBB question is valid for some scenarios...


    In the case of libraries, the main assembly (the executable or service) will load its dependencies and then will load the settings of configurations as needed per library.

    If you would like to have separate configurations per library, the application config file should (again) reference those files as additions to the main assembly.

    Example to a web.config:

    <?xml version="1.0" encoding="utf-8" ?>
     <appSettings file="AdditionalAssemblyConfigFile.dll.config">
      <add key="KeyToOverride" value="Original" />
      <!--<add key="KeyToNotOverride" value="Standard" />-->
      <!-- standard web settings go here -->


    Now, I do want to know what happen if I want that library.config file copied to the output of the project making reference of.


    In my case I have two WPF apps... The first one (let's call it A) will eventually execute in a separate process the second app (Let's call it B)... So if I reference them in my project I would get as output:


    It could be even useful (although I don't think it could be beneficial, most of the times we need custom settings for different assemblies) to apply it to the libraries projects as well so I would just make reference to the library.dll.config file instead of copying and pasting settings from one place to the other...

    Rodrigo Landaeta
    Friday, April 15, 2011 1:38 AM
  • @JoeyBB

    I want the same thing as you.

    I want to share my case:-



    In my case i have two connection strings in A's app.config automatically added by Visual Studio.
    The A\bin\Release\A.dll.config contains the same 2 connection strings.

    But when the A.dll and A.dll.config are copied to B\bin\Release\ folder the A.dll.config is empty. But i was able to connect ot the database. I found out that the app.config of the A.dll was embedded into the A.dll itself rather than being as a separate file.

    Ultimately in my B'a folder there is B.exe, A.dll,  there is A.dll.config(empty)
    but i am still able to connect to databse, nowhere my connection strings can be seen.

    I even took this folder B\bin\Release to another PC still it worked fine, nowhere were those two connection strings, as i said A.dll.config was empty.

    I used procexp.exe to see A.dll's strings at runtime i found out that A.dll has loaded the connection strings , dont know from where. So i believe A's config file is being embedded to the A.dll iteself. see my post

    Vibhor Agarwal
    Wednesday, April 27, 2011 1:26 PM
  • I was facing the same problem, like you mentioned.

    The easiest solution to this was to rename the App.config file for the dll project to the dll filename and add .config at the end of the file name. Change the property for the file in "Copy to Output Directory" to "Copy always".

    This will copy the config file to the output directory of the project which references your library and use the settings which are defined in it automatically.

    For e.g.

    If your DLL Library projects output is named "My.Library.dll" then just rename the App.config file for this library to "My.Library.dll.config" and set the appropriate property for this file to to "Copy Always".

    I hope this will help you.

    Tuesday, May 24, 2011 10:28 AM
  • @joey

    acc to your orignal question the dll config file is copied by the visual studio to the windows app's directory.

    In my case the config file contains two connection string entries. Vis Studio copies an empty config file but it is an empty config file. Still the window app exe works fine and connects to the database.

    Vibhor Agarwal
    Tuesday, May 24, 2011 4:32 PM
  • I've run into the exact same problem with a library project where the configuration file accompanying my dll file was not copied to the webproject that references the dll file. To resolve this issue, I added a post-build command (open the project properties and select the build tab) with the following code

    copy "$(TargetPath).config" "$(SolutionDir)\YOUR-PROJECT-FOLDER\bin\$(TargetFileName).config"

    Depending on the type of project (eg. Website, Windows Forms) you might need to change the command slightly but I'm sure you get the general idea.

    Elmar de Groot

    Imagination is more important than knowledge
    Thursday, January 12, 2012 12:26 PM
  • In order to Deploy the config file automatically.

    You can use DeploymentItem attribure on your class or one of your methods which needs it.



    Monday, January 30, 2012 5:07 PM
  • Hello,

    I second that question, in the component based development and unit tests all everywhere around, it is a nightmare to get the configuration file ready and correct for the test OR for hosted COM component in different AppDomain.

    Seems to me there isn't a simple way to set up the project file from the VS2010 UI, so that it copies the .dll.config along with the .dll accross into all the projects referencing the library. However, with a little dig in the .targets file and a bit of tricking it is somehow achievable:

    Insert the following fragment into the .csproj directly after the import statement of  the language specific targets:

        <Content Include="app.config"> 

    The construct above keeps the project reference mechanism up to date and joins the process of resolving outputs from referenced projects.



    Tuesday, July 24, 2012 6:11 PM
  • I prefer the post build step myself.  I usually put it in the referencing project (pull), like this:

    copy "$(SolutionDir)<DLLPROJECTNAME>\$(OutDir)\<DLLPROJECTNAME>.dll.config" "$(ProjectDir)$(OutDir)"

    Then I set the dll project app.config to "CopyAlways".

    While renaming the file to "<DLLPROJECTNAME>.dll.config", and setting it to "CopyAlways" will make it move over to your other project...  It wreaks havoc with your Property Settings tooling and Entity Framework data models, if you update them.

    • Edited by bigtlb Thursday, August 23, 2012 1:30 AM Fixed code fragment formatting
    Thursday, August 23, 2012 1:26 AM
  • Works a treat - Thx Pavel;

    david tuke

    Wednesday, November 25, 2015 12:23 PM
  • <ItemGroup>
      <Content Include="app.config">

    Monday, February 8, 2016 3:32 PM
  • That solution works for me.  

    Thank you

    Thursday, May 16, 2019 11:51 PM
  • This is the first solution came out from my mind.  However, it doesn't work for me.  In my case, the builder first save the output in a dynamic temp folder, thus, the actually final destination location of B ($(ProjectDir)$(OutDir)) is not available until B compiling is done.   
    Friday, May 17, 2019 12:00 AM