Dapper .net loses connection string with Sybase 12 or 16

That is interesting; it looks like it relates to:

internal Identity(string sql, CommandType? commandType, IDbConnection connection, Type type, Type parametersType, Type[] otherTypes)
    : this(sql, commandType, connection.ConnectionString, type, parametersType, otherTypes, 0)
{ }

So it is the simple act of querying the .ConnectionString that is failing. You say:

But if I use ADO.Net - everything works fine!

I imagine that is because when using ADO.NET you haven't had any reason to look at the .ConnectionString once a connection is open. Probably the first thing to do (can you check this?) is to see whether .ConnectionString does throw an error, i.e.

using(var conn = new WhateverConnection(connectionString)) {
    conn.Open();
    // maybe execute a command, just for fun
    Console.WriteLine(conn.ConnectionString);
}

of course if might be something else in the code that is somehow making it incorrectly think it relates to Entity Framework, as per:

iAnywhere.Data.SQLAnywhere.SAConnection.CalledByEntityFramework() +263

However! Ultimately, it looks like the "problem" here is: a bug in the SAConnection implementation. Frankly I think this is something you need to log with sybase.

I decompiled the assembly, showing the following code:

public override string ConnectionString
{
    get
    {
        SATrace.PropertyCall("", this._objectId);
        if (this._connStr == null)
        {
            return "";
        }
        if (SAConnectionOptions.GetAdoDotNetTesting(this._connOpts))
        {
           //.....
        }
        if (SAConnectionOptions.GetPersistSecurityInfo(this._connOpts) || base.DesignMode || SAConnection.s_isHostedByVisualStudio)
        {
            return this._connStr;
        }
        if (this.CalledByEntityFramework()) //It goes wrong here
        {
            return this._connStr;
        }
        string result;
        string text2;
        string text3;
        SAConnection.RemoveKeyValuesFromString(this._connStr, SAConnectionOptions.s_passwordKeys, false, out result, out text2, out text3);
        return result;
    }
    set
    {
        ///...
    }
}

So I added the following to our connection string: ;Persist Security Info=True This will allow the code to go in the 3th if statement, instead of the 4 which is causing the null reference.