|
I downloaded the code and plugged it right into my application and it worked on the first build. This is just what I needed. Now I can continue with my project. Thanks again.
|
|
|
|
|
Thanks alot for pointing me to the MySettings_SettingsLoaded - event.
Of course I was one of these "workaround-workers", who had to replace the connection in each damned command-object in whole the application - booo!
I'd like to remark, to evade the Readonly-restriction of a setting-Property may concern security matters.
(Usually I don't care about security - how secure is storing a connectionstring in a setting-property at all??)
To exceed this lack of security I'd like to introduce my way of dealing with connectionstrings:
I simply replace the DataDirectory with the current WorkingDirectory.
The WorkingDir again can be redirected by creating a File-Link and edit its WorkingDirectory-Property (and run the Application by clicking the Link).
So I can use the same Application.exe with different Databases, if I want.
What do you think about this hack?
Option Strict On
Option Explicit On
Imports System.Reflection
Imports System.Configuration
Namespace My
Partial Friend NotInheritable Class MySettings
Private Sub MySettings_SettingsLoaded( _
ByVal sender As Object, ByVal e As SettingsLoadedEventArgs) Handles Me.SettingsLoaded
Dim BindFlags As BindingFlags = _
BindingFlags.GetProperty Or _
BindingFlags.Public Or _
BindingFlags.Instance
For Each Prop As PropertyInfo In GetType(MySettings).GetProperties(BindFlags)
Dim Attr As SpecialSettingAttribute = DirectCast( _
Attribute.GetCustomAttribute(Prop, GetType(SpecialSettingAttribute)), _
SpecialSettingAttribute)
If Attr IsNot Nothing AndAlso Attr.SpecialSetting = SpecialSetting.ConnectionString Then
Dim DataDir As String = Environment.CurrentDirectory
Me(Prop.Name) = Prop.GetValue(Me, Nothing).ToString.Replace("|DataDirectory|", DataDir)
End If
Next
End Sub
End Class 'MySettings
End Namespace
|
|
|
|
|
Hmmm. At first glance, what comes to mind is that this approach seems would be for a database that is local to the specific application (especially when working with Vista). To share the database among different programs of the same vendor, then the application shared directory should be used. Also, be aware that Vista does not allow access to the programs installation directory at run time. All changeable files are saved in a special redirection folder. If you commonly save log files and what not in the applications current working directory, these will be redirected to another location. For user local databases, they should be stored in the users data directory. For shared application databases, they should be stored in the shared directory or on a network UNC. It's the network UNC issue...
As for connectiostrings and security in general, my approach is specifically for an application that will connect to databases which may be on network locations which are unknown at the time of development or may change from time to time. In a client-server environment this is often the case. It also allows the database connection string to be easily change after installation between, for example, a test database and a live database, but using the exact same code base and strongly typed database objects. For me this has huge benefits in product testing since you always know the code to access each database is absolutely identical without special fiddling with connection strings each time a database is opened. It also can help satisfy HIPAA security restrictions that would allow a support person to test a live installation of a client progam by easily changing the connection string to a test database which contains only dis-identified patient data.
|
|
|
|
|
because its a good idea and many developer indeed will use it
why we dont make things clear
i see one single person work this code out
and we all watching whats going on ?
please we need to clear this code more than that
thanks
|
|
|
|
|
I have no idea what you are asking for...... (he says, hoping this is not a troll)
|
|
|
|
|
hi mjmeans
sorry , i thought this code working with u.
because i did tried everything and following the comments and still doesnt work
thanks
|
|
|
|
|
First comfirm that you are writing in Visual Basic. This does not work at all in C# and will not ever work in C# because it does not have the built-in application framework that Visual Basic has. Then go over the instructions again. It DOES work. maybe you created the xxxxUserOverride setting as a connection string, which is wrong; it must be set as a normal user scoped string.
|
|
|
|
|
Hi, I saw your article and it seems to ve very good, I tried to use your solution, but I can´t understand something:
1.- I use My.Settings.SetUserOverride("TRASLADOSDBUserOverride", strRuta)
In here I use TRASLADOSDB as my Application scope connection string and TRASLADOSDBUserOverride as the User scope string. strRuta is the string in which I have my new conection string.
2.- in the module you have 2 events (userOverride_SettingsLoaded and userOverride_SettingsSaving)
But When are they accesed???? or How do I have to Access them in order to perform the change of the conection string from TRASLADOSDBUserOverride to TRASLADOSDB?, because TRASLADOSDB never changes
3.- I have followed step by step your article but I still can't change the connection string
Please I'm very
|
|
|
|
|
You should call My.Settings.SetUserOverride("TRASLADOSDB", "newstring") whenever you want to change the saved DB connection string. Do not include "UserOverride" in the name of the string to be overridden when calling SetUserOverride().
|
|
|
|
|
Thanks!! I have changed the Property from "TRASLADOSDBUserOverride" to "TRASLADOSDB", It works fine!!!
Thanks a lot!!!
|
|
|
|
|
Is it possible for you to translate this great class in C# ? I'm a novice and so I can't do it by myself . Thank you in advantage!
|
|
|
|
|
I don't think this is possible. The code requires the application framework created by the VS2005 when you enable the project property "Enable application framework", and "Dave My.Settings on Shutdown" for VB projects. I don't think C# projects have that support.
|
|
|
|
|
I've tried almost everything to get through this problem, and the most reasonable solution I found was to change the app.config file dynamically. But your solution is exactly what I've been looking for. It worked great. Vote:5
|
|
|
|
|
HI. I generally just use app.config files. I copy name of connection string from app.config of project that contains TableAdapters and then I put them in final app.config.
This I put in final app.config and it can be changed before you start application.
<connectionStrings>
<add name="Model.My.MySettings.ConnectionString" connectionString="Data Source=ORAX1;Persist Security Info=True;User ID=u1;Password=p1;Unicode=True" providerName="System.Data.OracleClient" />
</connectionStrings>
For client-server applications, i also similar type of configuration, but change it at run time on login with. With this type of authentication, user passes username and password on login. Tableadapters than use modified connection string.
<connectionStrings>
<add name="Model.My.MySettings.ConnectionString" connectionString="Data Source=ORAX1;Persist Security Info=True;User ID={0};Password={1};Unicode=True" providerName="System.Data.OracleClient" />
</connectionStrings>
dim pattern=My.Settings("ConnectionString")
dim conn as string=String.format(pattern,username,password)
My.Settings("ConnectionString")=conn
|
|
|
|
|
Yes. There are several ways to solve the problem.
But my solution is, in my opinion, better and more elegant because it works for applications that use strongly typed datasets where the table adapters are created automatically by the designer. The table adapter's connection string is also automatically coded by the designer to an application scoped (and uneditable) My.Settings string that was used on the developer's machine and automatically persisted. This original developers's machine connection string is then automatically loaded from the application scoped My.Settings string upon first use of the table adapter.
Numerous other people have come up with workarounds that involve 1) reading and writing to the registry, or INI file, or XML or other config file and, 2) reading them back in and manually applying the connection strings to the table adapters which 3) already have the wrong, but original, developer's machine connection string applied.
One other intriguing solution I have seen involved manually editing the .vb class behind the XML data source to change the My.Settings call to a different string. But if you made the slightest change to the schema, Visual Studio would instantly and without warning overwrite your change and replace it with the original developers application scoped connection string.
It is easy for bugs to occur with the other methods also because 1) if a designer created table adapter is used BEFORE setting its connection string, it will use the wrong string and setting connection string and the table adapter will ignore changes to its connection string property afterwards and, 2) as a program grows to enterprise complexity, more and more table adapters and possibly more data sources would be used and it is easy to forget to set the conenction string peroperty of the table adapter to the correct string.
This class solved all these problems at once with minimal editing required with each new application scoped connection string, can easily support dozens of connection strings with virtually no additional programming code, and is ClickOnce friendly.
|
|
|
|
|
I guess I am missing something. The way I do it now, I just copy-paste connection string from app.config from datasets.dll to finalexeapplication.exe.config. This can be done on deployment server. Upon initialization of tableadapters, they look for connection string in finalexeapplication.exe.dll, not in original dll.
My table adapters are also automatically created.
But then I really don't know if my connection string are aplication or user scoped, I just use default. I also don't know if my method will work in future releases of .net. And I also don't know how this would effect ClickOnce.
Anyway thanks for great article, it is always nice to read about configuration/deployment issues.
|
|
|
|
|
I know this is off topic, but I've never understood how to use the app.config for a .dll project in a client-server app. And since my app is C# based, this aricle doesn't work for me.
|
|
|
|
|
Great and simple tutorial, thank you very much.
This solution is good so far, but is there a way to change an existing connectionstring? I have already added a Datsource during development, and when it comes to the Production Machine, the connectionstring needs to be changed, unfortunately its not declard as user string, but as machine string already...any ideas?
Thanks i advance,
Fluffe
|
|
|
|
|
I am not sure what you are asking for. If you need to change the connection string on a production machine that is already installed and you are unable to add this class to your project and distribute an update, then this calss will not help you. If you can distribute an update to your client with the above class then 1) add a new user override string as shown above so that the class can use it to override the connection string you setup during development; 2) add a dialog to allow your user to change the connection string; 3) remember to use the SetUserOverride() function to save the user setting or the connection string will not be read by your strongly typed datasets or table adapters; 4) remember to set the project properties to save setting on exit or the change will not be persisted.
Also, table adapters get their connection string information when they are first used to get or fill a datasest, rather than when the New function is called. So if you do not want to limit your user to setting up the connection string before any tables are opened, then you will need to re-initialize your table adapters if the user changes the connection string (i.e. 'MyTableAdapter1 = New MyTableAdapter').
I am working on a connection properties dialog that works like VS 2005 connection properties but it is not ready to post. It only works for SQL Native Client databases and only with integrated security. Work is killing me right now so I dont know when I will be able to post that, so for the time being you are on your own as to how to ask the user for the proper connection string if you want that under user control.
If the production connection string needs to be hard coded, but different that the development connection string, then 1) add a registry setting into your installer; 2) in your form_load event, read the registry setting and call SetUserOverride. Loading it in the form_load event handler should guarantee that the table adapters have not yet tried to get or fill a dataset.
Hopefully your scenario is one of those I mentioned here. If I have misunderstood what you are trying to do, please try to restate it or give me some more details about your specific problem.
|
|
|
|
|
Hello again, thanks for your fast and long reply, I think I understand it alot better now, I will play with that in a moment. What I ment was the following, when I use the Wizzard to add a Datasource to my Project, I get a connectionstring written to the app.conf automatically. Since this connectionstring is pointing to my local SQL-Server, this connectionstring is useless when the Application is installed on another Location/Computer who has a different SQL-Server running. So my Idea was to use your knowledge to edit the existing String ( StringName, Connection, Declared as Application, not as User), and change this string during runtime to point to the different SQL-Server then. Since my english is pretty poor, I dont know how to explain it better. However, your article already helped me getting a better understanding of how it can work, and thats what this side is all about, thank you again!
|
|
|
|
|
So, I don't think you can directly modify the app.config file. If you use ClickOnce, the file is hard to find, and I think ClickOnce also checks and replaces damaged files automatically. So finding and modifying app.config is not the way to go. What my class does, is captures the event after app.config and user.config are loaded. Then examines the list of user settings to override application setting with the appropriate user setting.
This gives you the best of both worlds, since user settings (and thus those changed via SetUserOverride) are never saved when you are debugging in Visual Studio so your development environment is never permanently affected, but you can still temporarily (on a single run basis) connect to alternate databases. When you install the release version in your production environment, then any change to the connection string via the SetUserOverride method will be persisted.
If you use ClickOnce deployment remember that you need call Deployment.Upgrade() (or is it Deployment.Update? I can't remember) to migrate any user settings that were made in the previous version are copied to the current version. But call this must only be called once. I think the logic goes something like this.... After making a user integer setting NeedsUpdate=1 then add this to the form_load event of your main form (or splash form).
If My.Settings.NeedsUpdate=1 Then
My.Application.Deployment.Update()
My.Settings.NeedsUpdate=0
End If
|
|
|
|
|
Hello again, and thanks alot for your effort to answer my question. I played alot with everything regarding the app.conf file, and finally I found a solution that works for me, of course benefit from your source and example, so again, thanks alot, helping me so much!
Fluffe
|
|
|
|
|
Also, make sure you make the correction I posted a few days ago. I just updated the text so you should copy the class from the article again, or make the correction manually. The linked file is not updated yet.
|
|
|
|
|
Everyone. I got the userOverride_SettingsSaving backwards when writing the article. I will update the download sometime this weekend. The line should be "Me(userProperty) = Me(appProperty)". Do not change the line in userOverride_SettingsLoaded.
|
|
|
|
|
You saved my day (and night)....
Larry
|
|
|
|
|