Hello, Regardless of whether current implementation strategy is to change or not, Dynamic type loading will also happen for loading DB provider assemblies (e.g. System.Data.SQLite.dll), like currently DbLinq.Vendor.Implementation.Vendor.CreateDbConnection() does.
To not load assembly dynamically, you will have to add dependencies onto all DB providers, which you don't want (unless I miss some other possibilities). Atsushi Eno Pascal Craponne wrote: > Hi guys, > > I took a quick look at the code, and I definitely think that it is not > DbLinq's responsibility to directly load the required assembly. > The application know what vendors it will use, is then its own > responsibility. > To me, identifiers given in the connection string MUST just allow to > find an IVendor implementation that is already loaded. > Maybe, for DbLinq in extended mode, we may consider later to use an > extension to dynamically load the assembly, but this is not the first > priority. > > The code currently in SVN show that dynamically loading assemblies is a > complex task that is far beyond the DataContext's scope. > > Pascal. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
