Where should I put my connectionString in ASP.Net 3.5? - asp.net-3.5

I have two projects:
ASP.Net 3.5 website (frontend, UI)
VB Class Library (dataaccess logic)
Where should I save my connectionString, so that I can use if from the class library? And how does this affect where it is placed when I deploy/publish?
Note:
I don't want to pass it to every function in my VB Class

Depending on how you constructed your DAL -- LINQ, TableAdapters, etc. -- it may automatically look for it in the web.config file. If you created the DAL via a designer, likely it stores the default connection string in the app.config file for you class library. I copy the connection strings section from the app.config file to my web.config and change the connection string to the correct database (I have separate web.config's for DEV/QA/PROD). This makes it trivial since the designer generated code already has the code implemented to retrieve it from the configuration file.
If you are hand-coding your DAL and need to pass in the connection string, I suggest setting up a strongly-typed configuration class that interfaces to the web.config and does lazy loading of your configuration values. Use a factory to create your DAL and inject the configuration class into your factory via constructor so that it knows how to create your DAL with the connectionsString retrieved from the configuration file.

My question came from having spent half a day of trying to make this work, but I kept getting the wrong connection when deploying (where I use another database).
My problem was, that I was using
My.Settings.DefaultConnectionString
...To retrieve the connectionString in my VB Class Library.
After following tvanfossons anwer, I dug around some more and found out, that I can simply use (after referencing system.configuration) :
System.Configuration.ConfigurationManager.ConnectionStrings.Item("DefaultConnectionString").ConnectionString
It looks in the web-config for webapplications and app.config for windows/class library apps.
I am glad it now works, but even more glad I know why. ;)

I had the same issue you were having and I ended up using the System.Configuration.ConfigurationManager class to obtain the connection string stored in my web.config file from my class library like Kjensen's answer suggested. This worked wonders, if I had more experience I would vote that answer up.
I needed the connection string to build my Linq2Sql data context, which this method provided me with.
I now build my data context like below (remembering to add a reference to System.Configuration) -
public MyDataContext() : base(System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"]
.ConnectionString, mappingSource)
And as long as the web.config file contains "MyConnectionString" the configuration manager takes care of the rest.

We keep ours in the machine.config of each server and have a custom DAL to handle all DB interaction for our web apps.

Put it in the web.config in the connection strings section.
In the VB project use HttpContext.Current.GetSection to retrieve the section.

A fellow developers idea once was that we should store all the connection strings in a database table.
Don't try doing that. You won't get very far. :)

Related

NsPerstentContainer name in Appdelegate conventions in Core Data setup

