I'm trying to add SQL2008 support to a .NET 2.0 application. However, my unique constaint is that some users will still use SQL2005, and I don't want to require them to install the SQL2008 client components.
The actual set of DLLs I need for SQL2008 are different than SQL2005. The code can remain the same.
Botton line, I need a way in VS2005 (or manually editing the assembly file) to say:
If the user has DLL_1 v2, DLL_2 v2, and DLL_3 v2 use them. If not, use DLL_1 v1 and DLL_2 v1.
You can change the connection strings of your table adapters in code so was it necessary to write entirely new dlls for SQL2008?
Perhaps I'm missing your point, but what will changing the connection strings do?
I'm not writing new DLLs myself, I'm referring to the DLLs microsoft supplies to SQL server access.
If you're just doing basic data access, you shouldn't need to worry about it, either native client should work fine, and you can let the framework hook into it for you. If you specify the SQL client, .Net will use whichever one it can get its hands on. Are you using SMO Objects? In that case there could be some dependency issues.
You shouldn't have to make a direct reference to any DLLs at all. If you are using System.Data.SqlClient to connect to your DBs then .Net will know how to talk to both of them. If you aren't using System.Data.SqlClient to communicate with your servers then the next question become can you switch over to that namespace for your DB communication.
This may be a little outside the realm of what you are looking to do, but you could create a service layer abstraction where everybody connects to the service layer and the service layer handles the routing and the communication with the DB servers and you can communicate with the service layer either via SOAP or .Net Remoting. I've started to switch all of my apps over to this method as it allows me to focus my business logic and db abstraction in one controlled location and working with the presentation on the local machine.
Does the user select which DB version they are installing to? (I'm assume there's some kind of install process). Can you swap out the dll files in the bin folder on the install based on the selected database version?
Thanks for the ideas! However we're still not quite there...
No, the user does not select which DB version they're installing to. The intention is to allow SQL2005 and/or SQL2008, even in the same installation. For example, we have an administration application allows users to manage database instances across different SQL servers.
I realize that we could add a dialog to choose whether or not SQL2008 support is needed. However, this would expand our test matrix even more, which is what we're trying to avoid.
I believe I do need to reference the DLLs directly. I'm doing a lot more with the databases than just connecting and querying.
The DLLs I need are:
Any other ideas, thoughts?
Reflection will allow you to dynamically load the DLL set you want at runtime. So you can detect whats available and load it then.
The only drawback is that using Reflection can make your job a bit more difficult and time consuming.
I'll look into using reflection to load the DLLs, it sounds like that's pretty much the only option for me other than requiring the SQL 2008 Client Components.
As for redistributing the DLLs, I did read the license. There's a couple questionable terms in there that apply to us (e.g., for hosted software). Plus, it's an even more complicated issue because our clients data is very sensitive, so they go through extensive approval processes to allow anything, such as DLLs we include to be installed.
Thanks for the help!
"You can use all the functionality in a DLL and not reference it directly"
By which means are you referring? Reflection? Proxy? Something else?
You could use a service container and wire up the dependencies in your configuration file. It would probably entail separating out the code that depends on either set of assemblies into separate classes and assemblies.
Ie. two class libraries, one for 2005 and one for 2008, both containing a set of classes implementing a set of common interfaces. The application would then just ask the service container for an object that implements one of the common interfaces, and the application configuration file would dictate which implementation would be used.
This configuration could of course also be done in code at application startup.
This approach would also allow you to do more than just use a different set of dll's. If some things needs to be done differently on 2005 than on 2008, you could implement those differences in your class libraries, and the application would be none the wiser.