1

By common DLL I mean that on the file system of the server running the two that there is only one DLL shared by the service and the site.

The goal is that the DLL will have it's own App.config file so that when the service hits the DLL and asks for settings in the config, and when the website hits the DLL asking for the same settings, that those settings will always match each other.

I imagine that if the service uses a different copy of the same DLL with a different copy of the App.config, then the service's DLL's config may not match the website's DLL's config. I'm trying to ensure integrity by only having one set of the DLL and it's config on the server.

Is this a feasible goal?

I know I have to write up specific code in the DLL to ensure that it won't read either Web.config but that doesn't seem too bad. Are there other concerns I'm not thinking of?

Corey Ogburn
  • 24,072
  • 31
  • 113
  • 188
  • Well, sharing a DLL on a file system can be as simple as registering in the GAC. I've had that before where I needed applications that had older libraries needing to reference an older version of a DLL that I required (more specifically log4net). However, when you reference a DLL, as far as I know, it references the *.config of the application that is requiring it – Ricky Hartmann Dec 10 '14 at 21:36
  • I'm thinking I can use `ExeConfigurationFileMap` mixed with `Assembly.GetExecutingAssembly().Location` to get the config that's in the same folder and has the same name as the DLL. – Corey Ogburn Dec 10 '14 at 21:37
  • What about just setting the *.config to a specified location for each app. http://blogs.msdn.com/b/suzcook/archive/2003/06/02/57160.aspx AppDomainSetup.ConfigurationFile seems like a way to do that. I'd probably have both apps reference a database for the file location, this way you can have it dynamically reference the file path – Ricky Hartmann Dec 10 '14 at 21:41
  • That may be an approach I take when I put this together, but it sounds like you're saying this seems entirely possible. – Corey Ogburn Dec 10 '14 at 22:12
  • 1
    DLL's don't use their own config files. They use the config file of the application using them (app.config or web.config). I'm not sure what problem you're trying to solve here. – Tim Dec 10 '14 at 22:27
  • @Tim, I'm planning to write up one Core DLL to be used as a service. It will have two endpoints: a WCF service and a REST service that will basically expose functionality of the Core DLL. Due to company policy and change management, database changes can take up to a week to happen. Instead, I want to put a key config setting in a config file for the DLL so at most it takes a couple hours to a day to change. There will be problems if the WCF service reports this setting differently than the REST service. A DLL can have a config, it just isn't the norm. – Corey Ogburn Dec 10 '14 at 22:30
  • In _one_ ASP.Net application? ASP.net WCF and REST/Web API, etc. then it's one _config file_ for _that application_ (as mentioned above). You can segment with `section`. Or are they "nested applications" (e.g. application folder) at which point they can have their own config file (just note inheritance).? – EdSF Dec 10 '14 at 22:35
  • @EdSF, I don't know, this isn't an undertaking I've ever tried before. – Corey Ogburn Dec 10 '14 at 22:37
  • [This post](http://stackoverflow.com/a/23509786/304683) should hopefully give guidance/idea(s). Hth... – EdSF Dec 10 '14 at 23:20
  • 1
    @CoreyOgburn - If you have a single DLL that encapsulates your service, you should be able to expose SOAP and REST endpoints via the proper config file, without having to do a bunch of hoop jumping. What setting are you expecting needs to be changed? Is it part of the ``, `` or something else? – Tim Dec 11 '14 at 00:03

1 Answers1

0

First of all, why share the same physical assembly? There is no benefit whatsoever, and quite a few drawbacks. Even if the assembly contains generic functions which are non-application specific, each application should reference it's own local instance of the assembly.

Secondly, no it's not feasible to set up DLL config sharing at runtime (except by abusing the machine.config). Even if you GAC the assembly for sharing (recommended if you absolutely must share it), the assembly still executes under the context of the app domain which loads it, and each app domain has it's own config.

The ideal way would be package the assembly as a NuGet package and then you can easily manage the shared config requirement by including a configuration template as part of the package.

Community
  • 1
  • 1
tom redfern
  • 30,562
  • 14
  • 91
  • 126