Link to home
Start Free TrialLog in
Avatar of edenmachine
edenmachine

asked on

How to use Dataset.xsd files in a WebService project with a machine.config

I can't seem to figure out how to use Dataset.xsd files in a WebService project with a machine.config.  When I create an XSD file, the connection string from the machine.config doesn't show up in my list of connection strings.  This works fine in a normal Website project.
Avatar of edenmachine
edenmachine

ASKER

Actually, I just proved that it has nothing to do with the WebService aspect of it.  I have the same problem with a normal Website Project also.  So I guess my question has changed to "Why do Dataset.xsd files not allow access to the Machine.config?"
Avatar of Bob Learned
Why are you modifying Machine.config, and not Web.config?
Well, I'm putting the connection string in the machine.config so that whatever environment I have my application in (dev, QA or prod) it's pointed to the correct database - otherwise I'd have to constantly change the connection string in the web config when I move it up to a different environment.  Isn't this the norm to keep environment specific variables in the machine.config instead of the web.config?
No, it is not a normal practice to be modifying the machine.config.  It is very confusing to others who have to come and maintain the application, because they won't normally look in the machine.config for a connection string.
Once you come up with a web.config file, don't overwrite it in the different environments.  I know this is a pain, but it is the preferred method.
What about the Global Assembly Cache (GAC)?
What about Global Assembly Cache?  That is for global access of assemblies, not config files.
Also, it would be pretty easy to make a small comment in the Web.Config saying <!--- "MyAppConnectionString" is maintained in the Machine.config -->  this would completely eliminate any confusion for future developers as well as solve the "pain" of having to not move configs from enviroment to environment (because there are many times that I actually NEED to add things to the config and copy the changes to all environments though).
"What about Global Assembly Cache?  That is for global access of assemblies, not config files."

Yes, but I was asking in terms of standards and keeping connections to databases (through DLLs) and keeping them machine-specific.  Just looking to keep things standards-based but at the same time, keep it from being a huge pain (like with the Web.config)
ASKER CERTIFIED SOLUTION
Avatar of Bob Learned
Bob Learned
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
crap - well, I did a little digging and I was referring to machine.config incorrectly.  I'm actually referring to the Web.config that's in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG directory which is also accessed in top level website of IIS:
 http://by1.storage.msn.com/y1pUcumf6TmNjSSjNx69qE64wg4OJ8D87oOBWAquGPckYbD5NF00vGlDeY0QhXogqLjlau_5Zd8mr1AFXGX5ajiC_IURIuj7XuT  

Does that make a difference at all?
I don't believe that it makes any difference at all, and I don't think that I can help you get the machine.config working as you desire.