Disable EF Core Migration verification query
I'm running an asp.net core 2.1.4 web application with entity framework core 2.1.4 using code first. The migration and seed are done on application startup.
I've noticed a couple of EF queries checking for checking the migration history on every call:
Executed DbCommand (47ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (2ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (4ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT [MigrationId], [ProductVersion] FROM [__EFMigrationsHistory] ORDER BY [MigrationId];
No migrations were applied. The database is already up to date.
I don't want to check the database on every call. So I changed the ServiceLifetime.Singleton. But still I see this verification queries on every call.
services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(dbConnectionString,
builder => builder.MigrationsAssembly(migrationsAssembly));
}, ServiceLifetime.Singleton, ServiceLifetime.Singleton);
There is a similar question on EF6: How to disable Migration Verification during every DbContext initialization
The NullDatabaseInitializer doesn't exist in EF core.
What is recommended to do? Is this normal behavior?
entity-framework-core azure-application-insights
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
add a comment |
I'm running an asp.net core 2.1.4 web application with entity framework core 2.1.4 using code first. The migration and seed are done on application startup.
I've noticed a couple of EF queries checking for checking the migration history on every call:
Executed DbCommand (47ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (2ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (4ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT [MigrationId], [ProductVersion] FROM [__EFMigrationsHistory] ORDER BY [MigrationId];
No migrations were applied. The database is already up to date.
I don't want to check the database on every call. So I changed the ServiceLifetime.Singleton. But still I see this verification queries on every call.
services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(dbConnectionString,
builder => builder.MigrationsAssembly(migrationsAssembly));
}, ServiceLifetime.Singleton, ServiceLifetime.Singleton);
There is a similar question on EF6: How to disable Migration Verification during every DbContext initialization
The NullDatabaseInitializer doesn't exist in EF core.
What is recommended to do? Is this normal behavior?
entity-framework-core azure-application-insights
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
1
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code callingDatabase.Migrateor similar.
– Ivan Stoev
Nov 16 '18 at 8:11
Exactly, I'm calling theDatabase.Migrate()myself on application startup. But the verification queries are done on every new http request.
– Thieme
Nov 16 '18 at 8:46
1
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Thanks for your clarification! MaybeMicrosoft.AspNetCore.IdentityorIdentityServer4is causing this issue.services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();
– Thieme
Nov 16 '18 at 9:44
add a comment |
I'm running an asp.net core 2.1.4 web application with entity framework core 2.1.4 using code first. The migration and seed are done on application startup.
I've noticed a couple of EF queries checking for checking the migration history on every call:
Executed DbCommand (47ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (2ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (4ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT [MigrationId], [ProductVersion] FROM [__EFMigrationsHistory] ORDER BY [MigrationId];
No migrations were applied. The database is already up to date.
I don't want to check the database on every call. So I changed the ServiceLifetime.Singleton. But still I see this verification queries on every call.
services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(dbConnectionString,
builder => builder.MigrationsAssembly(migrationsAssembly));
}, ServiceLifetime.Singleton, ServiceLifetime.Singleton);
There is a similar question on EF6: How to disable Migration Verification during every DbContext initialization
The NullDatabaseInitializer doesn't exist in EF core.
What is recommended to do? Is this normal behavior?
entity-framework-core azure-application-insights
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
I'm running an asp.net core 2.1.4 web application with entity framework core 2.1.4 using code first. The migration and seed are done on application startup.
I've noticed a couple of EF queries checking for checking the migration history on every call:
Executed DbCommand (47ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (2ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT OBJECT_ID(N'[__EFMigrationsHistory]');
Executed DbCommand (4ms) [Parameters=, CommandType='Text', CommandTimeout='30'] SELECT [MigrationId], [ProductVersion] FROM [__EFMigrationsHistory] ORDER BY [MigrationId];
No migrations were applied. The database is already up to date.
I don't want to check the database on every call. So I changed the ServiceLifetime.Singleton. But still I see this verification queries on every call.
services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(dbConnectionString,
builder => builder.MigrationsAssembly(migrationsAssembly));
}, ServiceLifetime.Singleton, ServiceLifetime.Singleton);
There is a similar question on EF6: How to disable Migration Verification during every DbContext initialization
The NullDatabaseInitializer doesn't exist in EF core.
What is recommended to do? Is this normal behavior?
entity-framework-core azure-application-insights
entity-framework-core azure-application-insights
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
edited Nov 16 '18 at 13:12
Thieme
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
asked Nov 15 '18 at 15:41
ThiemeThieme
13410
13410
1
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code callingDatabase.Migrateor similar.
– Ivan Stoev
Nov 16 '18 at 8:11
Exactly, I'm calling theDatabase.Migrate()myself on application startup. But the verification queries are done on every new http request.
– Thieme
Nov 16 '18 at 8:46
1
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Thanks for your clarification! MaybeMicrosoft.AspNetCore.IdentityorIdentityServer4is causing this issue.services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();
– Thieme
Nov 16 '18 at 9:44
add a comment |
1
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code callingDatabase.Migrateor similar.
– Ivan Stoev
Nov 16 '18 at 8:11
Exactly, I'm calling theDatabase.Migrate()myself on application startup. But the verification queries are done on every new http request.
– Thieme
Nov 16 '18 at 8:46
1
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Thanks for your clarification! MaybeMicrosoft.AspNetCore.IdentityorIdentityServer4is causing this issue.services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();
– Thieme
Nov 16 '18 at 9:44
1
1
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code calling
Database.Migrate or similar.– Ivan Stoev
Nov 16 '18 at 8:11
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code calling
Database.Migrate or similar.– Ivan Stoev
Nov 16 '18 at 8:11
Exactly, I'm calling the
Database.Migrate() myself on application startup. But the verification queries are done on every new http request.– Thieme
Nov 16 '18 at 8:46
Exactly, I'm calling the
Database.Migrate() myself on application startup. But the verification queries are done on every new http request.– Thieme
Nov 16 '18 at 8:46
1
1
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Thanks for your clarification! Maybe
Microsoft.AspNetCore.Identity or IdentityServer4 is causing this issue. services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();– Thieme
Nov 16 '18 at 9:44
Thanks for your clarification! Maybe
Microsoft.AspNetCore.Identity or IdentityServer4 is causing this issue. services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();– Thieme
Nov 16 '18 at 9:44
add a comment |
1 Answer
1
active
oldest
votes
I found the issue:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/issues/778
After using a "real" SQL profiler I found out it was working as expected like @Ivan-Stoev said. The requests on my side were somehow using the same operation_id. So the traces and dependencies that where shown to me by application insights where actually not related.
I fixed it by removing the default DependecyTracking of AI.
private void RemoveDefaultAiDependencyTracking(IServiceCollection services)
{
var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ImplementationType == typeof(DependencyTrackingTelemetryModule));
services.Remove(serviceDescriptor);
}
Thanks for you time and sorry for wasting it..
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322973%2fdisable-ef-core-migration-verification-query%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I found the issue:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/issues/778
After using a "real" SQL profiler I found out it was working as expected like @Ivan-Stoev said. The requests on my side were somehow using the same operation_id. So the traces and dependencies that where shown to me by application insights where actually not related.
I fixed it by removing the default DependecyTracking of AI.
private void RemoveDefaultAiDependencyTracking(IServiceCollection services)
{
var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ImplementationType == typeof(DependencyTrackingTelemetryModule));
services.Remove(serviceDescriptor);
}
Thanks for you time and sorry for wasting it..
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
add a comment |
I found the issue:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/issues/778
After using a "real" SQL profiler I found out it was working as expected like @Ivan-Stoev said. The requests on my side were somehow using the same operation_id. So the traces and dependencies that where shown to me by application insights where actually not related.
I fixed it by removing the default DependecyTracking of AI.
private void RemoveDefaultAiDependencyTracking(IServiceCollection services)
{
var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ImplementationType == typeof(DependencyTrackingTelemetryModule));
services.Remove(serviceDescriptor);
}
Thanks for you time and sorry for wasting it..
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
add a comment |
I found the issue:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/issues/778
After using a "real" SQL profiler I found out it was working as expected like @Ivan-Stoev said. The requests on my side were somehow using the same operation_id. So the traces and dependencies that where shown to me by application insights where actually not related.
I fixed it by removing the default DependecyTracking of AI.
private void RemoveDefaultAiDependencyTracking(IServiceCollection services)
{
var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ImplementationType == typeof(DependencyTrackingTelemetryModule));
services.Remove(serviceDescriptor);
}
Thanks for you time and sorry for wasting it..
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
I found the issue:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/issues/778
After using a "real" SQL profiler I found out it was working as expected like @Ivan-Stoev said. The requests on my side were somehow using the same operation_id. So the traces and dependencies that where shown to me by application insights where actually not related.
I fixed it by removing the default DependecyTracking of AI.
private void RemoveDefaultAiDependencyTracking(IServiceCollection services)
{
var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ImplementationType == typeof(DependencyTrackingTelemetryModule));
services.Remove(serviceDescriptor);
}
Thanks for you time and sorry for wasting it..
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
edited Nov 16 '18 at 13:11
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
answered Nov 16 '18 at 12:05
ThiemeThieme
13410
13410
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322973%2fdisable-ef-core-migration-verification-query%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The default behavior of EF Core is to do nothing (the equivalent of EF6 NullDatabaseInitializer). There must be some application code calling
Database.Migrateor similar.– Ivan Stoev
Nov 16 '18 at 8:11
Exactly, I'm calling the
Database.Migrate()myself on application startup. But the verification queries are done on every new http request.– Thieme
Nov 16 '18 at 8:46
1
Nope. There must be some code of yours (or the libraries other than EF Core you use) which is doing that. EF Core doesn't.
– Ivan Stoev
Nov 16 '18 at 8:58
Thanks for your clarification! Maybe
Microsoft.AspNetCore.IdentityorIdentityServer4is causing this issue.services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders();– Thieme
Nov 16 '18 at 9:44