BACKGROUND:
Most of my programs use table adapters, and the connection strings are stored in app settings. This works fine, but was a real PITA when switching from development to production environment. I had to change manually the connection strings before and after starting my work on any app.
After a bit of research I found how to switch connection strings for table adapters dynamically. By simply adding a custom property for connectionString, I was able to acheive this. But I still have to add code in the new event for each application so the connection strings get switched when it loads. (My connection strings are kept as an app property setting in a common DLL. I just keep one copy of the DLL with my connection strings locally, and one copy o the DLL with the production connection strings on the production server.)
NEW PROBLEM
I'd like to take this one step further and have either have the datasets change the connection strings for all table adapters they each contain when they load using the new event, or do the same from a VB module. I may have up to 3 datasets at any one time.
I do depend a lot on intellisense to help me determine which methods and properties are available, but I can not find a way to retrieve a list of the table adapters in my datasets. It does not appear that they are a part of any collection of objects as far as I can tell. I've searched a quite bit for a solution, but no luck.
Marshall
You might want to reconfigure the location of the connection strings. Make your presentation layer (i.e. the application) contain the connection string in it's app.config. Now here's the cool part ... any .DLL that is being used by the application can access the application's app.config using the ConfigurationManager.ConnectionStrings("MyConnectionString").ToString function. Your .DLL would call the connection string by name, and the call propagates up to the application's app.config. If you don't want to hard code "MyConnectionString", then you should simply pass the connection string to the .DLL via a property of an object.
If you DON'T want to rearrange the connection string "ownership", simply expose the .DLL's connection string from it's own config file via a static object in the .DLL which the application can read. Assign that to the TableAdapters.
As a side note, if you are already familiar and comfortable with what appears to be your custom DLL's, move all of the data access logic into its own DLL as a Data Access Layer (DAL) - get the data access logic out of the presentation layer!
Related
I am trying to develop a small utility program that will be deployed with other application that we already have. In order to make the utility work, I need to know the connectionString used by the application to access the database.
Since I have old and new applications, they have different ways to connect to the database. So I figured the way I would do it is something like that
All project will need to implement a dll named "Connect.dll"
This dll will include one public function name GetConnString. This function will return a string which correspond to the connection string to use to connect to the main database.
What I wanted to do was to simply include the utility in the same folder as the application and use the Connect.dll found within the folder. So far though, unless I copy the original dll found within my utility project, the utility will crash. Is there any way to do this ?
Regards,
Create a non signed assembly and enforce that all the clients use the same assembly version with (of course) the same signature.
In your utility set the property "Specific Version" to False.
This should do the trick.
I have a DLL that is a logging component that we use in many different projects. This logging component is designed to be entirely self-contained, and thus it must have its database connection string internal to it. In this project, it is completely unacceptable to require that its connection string be copied to the app.config of any project that uses it.
This has been working great for years, but now we have found that mixing its older ADO tech with new apps that use EF results in horrible performance when the logging is being done. For example, adding a single log entry when the application starts results in a > 30 second delay before the app opens.
So to combat this, I have re-written this component to use EF.
The problem is under the current EF (version 4.4 since we are targeting .Net Framework 4.0) does not offer a constructor to DBContext that allows you to specify the entire connection string. The code attempts to change the Database.Connection.ConnectionString, but the DBContext object insists on looking in the App.Config for the connection string even though we are giving it a new one.
I must get around this behavior.
I would like to switch between running on a database on the server (the real database) and a local copy that I keep for testing in localhost.
I tried to switch between db#1 (server) and db#2 (localhost) by changing the definition of the connection string in app.config (I also restarted VS to make sure nothing hides in memory). A strange thing happens: on the one hand if I query the db through datasource/preview data (in VS'10) indeed it brings the data from db#2. But when I run the application is still grabs the information from db#1, although as far as I know the connection string appears only in app.config, so I do not even understand where does it take the information from in order to connect to db#1.
While we're on the subject, what would be the more elegant way to switch between databases ? ideally from a pull-down menu I would chose the data source. But can I switch the connection string in run time ?
Visual studio maintains its own database connection info, presumably from its own app.config file. This is completely independent of your solutions app.config.
Switching databases as you suggest is relatively easy. Put 2 connection strings with different names in your app.config. Use a variable to hold the string you want and reference this wherever you are directly referencing the connection string now.
I've created a infopath 2010 form with a connection to a SP list. This connection allows me to populate a drop down list. This is working as expected if I work on an existing site.
Now I want to publish this form as a task form of a workflow feature. the workflow is part of a site template that also defines some list instances. As list instances have new IDs each time they are created, the form data connection won't work (listID and spweb absolute url are hard coded in the data connection in the xsf file).
Is there a clean way to allow me to populate a DDL in infopath without the actual list id ?
In fact, can I bind to "lists/mylist" instead of {myguid} ?
thx
(angry against Microsoft for using guids everywhere without the ability to control them).
I finally followed this approach :
In my forms, I converted the data sources to datasources shared in the host sp site. This generated for me the udcx files.
Then, I created, in VS 2010, a feature with a module to provision a DataConnection library, holding all this udcx files. In this udcx file, I replaced the GUID with tokens like $listguid$ or $weburl$
I also wrote a feature receiver to replace, after provisioning the module, my tokens with the actual values
quite painful and very disappointed with this big holes in SP development processes
a task at my hand requires me to move an ASP application from one server to another. For this, I need two command line tool like stuff to know the following info.
Get the list of com objects used in this asp project.
Get the list of registered com objects in my existing server.
Any Idea ?
A quick search for "CreateObject" should some up all the COM objects created from VBScript in the ASP pages. You should also check the global.asa for any object tags, which is the other way COM objects get instantiated. If you also have server side Javascript then you should also look for "ActiveXObject".
I expect you could extract this info with commandline tools like grep etc, but unless you are doing this over and over again on different setups then it would almost certainly be quicker to do in VS.NET or something like Agent Ransack.
As suggested by #andynormancx, search your code for appropriate calls:
CreateObject
GetObject
object tags in global.asa
ActiveXObject (from javascript)
You can use WMI objects to get a list of all COM objects on the existing server. This probably won't be hugely useful, but maybe do this on your new server and then do a diff between the two to identify differences that might be important. A sample script for getting the list of objects is here: