By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,086 Members | 1,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,086 IT Pros & Developers. It's quick & easy.

Deployment nightmares with app.config

P: n/a
Let's say you have a stand alone C# library project that is your
datalayer. When this library compiles it will produce
"My.DataLayer.dll" for example.

In the project you use all the new whizbang DataSet generation tools to
create some datasets, etc in your DataLayer project. When you setup a
connection string it adds a settings.settings file and na app.config to
the project which holds the connection string. Essentially the
settings.settings is a front-end to the app.config file.

Now, you compile your project and everything works, except the
app.config file is embedded into your DLL. This means you cannot take
the DLL and copy it to production or beta without first changing the
settings and regenerating the app.config and recompiling.

I read somewhere a long time ago that you can rename the app.config file
to the My.DataLayer.dll.config for example but it doesn't appear to
pickup the settings in the new config file, they are STILL embedded
within the DLL (even though the file is set to not copy and not embed).

Anyone know of a way around this?

-Keith
Jan 19 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
How did you compile the app.config into your DLL? I always get two files,
MyAssembly.Exe and MyAssembley.Exe.Config.

I never have an app.config for my DLL, as they should be dumb to
environmental variables.

I would suggest that the consumer of your DLL will tell your DLL what the
connection string is. You can do it in a number of ways, Singleton
Instance, pass in the values on class init, pass in the values on each call,
and more.
"Keith Elder" <ke***@removethis.dotnetpimps.net> wrote in message
news:tP********************@comcast.com...
Let's say you have a stand alone C# library project that is your
datalayer. When this library compiles it will produce "My.DataLayer.dll"
for example.

In the project you use all the new whizbang DataSet generation tools to
create some datasets, etc in your DataLayer project. When you setup a
connection string it adds a settings.settings file and na app.config to
the project which holds the connection string. Essentially the
settings.settings is a front-end to the app.config file.

Now, you compile your project and everything works, except the app.config
file is embedded into your DLL. This means you cannot take the DLL and
copy it to production or beta without first changing the settings and
regenerating the app.config and recompiling.

I read somewhere a long time ago that you can rename the app.config file
to the My.DataLayer.dll.config for example but it doesn't appear to pickup
the settings in the new config file, they are STILL embedded within the
DLL (even though the file is set to not copy and not embed).

Anyone know of a way around this?

-Keith

Jan 19 '06 #2

P: n/a
Looking at this further, the app.config isn't in the DLL, but the
settings.designer.cs file IS. That is where it gets the connection
string from. I completely agree that the DLL should be dumb to
environment variables. However, it doesn't seem this is the case of how
things are done.

For example, if you go to "Data->Add new data source" in a DLL and
create a strong typed Dataset. It adds the settings.settings and
app.config automatically to your project.

If you compile the project, and go into the Debug folder, you'll see:

Project.dll
Project.dll.config

However, if you open up the dll in a plain text editor and search for
your database name, you'll find it in the DLL.

So, if you call the TableAdapter on your dataset, it uses the connection
string in the settings.designer.cs file. You can easily step threw it
and see this is what is happening.

AMDRIT wrote:
How did you compile the app.config into your DLL? I always get two files,
MyAssembly.Exe and MyAssembley.Exe.Config.

I never have an app.config for my DLL, as they should be dumb to
environmental variables.

I would suggest that the consumer of your DLL will tell your DLL what the
connection string is. You can do it in a number of ways, Singleton
Instance, pass in the values on class init, pass in the values on each call,
and more.
"Keith Elder" <ke***@removethis.dotnetpimps.net> wrote in message
news:tP********************@comcast.com...
Let's say you have a stand alone C# library project that is your
datalayer. When this library compiles it will produce "My.DataLayer.dll"
for example.

In the project you use all the new whizbang DataSet generation tools to
create some datasets, etc in your DataLayer project. When you setup a
connection string it adds a settings.settings file and na app.config to
the project which holds the connection string. Essentially the
settings.settings is a front-end to the app.config file.

Now, you compile your project and everything works, except the app.config
file is embedded into your DLL. This means you cannot take the DLL and
copy it to production or beta without first changing the settings and
regenerating the app.config and recompiling.

I read somewhere a long time ago that you can rename the app.config file
to the My.DataLayer.dll.config for example but it doesn't appear to pickup
the settings in the new config file, they are STILL embedded within the
DLL (even though the file is set to not copy and not embed).

Anyone know of a way around this?

-Keith


Jan 19 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.