ASP.Net website structure - TableAdapters and a Class Library

[Guest]

Hi there.

First of all let me apologise for this is a somewhat general question to
which I would be interested in any opinions.

As far as I can see when I create a web application the recommended location
for the database is the app_data folder. The recommended location for code
files and datasets/table adapters appears to be the app_code folder. This set
up appears to work reasonably well although it results in the all the code
files being published with the web application.

A better solution appears to be to create a separate Class Library with a
reference to that Library from the web applications. After a build the dll is
copied into the bin folder and any of the code can be accessed just fine.
With this set up I only then need to publish the dll in the bin folder which
seems a better option.

With the second option everything is fine just so long as I use SQL Server
as the location of the database is not critical to the connection string.
However if I want to use an Access Database (well I don’t want to but
sometimes this is the only option) the access database is located in the
app_data folder which isn’t naturally accessible from the Class Library. If I
create a dataset with table adapters within the class library when I compile
the project the connection string appears to be wrong as the dll copied to
the web application doesn’t look for the string details in the web.config.
Previously it was using the connection string from the application settings.

The conclusion I have drawn is that using table adapters in an external
Class Library to create a data layer doesn’t work so well with an Access
database.

Is this correct or am I missing something?

Any good articles covering the above would be of interest.

 

[Steven Cheng[MSFT]]

Hello Martyn,

From your description, the problem you met here is the
TypedDataSet/TableAdapter(defined in a separate class library project)
which connect to an Access mdb file will not quite work when referenced in
ASP.NET web application since the TableAdapter will still refer to the
original database connectionstring(file path) to mdb file used at
design-time, correct?

I think what you do here is correct and it is certainly reasonable to
separate the TypedDataSet/TableAdapter(or other custom data access/business
component) into separate class library when we want to provide good
encapsulation and isolation of differnt Tier in our application. The reason
why the TableAdapter will reference the connectionstring(file path) at
design-time is because VS IDE will help generate a setting class which
contains a dictionary of data, and the TableAdapter's connectionstring is
also stored in it. However, this value is overridable if we use the class
library in other upstream application layer(in asp.net or winform
application), this can be done through override the connectionString in the
upstream application's application config file(web.config for asp.net
application). Actually, in the class library project, you will find an
"app.config" file also, and it will contains the connectionstring entry for
the TableAdapter, e.g.

===================
<add name="URLSiteLib.Properties.Settings.AccessDBConnectionString"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\temp\database_temp\aspdb.mdb"
providerName="System.Data.OleDb" />
===================

this is the one you set when creating the DataSet/Tableadapter, and this
value is also referenced by the Settings class generated by VS.NET, you can
find the following code in the "settings.designer.cs" file:

===============
[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]

[global::System.Configuration.SpecialSettingAttribute(global::System.Configu
ration.SpecialSetting.ConnectionString)]

[global::System.Configuration.DefaultSettingValueAttribute("Provider=Microso
ft.Jet.OLEDB.4.0;Data Source=D:\\temp\\database_temp\\aspdb.mdb")]
public string AccessDBConnectionString {
get {
return ((string)(this["AccessDBConnectionString"]));
}
}
==============================

So it actually will read the value from app.config file first, and if not
exists, use the default value(set by the
DefaultSettingValueAttribute(....)).

thus, when you reference the class library and use the TableAdaper in a
upstream application(asp.net or winform or console) and want to modify the
connectionstring used by the TableAdapter, you should override the above
connectionstring setting in the application's configuration file. For
example, the following fragment override the connectionstring (refer to the
mdb file in App_Data dir) in the ASP.NET application's web.config file:

============================
<add name="URLSiteLib.Properties.Settings.AccessDBConnectionString"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=|DataDirectory|aspdb.mdb"
providerName="System.Data.OleDb" />
==============================

Hope this helps clarify it a little. If you have anything unclear or any
further question this on this, please feel free to let me know.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

You’re absolutely spot on Steven.

I will try over riding the connection string as you explain.

Thanks for your reply.


--
Regards

Martyn Fewtrell

Hello Martyn,

From your description, the problem you met here is the
TypedDataSet/TableAdapter(defined in a separate class library project)
which connect to an Access mdb file will not quite work when referenced in
ASP.NET web application since the TableAdapter will still refer to the
original database connectionstring(file path) to mdb file used at
design-time, correct?

I think what you do here is correct and it is certainly reasonable to
separate the TypedDataSet/TableAdapter(or other custom data access/business
component) into separate class library when we want to provide good
encapsulation and isolation of differnt Tier in our application. The reason
why the TableAdapter will reference the connectionstring(file path) at
design-time is because VS IDE will help generate a setting class which
contains a dictionary of data, and the TableAdapter's connectionstring is
also stored in it. However, this value is overridable if we use the class
library in other upstream application layer(in asp.net or winform
application), this can be done through override the connectionString in the
upstream application's application config file(web.config for asp.net
application). Actually, in the class library project, you will find an
"app.config" file also, and it will contains the connectionstring entry for
the TableAdapter, e.g.

===================
<add name="URLSiteLib.Properties.Settings.AccessDBConnectionString"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\temp\database_temp\aspdb.mdb"
providerName="System.Data.OleDb" />
===================

this is the one you set when creating the DataSet/Tableadapter, and this
value is also referenced by the Settings class generated by VS.NET, you can
find the following code in the "settings.designer.cs" file:

===============
[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]

[global::System.Configuration.SpecialSettingAttribute(global::System.Configu
ration.SpecialSetting.ConnectionString)]

[global::System.Configuration.DefaultSettingValueAttribute("Provider=Microso
ft.Jet.OLEDB.4.0;Data Source=D:\\temp\\database_temp\\aspdb.mdb")]
public string AccessDBConnectionString {
get {
return ((string)(this["AccessDBConnectionString"]));
}
}
==============================

So it actually will read the value from app.config file first, and if not
exists, use the default value(set by the
DefaultSettingValueAttribute(....)).

thus, when you reference the class library and use the TableAdaper in a
upstream application(asp.net or winform or console) and want to modify the
connectionstring used by the TableAdapter, you should override the above
connectionstring setting in the application's configuration file. For
example, the following fragment override the connectionstring (refer to the
mdb file in App_Data dir) in the ASP.NET application's web.config file:

============================
<add name="URLSiteLib.Properties.Settings.AccessDBConnectionString"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=|DataDirectory|aspdb.mdb"
providerName="System.Data.OleDb" />
==============================

Hope this helps clarify it a little. If you have anything unclear or any
further question this on this, please feel free to let me know.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Thanks for the reply Martyn,

Glad that the information is of assistance. If you have any further
questions or anything unclear, please feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.