dynamic web reference appears to be worthless

[blekros]

Group,

Back in VS 2003 .NET 1.1 days, I used to create a special dll xml
configuration file to hold my web reference URL and load it from
there.

After loading VS2005 .NET 2.0, lo, there it is a dynamic web reference
that puts itself in its own <dllname.dll>.config file.

Does this mean that I can do the obvious, set the URL in the
<dllname>config file and during deployment?

No, apparently it doesn't.

After a day of twiddling with serialization assemblies on/off, debug,
optimize settings, build after flippin' build, there is no way on
god's green earth that <dllname.dll>.config is ever loaded and the web
reference url generated from that file. I might as well delete this
file or remove it from the deployment content because again, and I
cannot stress this enough, DOES NOT APPEAR TO EVER BE OPENED AND READ
WHEN THE DLL IS LOADED.

Solution? Go to the microsoft forums and find out, well, yes, Brad,
recreate your homegrown dll configuration scenario and SET THE URL
PROPERTY IN THE CLASS LIBRARY that wraps the web service EVEN THOUGH
the dynamic web reference property is set. Gee, why didn't *I* think
of that BEFORE my project was due.

Ok, steam vented.

MS Experts, what is going on?

Walk me through this from the bottom to the top. A dll exists. An
application, in this case, a compiled class on an ASP.NET website has
a reference to this DLL.

Start from the class loader when my class with the web reference and
its dll are loaded into the framework. What is happening? If there
is a serialization DLL, what is happening? If there is a
<dllname.dll>.config, when is it EVER read? When is it ever NOT
read? The 404 message refers to a reference.cs. No reference.cs has
ever seen the light of day in solution view, class view, any view in
VS2005.

Sorry for the whining tone, but imagine my surprise when I deployed a
project (on-site, travel expenses included) only to have it go all 404
when the 3 tiers were actually split onto three separate machines.
Gee Wally, then the big kids got all mad that their project had to be
pushed out until the following week, causing the CIO to get fired,
their stock to plummet and 10,000 people laid off, and me to get
kicked off the team.

Thanks,

Brad

 

[blekros]

Walk me through this from the bottom to the top. A dll exists. An
application, in this case, a compiled class on an ASP.NET website has
a reference to this DLL.

Start from the class loader when my class with the web reference and
its dll are loaded into the framework. What is happening? If there
is a serialization DLL, what is happening? If there is a
<dllname.dll>.config, when is it EVER read? When is it ever NOT
read? The 404 message refers to a reference.cs. No reference.cs has
ever seen the light of day in solution view, class view, any view in
VS2005.

Further digging has revealed that there is indeed a strongly typed
class in the dll that contains the web reference.
mynamespace.Properties.settings This contains a static method to get
the default settings object and an instance method to look it up from
the indexer.

Great, so my new plan was to query the settings class, get the
property for the web service end point, and set the URL property in
the web service proxy reference. Trouble is, the value that comes
back from the settings class is *still* the default value from compile
time, not the value in the <dlllname.dll.config> . Will this file
never load?

Turns out the settings base class has a Reload() method, so I tried
that. No luck. The question now is: how do I hydrate the strongly
typed class from the <dllname.dll.config> file? What object has a
load method for a dll config file? Stay tuned as we dig further into
the ConfigurationManager nightmare.

Brad

 

[Marc Gravell]

In general, the only config file worth much is "your.exe.config". As
far as your app is concerned you haven't provided any configuration
info for your web service, so it is defaulting to the initial setup.
You need to move the dll config entries into the app.config (create
one if necessary).

| don't know how much of your rant is the verbatim truth, but a little
bit of testing and demo preparation might have saved you some pain
here.

But more importantly, while I accept that you are frustrated by
events, your original post was simply so abbrasive that I suspect
people ignored it on principal; your follow up was much more
reasonable...
Akin to Eric Libbert's recent blog:
http://blogs.msdn.com/ericlippert/archive/2008/02/20/how-to-not-get-a-question-answered.aspx

Marc