title: Get context connection and use it as a connection in other place
body: <p>I am working in an environment in which enterprise host application is calling client applications with implemented COM interface via ProgID. This is the way how programmers of host application allow to enhance application with plugins.</p>
  
  <pre><code>Host app &lt;-&gt; COM interface &lt;-&gt; Client app
  </code></pre>
  
  <p>The client app can use methods from provided COM interface.</p>
  
  <p>One of that method is <code>RunSqlQuery(rawSqlQuery)</code>. It has possibilities to fully communicate with SQL within the scope of a logged-in user of the host application (based on connection authentication type it could be Windows or SQL user).</p>
  
  <p><strong>What I am looking for is a way to get a current connection context which was started from the host application and use it as a connection for DbContext.</strong></p>
  
  <p>Why?</p>
  
  <ol>
  <li>I want to use some ORM for data binding, parameters binding, change tracker, etc.</li>
  <li>I can use my own explicit SQL connection for it, but with my own SQL connection, I don't reach local temporary tables, which are created within the host application on its start. Host application heavily rely on stored procedures, which in turn operates with that mentioned local temporary tables</li>
  <li>In the case of using explicit SQL connection (main SQL connection holds host application), I need to manage connection credentials in the connection string (when it is not allowed SQL server authentication mixed mode)</li>
  </ol>
  
  <p><strong>For clarity, where is the problem, something similar is well known in the SQL CLR world:</strong></p>
  
  <p>In SQL CLR UDF there is possibility to use <code>context connection=true</code> as a connection string for instance of SqlConnection (more <a href="https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/data-access/context-connection?view=sql-server-2017" rel="nofollow noreferrer">here</a>).</p>
  
  <p>In the link above they wrote:</p>
  
  <blockquote>
    <p>The connection is in a different database session than the stored
    procedure or function, it may have different SET options, it is in a
    separate transaction, it does not see your temporary tables, and so
    on.</p>
  </blockquote>
  
  <p>And in other places in that link:</p>
  
  <blockquote>
    <p>You probably want the stored procedure or function to execute in the
    context of that connection, along with its transaction, SET options,
    and so on. This is called the context connection.</p>
  </blockquote>