I'm programming my fist SwiftApp got stuck setting up Core data. Since I'm integrating it into existing code I can't have Xcode set it up on Prohect init anymore. Furthermore I als want to understand what the lines of code actually do. Since all Core libraries are secret I am stuck with Apple's Docs which are not very clear on the matter.
Pfew... with that out of the way here is the question; What is the significance of the name passed to...
let container = NSPersistentContainer(name: "Core_Data")
...in the App Delegate file. I had set it up before but during compilation Xcode complained that it could not find the specified Name's module. Changing it to my project's name, the core data file I had created or the name of the Database passed to the menu when adding a Core Data file did not seem to help at all. Searching the web and a few tutorials people just fly over it and it is still very much unclear to me.
Any help would be much appreciated!
The string passed there is used for two things. If you were to pass the string Foo, Core Data would attempt:
To find the data model by looking for Foo.xcdatamodel or Foo.xcdatamodeld.
To find (or create) the persistent store, using the name Foo.sqlite.
Even an incorrect string value (i.e. one that doesn't match the name of your data model) should not cause a compilation error. It might cause an error at run time if iOS can't find the named data model.

Entity Framework Connection strings issue

im developing a class library (dll) with visual studio 2012, this library contains a model first created database, with the connection string setted on its app.config file.
Now, im creating a console app (actually a test, but for this its pretty much the same) with an added reference to the dll project.
At first i thought the console app didnt need to know anything about the database, since it was using the dll, however i got a connection string missing error. Fine i added it and it worked, but this isn't what i want, i need the dll to encapsulate all the database related stuff.
Also, what bothers me the most, is that the connection string is also needed on BOTH the dll and the app, even the .mdf file(im using local sql server) generated in the dll/bin/debug folder is needed and copied over to the app/bin/debug folder so i need the file to be on both sides...
How can i make the dll to work by itself, using its own config file and not the app config file? And no, using some kind of service is not an option, it needs to be a dll!
in your database class you can add your connection string like this as base parameter
public class mydb:DbContext
{
public mydb() :base("Server=....")
{
}
}
or you can add your Connection string to app.config and just put its name in base
Example:
public mydb() :base("ConnectionstringName")

How can I make the Entity Framework Type Provider use the runtime config file?

I have an F# library project that I'm using from a C# web project. I would like to use the Entity Framework Type Provider in my F# project, and have it get the connection string from the Web.config - but I'm having trouble getting this working.
type internal FooDb =
SqlEntityConnection<ConnectionStringName="FooDb", Pluralize=true>
At design time, I'm required to have an App.config file in the F# library project with a connection string having the matching name.
At runtime, when calling my F# code from the C# web project, I get an error that it can't locate the "App.config" file. This surprises me, because I was expecting that at runtime it would just use ConfigurationManager.ConnectionStrings to load the connection string from the currently-active config file (in the case of a web app, Web.config). However this doesn't seem to be the case.
I tried adding the ConfigFile parameter:
type internal FooDb =
SqlEntityConnection<ConnectionStringName="FooDb", ConfigFile="Web.config", Pluralize=true>
But this just made it complain at design time that it couldn't find Web.config.
Then I renamed the App.config file in the F# library project to Web.config and that seems to have gotten things working. However, I'm uneasy about this solution. Is this really how it's intended to work? I have to have a web.config file in my library project? What would I do if I wanted to use the same library from a command-line executable, and in that environment the config file is called AssemblyName.exe.config?
Forcing me to hard-code the name of a config file that can have different names in different contexts seems very brittle, and a poor design. Please tell me I'm missing something.
The issue you've encountered seems rather unfortunate indeed, and I don't know whether you are missing something or not. However, the SqlEntityConnection documentation says that FooDb should have a GetDataContext overload where a "connectionString parameter may be used when the connection string is determined at runtime." Perhaps that will give you a decent enough work around (i.e. pass in the connection string from ConfigurationManager.ConnectionStrings yourself).

WCF Data Service with EF fails to expose imported functions

(I am also using .NET 4.0 and VS 2010.)
I created a function import returning a complex type, as explained at http://msdn.microsoft.com/en-us/library/bb896231.aspx. The function import and new complex type appear in my .edmx file and in the Designer.cs file. However, the function does not appear when I view the service in the browser, and when I add or update a service reference in the client project, the function does not appear there either - as is to be expected, given the first result.
Creating an imported function and using it seems conceptually very simple and straightforward, and one would think it would just work, as Microsoft's step-by-step instructions appear to suggest: http://msdn.microsoft.com/en-us/library/cc716672.aspx#Y798 (which article shows the SP returning entity types - I tried this also, and it doesn't work for me either).
This blog post shows the addition of a method to the DataService class, which Microsoft's instructions omit: http://www.codegain.com/articles/wcf/miscellaneous/how-to-use-stored-procedure-in-wcf-data-service.aspx I tried adding one method returning a list of entity types and another returning a list of complex types, and still had no success. I still could not access the functions, either directly via the browser or from the client application via a service reference.
Thanks in advance for any help with this.
config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);
MS would do well to add a note to the walkthroughs stating that the above bit of code must be there. (It may be better to enable each operation explicitly than to use "*".)
http://www.codegain.com/articles/wcf/miscellaneous/how-to-use-stored-procedure-in-wcf-data-service.aspx shows that line of code. Also, something it is there in the code, commented out, when one creates the WCF Data Service. Some of us like to delete commented-out code that we aren't using and that seems irrelevant - perhaps doing so a bit prematurely, sometimes.

Accessing Datasource from Outside A Web Container (through JNDI)

