January 2008 Archives

Overriding Dataset Settings Connection String

| 3 Comments | No TrackBacks
So say you have a database connection [DataSet] that you have added to your project.  You do not want to store the password with it (which will end up in the .config file) and may want to change the database name at runtime from what you are using at runtime.  Doing this seems a bit off, since you can not write to the ConnectionString that is creating in the settings portion of the VS designer!  You can not change it to type User instead of Application scope either.

A useful tidbit that I discovered when looking for how to change this.  While it should seem immediately obvious how to modify a connection string at runtime, it is not.  After doing some digging I found the following code to place in Settings.cs [Go to settings, then click "View Code"].

In Settings.cs:
Now when working with your dataset, each time it needs to get the connection string it will return your custom connection string.  This is useful incase you do not want to store the password in your configuration files.  Also, this will allow switching different databases of the same type with your dataset at runtime.  I do that -- I have a "master" database that I use for development, and at runtime I switch to the live database.. both have exactly the same type of structure.

Hope you find this useful!

Matthew MacSuga

My First Post - A C# Plugin Paradise

| No Comments | No TrackBacks
First post!

Thank you for finding my little spot on the Internet.  I hope that you find what I am planning to write to be not only helpful, but insightful.  When I'm looking over here and over there for information I come across so many sites and ideas that I have a difficult time of keeping track of everything.  With this blog, for my own purposes.. I plan on collating the ideas that I find into one solid resource on a particular subject, while injecting my own ideas and experiences into a particular subject.  I have high aspirations for what I am attempting to do here, and I hope that you thoroughly enjoy reading what I have to write.

Without further interruption, here is the first post in what I hope is a good series of posts on the elusive subject of:  Plugins, Addins, and application Extensibility.

So I've been working with C# for some time now and over the past year I have been tinkering with supporting Plugins off and on.  I decided this week that I really needed to dig deep and get a flexible plugin architecture written for my application(s) so that I, and 3rd party developers could easily extend my application beyond what I initially write. 

There are so many, and so few resources on this subject.   It's really quite surprising that it is so incredibly difficult to find the right resource.  Every article that I have read implements plugins in a slightly different way.  Some go straight for the meat and simply load the plugin (Assembly.LoadFile / Activator.CreateInstance) while others do it the "better" way and properly create a new AppDomain and then load the plugin(s).

What I am struggling with is making a system that is flexible, powerful, easily implemented, efficient, and fun to work with.  I need to have several different types of plugins -- database plugins (MySQL, SQL Server, SQLite, MS Access), different UI layers (each client has their own unique interface to the core of the application), different printing functions (again, based on client), etc.  So the huge question is, how do I implement this in a way that's effective and has a solid foundation on which to base an entire application.

Some have suggested using CAB (Composite Application Blocks) which is part of Microsoft's Patterns & Practices library.  While this is very effective, it is also a beast at first glance.  Not to mention, I am (for good or bad!) one of those programmers who just has to do it on their own.  Part of the reason for that is building a solid understanding of exactly what it is that I am doing.  Surely I could build an entire application based on and around CAB, but I would want to dig at the internals and understand all of the nuts and bolts on how it works. If I design such a system myself, then I will have complete control over the end product and fully understand exactly how it works.

In future posts, I will be posting sample code as I move along in my discovery of how building a plugin system actually works -- with real, concrete examples so that you dear reader, can take it and build something for yourself.  I hope to cite examples on how I came to my conclusions and give credit where credit is due.

Speaking of credit, I would sincerely like to thank all contributing members of The Code Project (http://www.codeproject.com) for all of their hard work in teaching me how to be a better programmer, and learn new tricks.  Without that resource, I certainly would not be where I am today and have the understanding of C# and the .NET framework that I do now.  I have found it to be an invaluable resource and check it for new articles everyday hoping that I will learn something new and exiting on which to base future works.

Thank you !

Matthew MacSuga

About this Archive

This page is an archive of entries from January 2008 listed from newest to oldest.

March 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.