471,325 Members | 1,643 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

Deployment nightmares with app.config

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
3 9120
Remove the config file and place it in an accessible project

"Keith Elder" <ke***@removethis.dotnetpimps.net> wrote in message
news:Uo******************************@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
That defeats the purpose of deploying a stand alone DLL though. It
should rely on some other file in another project. Plus doing that
removes the connection string from the designer.

threetoes wrote:
Remove the config file and place it in an accessible project

"Keith Elder" <ke***@removethis.dotnetpimps.net> wrote in message
news:Uo******************************@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
Hi,

A config file exist only for an executable, a DLL has no config associated.
You have a couple of options though ( I listed them in a decreasing
priority list)

1- Create an Init method for the dll
2- Create a config file only for the dll and place it in the same folder
than the dll, you can read it later and interprete the config options.
3- Create a config section in the .exe config file, the dll can read its
values from there. and they do not interfere with other dlls/ the exe
settings.
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Keith Elder" <ke***@removethis.dotnetpimps.net> wrote in message
news:Uo******************************@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 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Eric Cadwell | last post: by
2 posts views Thread by Robert May | last post: by
2 posts views Thread by Keith Elder | last post: by
2 posts views Thread by Oleg.Ogurok | last post: by
3 posts views Thread by =?Utf-8?B?RHVrZSAoQU4yNDcp?= | last post: by
3 posts views Thread by shapper | last post: by
5 posts views Thread by tshad | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.