views:

2434

answers:

3

Ok, this is rather simple, but from what I've seen… you can only use some sort of Windows Workflow to include another config into another (which I refuse to do).

Here's the deal:

MAINAPP.EXE References an hypothetical LIBRARY.DLL.

MAINAPP.EXE has its own MAINAPP.EXE.config.

If you add "config values" to LIBRARY.DLL (thereby creating an app.config in LIBRARY.DLL project), those values are not available at runtime even if you copy app.config into LIBRARY.DLL.config to the right path post-build.

The reason for the above is that even referenced libraries will read from the "mainapp.exe" config.

So far "so good". Now, when you add a WCF Service reference, visual studio creates or populates your app.config with the bindings/endpoints/etc.; but that's added to the project where you added the reference's config; hence, your Library.DLL.prj ends up with a nice app.config that doesn't work because it never gets read, nor even copied to the output directory. Now you may think that you can right click that app.config and set "copy always" to true. Forget it. That doesn't do anything. (You can google for that one).

So, given the above weird scenario, how is a regular VS2008 developer working with a .NET 3.5 project going to manage the WCF service references he adds to his Business Layer dll? Is that developer supposed to COPY and PASTE all the whole section from the useless app.config in his DLL to the Mainapp.exe.config file each time there's a change in the services or each time he adds/removes one ?

I hope I'm wrong. Thanks.

A: 

No you're right.

But surely your WCF services are not in the business layer project, but instead in a separate project which acts as a facade into the business layer. Your business layer is then just another assembly as it should be and doesn't care how it's accessed, the WCF project does that for it.

Or of course you write custom service hosts and put the minimal amount of information in the config file (host name, certificate thumbprint) and do the rest in code.

blowdart
Oh no, my WCFs are not in the BL, the BL has methods and logic to connect to a WCF that is on a different server. I need the wcf references in BL.dll to be able to connect to those. I see no real benefit from creating a WCFFacade. Will have to copy the app.config anyway. Care to clarify #2. Thanks.
Martín Marconcini
+4  A: 

Yes. Copy and paste is the answer. It's not a great answer, but it's the answer, and it has been since day 1 in .NET 1.0 with AppSettings.

John Saunders
*sigh* thanks. I thought that with WCF, .NET 3.5, VS2008, year 2009, things may have "improved" a little bit.
Martín Marconcini
They did improve. There's more stuff to copy now. ;-) Seriously, how would we update the calling .config file based on changes in the source .config file? I think a human needs to do that. We'll want Oslo to help provide a solution for this: change scripts for config?
John Saunders
I think you're missing the point. The problem is not the updating of the config, but that the .DLL config is not read as it should. It's actually really retarded. It's a microsoft thing. It's OBVIOUS that you will want a DLL to hold its own config…
Martín Marconcini
How would you locate the config file of a DLL in GAC? Also remember that custom config sections become instances of a type. Where are the assemblies defining those config sections? At present the answer is "in .exe.config". With Oslo: "in the Repository".
John Saunders
You have a point, however, why adding a WCF Service reference to a DLL adds the info in the app.config for that DLL project? No indication whatsoever that the config will be plainly ignored by VS and the application… that stuff is what I mean. MS does stuff like that all the time and I hate that :)
Martín Marconcini
If you think Microsoft made a mistake with this, then please create a suggestion on http://connect.microsoft.com/visualstudio/. Then post the URL of the suggestion here so we can vote on it.
John Saunders
One thing you might suggest is that when they put the config in dll.config, that they add a comment saying it must be copied. That might be easy enough for them to get it into .NET 4.0.
John Saunders
Here's the URL: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=423440Thanks.
Martín Marconcini
If you don't need the App.exe.config you add the config file into the app as add existing item add as link. That works quite well.
RichardOD
Which config file? For a DLL that's going to be used with many different consuming applications, there's no single config file to link to.
John Saunders
+2  A: 

You can have a library project include custom config files and those files can be copied to the executable location of another application (it's a little sticky, but not too big a deal). You just have to use OpenMappedExeConfiguration to get to any information in those files. You'd then have to do some custom coding when you instantiate your WCF proxies (instantiate a Binding and pass that to the proxy). I'm late to the party here, but I can provide more details if you're interested.

sliderhouserules
Thanks for the response. It turns out Microsoft acknowledges that this is a "poorly documented" situation. I have already fixed the problem by manually copying the config relevant parts to the main config, all I was ranting about was that this is not "written" anywhere. Thanks anyway! (+1)
Martín Marconcini