Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration scripts are always generated for "Development" environment #11950

Open
macsux opened this issue May 9, 2018 · 12 comments
Open

Migration scripts are always generated for "Development" environment #11950

macsux opened this issue May 9, 2018 · 12 comments

Comments

@macsux
Copy link

macsux commented May 9, 2018

dotnet ef migrations script always defines Development environmental variable. For applications that use InMemory EF provider when running in Development mode by defining multiple Configure{EnvironmentName}Services blocks this creates a problem, especially when trying to publish to Azure.

Exception message:
Microsoft.EntityFrameworkCore.InMemory is not a Relational provider and therefore cannot be use with Migrations.

Steps to reproduce

Problem is visible in https://github.com/dotnet-architecture/eShopOnWeb when trying to publish on azure and apply migrations on publish.

Further technical details

EF Core version: 2.0.2
Database Provider: Mixed
Operating system:
IDE: Visual Studio 2017 15.6.2

@bricelam
Copy link
Contributor

bricelam commented May 9, 2018

You can manually set the ASPNETCORE_ENVIRONMENT environment variable before calling dotnet ef.

@macsux
Copy link
Author

macsux commented May 9, 2018

I don't call dotnet ef directly - it's being called for me by Visual Studio during a publish to azure.

@bricelam
Copy link
Contributor

bricelam commented May 9, 2018

Interesting. We may need to add an option to the publish dialog for this...

@divega
Copy link
Contributor

divega commented May 10, 2018

@bricelam to provide workaround. @divega to follow up about how this works on deployment.

@divega divega self-assigned this May 10, 2018
@divega divega added this to the 2.2.0 milestone May 10, 2018
@bricelam
Copy link
Contributor

To work around this, you can set the environment variable before launching Visual Studio when publishing:

SET ASPNETCORE_ENVIRONMENT=Production
devenv

@divega
Copy link
Contributor

divega commented Jul 25, 2018

@bricelam, should we treat this as a duplicate of #8695? Otherwise can you remind me what this one is about?

@bricelam
Copy link
Contributor

bricelam commented Jul 26, 2018

We were going to follow up with the Web Publish team about adding an option in the UI to specify the environment.

@ajcvickers ajcvickers modified the milestones: 2.2.0-preview2, 2.2.0 Sep 11, 2018
@divega divega changed the title "dotnet ef migrations script" always runs as "Development" environment Migration scripts are always generated for "Development" environment Sep 28, 2018
@divega divega removed their assignment Oct 7, 2018
@divega divega removed this from the 2.2.0 milestone Oct 7, 2018
@divega
Copy link
Contributor

divega commented Oct 7, 2018

@mlorbetske is now tracking this in his list. Clearing up fields to decide what to do with this issue.

@Rick-Anderson
Copy link

To work around this, you can set the environment variable before launching Visual Studio when publishing:

SET ASPNETCORE_ENVIRONMENT=Production
devenv

Or on the Properties > Debug debug tab set it

image

@GeorgeAlexandruD
Copy link

@rick

To work around this, you can set the environment variable before launching Visual Studio when publishing:

SET ASPNETCORE_ENVIRONMENT=Production
devenv

Or on the Properties > Debug debug tab set it

image

And? how do I change between environments? You can't just say "this is solution" but then not show how it works.

If I manually change the variable (ew!) then it stays changed no matter what mode I run visual studio in. Please be specific, and clear, in your answers. Also when writing @microsoft docs. We ain't all geniuses with 30 years experience.

@rick
Copy link

rick commented Oct 13, 2023

bladdow

@lkurzyniec
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants