The original goal of changing the connection string is to obtain metris of EF usage in SQL Azure. The problem with this is that fiddling with the connection string when the user is not explicitly asking for it is somewhat dangerous:
- If an application tries to share the same connection string between an EF model and other data access code, or between a regular EF model and the universal membership provider, the application will end up with two different connection strings.
- If there is more than one connection string the connection pool is fragmented (relatively low impact) and potentially, if the application is using Sys.Tx, transactions could be promoted to 2-phase commit, which in the case of SQL Azure or SQL CE would fail.
We are getting very little value out of it "feature", so we could consider removing it. We should still make sure that connection strings created by EF at runtime or design time always contain the application token without affecting connections provided by the user.
Comments: already verified, as part of verification for issue 771
- If an application tries to share the same connection string between an EF model and other data access code, or between a regular EF model and the universal membership provider, the application will end up with two different connection strings.
- If there is more than one connection string the connection pool is fragmented (relatively low impact) and potentially, if the application is using Sys.Tx, transactions could be promoted to 2-phase commit, which in the case of SQL Azure or SQL CE would fail.
We are getting very little value out of it "feature", so we could consider removing it. We should still make sure that connection strings created by EF at runtime or design time always contain the application token without affecting connections provided by the user.
Comments: already verified, as part of verification for issue 771