[Solved] N-Tier ORM Project Context Construction Defect

[Brian]

If you have a project that contains your domain model and the associated context, it will have its own App.Config that looks something like this:

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="My_DBC" connectionString="data source=(local)\SQL2008;initial catalog=My_DB;integrated security=True" providerName="System.Data.SqlClient"/>
  </connectionStrings>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/></startup></configuration>

For Telerik ORM version 2010.2.714 (Jul 14, 2010), when you include that project from a WPF application and create your context with a: MyContext context = new MyContext(); it will give an error containing this:

'format of the initialization string does not conform to the specification starting at index 0'

As suggested by Telerik in the other thread, you can copy the connectionstrings section of App.Config to the local WPF application app.confg, but I don't like this, as it puts configuration settings in two places, which makes for configuration management headaches.

You can edit the dynamically created MyContext.cs file and set connectionStringName (from 'My_DBC') to the actual connection string as follows:

public partial class MyContext : OpenAccessContext
{
    private static string connectionStringName = @"data source=(local)\SQL2008;initial catalog=My_DB;integrated security=True";
}

Clearly, this is undesirable.  Instead, I would expect code in OpenAccessContext that would check the running assembly and deduce that the model is in another, and get the connection string from there.  To do that, the connection string would need to be stored as an assembly resource, instead of in app.config.  I really like that approach, since it is clean and supports easy DLL xcopy distribution.  I know it goes counter to Microsoft's approach a bit.  It is too bad that there is not a System.Configuration.ConfigurationManager.ConnectionStrings does not support this for assemblies as well as app.config files.

My solution for now is to set the connection string in my database initialization function, which is called on application startup.  I have a static variable where I store the connection string, making the value in App.Config unused, except for design-time.  Then, I modified MyContext.cs so that the constructors that take a connection string set connectionStringName = connection, so that the many later parameter-less calls to new MyContext() will use it.  I still don't like editing the auto-generated file, but see no alternative for now other than copying the section in app.config to every client (ASP.NET, WPF, WCF) I have (there are several that use the same model library).

I suggest that Telerik make some changes to the auto-generated MyContext code to reflect the above, or something similar.  Maybe an explicit call that lets you modify connectionStringName?  Better yet, add a static string called connectionString, which if non-null is used instead of connectionStringName.

This is the same issue as discussed at the end of the Azure connection string problem thread.

[Serge]

Hello Brian Womack, PhD,

 The main reason behind storing connection strings in the app.config and config files for that matter is that they are plain text. You do not need to recompile the whole solution if your connection string has to change. This way you can distribute an application without recompiling for each and every one of the machines you want to install it to. 

And while it might look bothersome to care over two connection strings in the long run it is usually preferable. When you are deploying you would only care for the connection string in the executing assembly, and you will in fact have one connection string you need to worry about and one you can forget about, as you are not shipping it. 

However if you want to achieve this please let me make a few points. As you have guessed it is really not recommended to modify the auto generated files as you will lose all the changes the next time you perform a save on the rlinq. Instead you can either extend the generated classes through a partial class or just create you own context class. It should look a little like : 

public partial class MyContext : OpenAccessContext
{
    private static string connectionStringName = "your-connetionstring-here";
    private static BackendConfiguration backend = GetBackendConfiguration();

    private static MetadataSource metadataSource = XmlMetadataSource.FromAssemblyResource("EntityDiagrams1.rlinq");

    public MyContext()
        : base(connectionStringName, backend, metadataSource)
    { }

    public static BackendConfiguration GetBackendConfiguration()
    {
        BackendConfiguration backend = new BackendConfiguration();
        backend.Backend = "mssql";
        return backend;
    }


    // entity endpoints here....
}

While this is a good solution it would leave you with the context. So a much better solution would be to just modify the T4 template that is used for generating the context class. You can read more about T4 templates in this blog post and in this help article.

If you have trouble editing the T4 template please be sure to contact us back so that we can assist you with that. It should only result in a few changes in the Context.ttinclude file. If you have trouble please send us a copy of what the context should look like in your opinion and we will modify the templates for you.

Looking forward to hearing from you.

Kind regards,
Serge
the Telerik team

[Brian]

Yes, I hear you. *SMILE*  I wish I could remove the word 'Defect' from the subject line, as this is not really a defect, but a feature request.  Thanks for the reference to the template.

I suppose what I'm asking is that the ORM have some standardized way to, at compile time, to store the connection string in the app.config in the model DLL.  If a connection string is present in the app.config, it would override what is in the DLL.

Since most of the time, my connection string uses Windows authentication on (local)/SQL2008, there really won't be a need to edit it, so the above feature would make configuration management easier.

[Serge]

Hello Brian Womack, PhD,

 I am glad I was helpful. We will consider improving our connection string handling in the future versions of OpenAccess. For now we are thankful for your suggestion. 

Please do not hesitate to share your thoughts on possible improvements of OpenAccess, I cannot express how helpful the community comments are.

All the best,
Serge
the Telerik team