I'm trying to access a data source that is defined within a web container (JBoss) from a fat client outside the container.
I've decided to look up the data source through JNDI. Actually, my persistence framework (Ibatis) does this.
When performing queries I always end up getting this error:
java.lang.IllegalAccessException: Method=public abstract java.sql.Connection java.sql.Statement.getConnection() throws java.sql.SQLException does not return Serializable
Stacktrace:
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.doStatementMethod(WrapperDataSourceS
ervice.java:411),
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.invoke(WrapperDataSourceService.java
:223),
sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source),
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25),
java.lang.reflect.Method.invoke(Method.java:585),
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155),
org.jboss.mx.server.Invocation.dispatch(Invocation.java:94),
org.jboss.mx.server.Invocation.invoke(Invocation.java:86),
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264),
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659),
My Datasource:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/xxxxxDS</jndi-name>
<connection-url>jdbc:oracle:thin:#xxxxxxxxx:1521:xxxxxxx</connection-url>
<use-java-context>false</use-java-context>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>xxxxxxxx</user-name>
<password>xxxxxx</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>
Does anyone have a clue where this could come from?
Maybe someone even knows a better way how to achieve this.
Any hints are much appreciated!
Cheers,
Michael
Not sure if this is the same issue?
JBoss DataSource config
DataSource wrappers are not usable outside of the server VM
#Michael Well, java.sql.Connection is an Interface - it might technically be possible for the concrete implementation you're getting from JBoss to be Serializable - but I don't think you're really going to have any options you can use. If it was possible, it would probably be easy :)
I think #toolkit might have said the right words with useable outside the VM - the JDBC drivers will be talking to native driver code running in the underlying OS I guess, so that might explain why you can't just pass a connection over the network elsewhere.
My advice, (if you don't get any better advice!) would be to find a different approach - if you have access to locate the resource on the JBoss directory, maybe implement a proxy object that you can locate and obtain from the directory that allows you to use the connection remotely from your fat client. That's a design pattern called data transfer object I think Wikipedia entry
#toolkit:
Well, not exactly. Since I can access the data source over JNDI, it is actually visible and thus usable.
Or am I getting something totally wrong?
#Brabster:
I think you're on the right track. Isn't there a way to make the connection serializable? Maybe it's just a configuration issue...
I've read up on Ibatis now - maybe you can make your implementations of Dao etc. Serializable, post them into your directory and so retrieve them and use them in your fat client? You'd get reuse benefits out of that too.
Here's an example of something looks similar for Wicket
JBoss wraps up all DataSources with it's own ones.
That lets it play tricks with autocommit to get the specified J2EE behaviour out of a JDBC connection. They are mostly serailizable. But you needn't trust them.
I'd look carefully at it's wrappers. I've written a surrogate for JBoss's J2EE wrappers wrapper for JDBC that works with OOCJNDI to get my DAO code unit test-able standalone.
You just wrap java.sql.Driver, point OOCJNDI at your class, and run in JUnit.
The Driver wrapper can just directly create a SQL Driver and delegate to it.
Return a java.sql.Connection wrapper of your own devising on Connect.
A ConnectionWrapper can just wrap the Connection your Oracle driver gives you,
and all it does special is set Autocommit true.
Don't forget Eclipse can wrt delgates for you. Add a member you need to delegate to , then select it and right click, source -=>add delgage methods.
This is great when you get paid by the line ;-)
Bada-bing, Bada-boom, JUnit out of the box J2EE testing.
Your problem is probably amenable to the same thing, with JUnit crossed out and FatCLient written in an crayon.
My FatClient uses RMI generated with xdoclet to talk to the J2EE server, so I don't have your problem.
I think the exception indicates that the SQLConnection object you're trying to retrieve doesn't implement the Serializable interface, so it can't be passed to you the way you asked for it.
From the limited work I've done with JDNI, if you're asking for an object via JNDI it must be serializable. As far as I know, there's no way round that - if I think of a better way I'll post it up...
OK, one obvious option is to provide a serializable object local to the datasource that uses it but doesn't have the datasource as part of its serializable object graph. The fat client could then look up that object and query it instead.
Or create a (web?) service through which to access the datasource is governed - again your fat client would hit the service - this would probably be better encapsulated and more reuseable approach if those are concerns for you.