"Apply this migration on publish" option missing from Azure Publishing profile

[divega]

According to https://github.com/aspnet/Tooling/issues/988#issuecomment-277859310 this still repros on the latest publically available build of VS 2017 as of Feb 2.

From @Banashek on December 20, 2016 2:35

I initially created a new dotnet core mvc application in VS2017 using steps similar to the steps found here: https://docs.microsoft.com/en-us/aspnet/core/tutorials/publish-to-azure-webapp-using-vs

There is an image on that page (found here: https://docs.microsoft.com/en-us/aspnet/core/tutorials/publish-to-azure-webapp-using-vs/_static/pubs.png) that shows the ability to apply migrations on publishing.

I have lost that checkbox, along with the "Databases" and "Entity Framework Migration" arrow-drop-down menus (I still have the File Publish options).

I'm not sure how to troubleshoot this. I've looked up the issue and found a few resources:

• http://stackoverflow.com/questions/19664459/execute-code-first-migrations-checkbox-disappeared-from-my-publish-profile
• http://stackoverflow.com/questions/16543229/publish-entity-framework-code-first-migrations-with-no-context-in-the-startup-pr?answertab=active#tab-top
• https://msdn.microsoft.com/en-us/library/dd394698%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

However, I haven't found a solution and am not sure of what exactly makes these options appear in the publishing profile.

Is there any current (1.1.0 is pretty new, so i understand if not) documentation on this feature?

If not, is there someone who might be able to point me in the right direction to get this solved? It was completely unexpected that this would stop working in production.

Thanks

Further technical details

EF Core version: 1.1.0 Database Provider: Microsoft.EntityFrameworkCore.SqlServer Operating system: Windows 10/Azure IDE: Visual Studio 2017 RC

Copied from original issue: aspnet/EntityFramework#7276

[divega]

From @Banashek on December 20, 2016 18:20

Ok it looks like this is a known issue:

https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md#migrations-not-applied-during-publish

So how would I go about manually applying these migrations?

Since I'm using the new project type with vs2017 (no dotnet ef commands), I'm not sure the best way to do it.

I was told there used to be a -Script option to output a script, but it doesn't look like this option is available from the package manager console.

[divega]

From @Banashek on December 20, 2016 23:13

So it looks like i missed a command that's available in the package manager called Script-Migration.

Using this command along with manually running the output against the azure sql instance allows me to continue working for now.

Is there any information on when the visual studio tooling issue might be fixed? It's not directly an issue for this repo, but this seems like the best place to ask.

[divega]

@balachir do you know if the issue in the known issues list is fixed?

[divega]

From @chadwackerman on February 3, 2017 3:36

@divega Issue still happens on the Latest VS 2017 as of yesterday. Please reopen this.

[divega]

From @punkouter on February 6, 2017 20:33

Yes. Just found this. So I guess I need to manually run the script on the azure db using Script-Migration until it works ?

[divega]

From @chadwackerman on February 6, 2017 21:58

Bug status:

• no one assigned
• closed for no reason
• nobody responding

Further evidence that attempting projects of this scale on GitHub does not work well. Without exception every Microsoft bug I stumble upon is mismanaged. @rowanmiller

[divega]

@chadwackerman this was intentionally closed as external because it is not an EF Core issue but a tooling issue and the original poster pointed out it was already accounted for in the known issue list at https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md#migrations-not-applied-during-publish.

Thanks for letting us know that it still repros. I will move it to the right repository.

[mlorbetske]

@vijayrkn could you take a look please?

[vijayrkn]

@chadwackerman @Banashek @punkouter In VS 2017 RC, we have added the ability to apply migrations from VS publish UI. Please make sure that the csproj has reference to this CLI tool

<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

Also, can you verify if the dbcontext is getting printed, when you execute this command from the project root?

dotnet ef dbcontext list --json

The entry point for the settings page has changed in the recent release. You can click on settings link to get to the Settings dialog.

To manually apply migrations as part of publish, you can add the migration section listed here to the pubxml https://github.com/aspnet/websdk

[chadwackerman]

It was a .json based project imported using RC 3. It created the following line instead:

<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />

With a matching version number in the package:

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.0-preview4-final" />

That worked in VS 2015. Why has the version number dropped from 1.1 to 1.0?!

Edit to tag @vijayrkn and clarify that "Discovering data contexts..." now spins for a bit but does indeed find the dbcontext when I replace the 1.1 build with the 1.0 build.

[vijayrkn]

Support for msbuild was added to this this version 1.0.0-msbuild3-final, So you will have to change the version of DotNetCliToolReference to 1.0.0-msbuild3-final.

<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

& Package reference to

    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.0.0-msbuild3-final" PrivateAssets="All" />

[chadwackerman]

Per above I did that and it indeed worked. I'm just curious as to how tools are going to be able to do that since I was running version 1.1 yet the fix is 1.0.

I brought everything up to date. Didn't work. Then checked the pre-release box and tried again. Still nothing. So I wound up here. But I'm not sure version management via GitHub comments scales to the entire ecosystem.

Am I missing something here?

[vijayrkn]

If you are using netcoreapp1.1, then you can use 1.1.0-msbuild3-final for Package reference.

    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.0-msbuild3-final" PrivateAssets="All" />

/cc @prafullbhosale

[chadwackerman]

Where are these packages/tools published? Should the feed be added to the RC?

[vijayrkn]

https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.Tools/1.1.0-msbuild3-final

[chadwackerman]

If search NuGet it says my build is the latest version and yours is not. Does it sort by name, not date of release, and "-preview4-final" is >= "-msbuild3-final"?

Oh good lord. I just updated packages and it overwrote yours.

Yet another reason for you guys to stop playing so fast and loose with version strings.

[prafullbhosale]

Does it sort by name, not date of release, and "-preview4-final" is >= "-msbuild3-final"?

Yes, these follow semantic versioning. The decision to version these packages as msbuild* was deliberate in order to make it easier for identify that these versions support MSBuild projects.

The upcoming release for these packages should resolve the versioning problems.

[chadwackerman]

@prafullbhosale You do realize that if I "update to latest" and it does not bring down the latest, then the "semantic" part of "semantic versioning" is void, yes?

Version number is not a place to "label" things.

cc: @robertmclaws

[chadwackerman]

We need to have a SERIOUS discussion about NuGet and the total insanity that is going on with versioning. @prafullbhosale @maartenba @vijayrkn

I feel like I need a CSS !important flag so I can tell the tools to stop screwing me over. And when CSS is the inspiration, we've clearly lost the rabbit here.

Restoring NuGet packages...
Dependency specified was Microsoft.EntityFrameworkCore.Tools.DotNet (>= 1.1.0-msbuild3-final) but ended up with Microsoft.EntityFrameworkCore.Tools.DotNet 1.1.0-preview4-final.

[mlorbetske]

Hi @chadwackerman, we know the current versioning story is not in a good place & are working to improve it. This will get better soon with the move not have build quality indicators (which, as you've pointed out, have been incorrectly used for labels). If you wish to discuss versioning, it would probably be best have the discussion in an issue dedicated to that topic so that it gets better visibility.

Given that the original issue you were experiencing is resolved with the use of the appropriate package versions, I think we should close this issue. Do you agree?

[chadwackerman]

I'm not sure the bug is resolved, however I have performed a migration. Do what you gotta do.

Stuff like this really shouldn't be happening in 2017.

[mlorbetske]

I may be misunderstanding then, apart from the issue where the packages don't follow semantic versioning correctly, are you still running in to trouble with this?

When you feel that the issue of not being able to apply migrations on publish is resolved, please close this issue. Until then, please continue to let us know what you're running in to with this scenario so we can help.

[mlorbetske]

Ah, I see the issue in your most recent post now. The version has been pulled "up" to preview by something else. Does your project reference any other projects that also depend on that package (possibly with the wrong version)?

[chadwackerman]

I understand what's happening on my side. I guess I'm not convinced that Microsoft understands what's happening on its side.

Last summer I installed an RC of .NET Core (that wasn't close to a RC) to help you out. Then I installed some more stuff to help you out after you rebooted that effort. And then I played ping pong with project formats while you figured those out. And just when things started to seem sane, I installed RC 3 of Visual Studio 2017 and it's overwriting the tools I need ... uh ... to help you out.

Screwing up versioning and process this badly undermines the most important driving factor of any open source project: informed people who install things, get even more informed, and therefore provide useful feedback. The way Microsoft fumbles through their GitHub work across projects is not just chaotic, unprofessional and wasteful, it's also fundamentally disrespectful to the people who are trying to help you make this stuff better.

It would seem that something could be done in this very issue -- like bumping to 1.1.1 from 1.1.0 in order to let people validate the tooling as part of the beta/RC/whatever you call a non-feature complete release these days. But I suppose that just breaks other people if NuGet isn't smart enough to allow targeting a package change to a specific project format or Visual Studio version.

But really... how exactly did we get here? And how has NuGet remained such an obvious piece of crap given the fact that so many issues keep pointing back to it as a choke point?

Microsoft borked the main Http component for the system -- System.Net.Http -- and hasn't been able to ship a fix for a sev1 there for over six months (https://github.com/dotnet/corefx/issues/11100). Trying to help by updating that 186k DLL results in NuGet downloading hundreds of megabytes of .json (!) then crashing when Visual Studio runs out of memory trying to parse it (https://github.com/NuGet/Home/issues/4448). That process takes over 11 minutes of wall clock time on a 8 core machine because it's pulling bits from an overloaded server in Belgium run by a company called "Tech Tomato."

This is how the .NET team develops all day every day?

I was a senior Microsoft dev manager over some pretty massive technology efforts and I've never seen a mess as big as the one going on right now in .NET.

I'll assume people are aware of the problem and doing what they can. Despite the fact that I have been unable to find even a single whiff of evidence supporting that view.

You may now close this bug, improve your GitHub internal reporting metrics, and get on with your day. Bonus points if you forward the relevant parts of this rant to someone internally who isn't completely fried as part of this horribly-mismanaged release cycle.

[mlorbetske]

@chadwackerman I'm not trying to close the issue or be dismissive, I'm trying to keep it focused on the stated problem so that other people with the same problem can discover it and benefit from the solution rather than changing the topic.

Since I don't know how to accurately sum up all of the experience issues you've run in to, I've not opened another issue on your behalf to track those things - please e-mail me at mlorbe at microsoft dot com so we can work together to raise awareness with the right folks. Hopefully the result of that will be one or more GitHub issues dedicated to these things so that others can contribute their experiences as well.

[chadwackerman]

I didn't take your comments as dismissiveness, you did great. And yes, close this bug!

But, yeah... the broader problems here not only manage to violate every possible versioning standard but also every modern open source/open development best practice as well (ship often, principle of least surprise, gamify so that participation is rewarding not endlessly frustrating).

The package manager is an embarrassment. People don't seem to know what alpha, beta or release candidate means any more. Versioning is absolutely absurd. Coherent docs are nowhere to be found. And testing has been pushed to the community yet the tools can't deliver the bits and the outsourced community software (GitHub) obviously doesn't scale to an effort like this.

The solution is NOT to create a new sub-issue every time something wanders off from the subject line. Or politely inviting someone to contact you off-list. That doesn't scale, it just feels better. We learned this in the 90s in open source.

It just buries the problem further. A complex system like .NET does not map into a tidy list of curated hierarchies tagged by a color-coded folksonomy using a cutesy web interface. That didn't scale to knitting blogs in 2005 and it's long since failed trying to triage .NET in 2017.

It does give the Microsoft people who pull the strings here just enough flexibility to hang themselves and I'm tired of getting caught up in the rope.

[rlogwood]

@mlorbetske i'm not sure why you closed this issue as the problem is still present for me. Following the instructions posted by @vijayrkn do not fix the problem for me in VS2017 RC. Did you open a new issue for this problem?

I followed @vijayrkn instruction to install https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.Tools/1.1.0-msbuild3-final however I had to manually update the csproj file.

I used the script-migration command and manually updated the server to move forward. There appears to be no support in VS2017 RC for doing migrations on publish even after following the recommendations in this thread from @vijayrkn.

I think it could help if there was a quality control team working to keep rich example projects working as new versions are rolled out. The current reality is a lot of time is required to try to get things to work and to find answers to questions when they don't.

My csproj file and VS2017 RC version information are both shown below for your reference:

Project csproj file

<Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net452</TargetFramework>
    <PreserveCompilationContext>true</PreserveCompilationContext>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
  </PropertyGroup>
  <PropertyGroup>
    <UserSecretsId>hidden</UserSecretsId>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System.ComponentModel.DataAnnotations" />
    <Reference Include="System.Data" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Diagnostics" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Routing" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Server.IISIntegration" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Session" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.0" />
    <PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="1.1.0" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink.Loader" Version="14.1.0" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="1.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.0-msbuild3-final" PrivateAssets="All" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="1.1.0" />
    <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="1.0.0-msbuild3-final" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
    <DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="1.0.0-msbuild3-final" />
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
  </ItemGroup>
</Project>

VS2017 RC Version Information

Microsoft Visual Studio Enterprise 2017 RC
Version 15.0.26127.3 D15SVC
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Enterprise

Visual Basic 2017 RC   00369-50000-00000-AA085
Microsoft Visual Basic 2017 RC

Visual C# 2017 RC   00369-50000-00000-AA085
Microsoft Visual C# 2017 RC

Application Insights Tools for Visual Studio Package   8.5.10109.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2016   15.0.30124.0
ASP.NET and Web Tools 2016

ASP.NET Web Frameworks and Tools 2013   5.2.50105.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v2.9.6   15.0.30118.0
Azure App Service Tools v2.9.6

Azure Data Lake Node   1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio   2.2.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

KofePackagePackage Extension   1.0
KofePackagePackage Visual Studio Extension Detailed Info

Microsoft Azure Hive Query Language Service   2.2.5000.0
Language service for Hive query

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio vNext - v2.9.41216.2

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Node.js Tools   1.3.41102.00
Adds support for developing and debugging Node.js apps in Visual Studio

Node.js Tools - Profiling   1.3.41102.00
Profiling support for Node.js projects.

NuGet Package Manager   4.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

SQL Server Data Tools   15.1.61701.181
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript   2.1.5.0
TypeScript tools for Visual Studio

[chadwackerman]

@rlogwood try installing Microsoft.EntityFrameworkCore.Tools 1.0.0-msbuild3-final

Per another thread it's apparently the same bits. But for some reason the 1.1.0 version pulls 1.1.0-preview4 here. I think a package somewhere is missing a preview bit.

[vijayrkn]

@rlogwood Can you please try updating the VS to the latest version (15.0.0-RC.4+26206.0)?

If you are still not able to see the EF migration section after updating to RC.4, can you please share the output of the following command?

dotnet ef dbcontext list --json 

[rlogwood]

Hi @vijayrkn, Before posting my comment I made sure my VS2017 RC was up-to-date. I have installed every update when prompted by the VS2017 RC notification. I included the VS2017 RC version information shown on my install in my comment above. Does it not correspond to what one would see when installing the latest from https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes#feb7 ? Thank You

[vijayrkn]

In your comment, the VS version is mentioned as 15.0.26127.3. This was the release from January 27, 2017 (build 26127.00).

The latest update on feb7 should have the build number 26206.00. Can you please try updating to https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes#feb7 ? Thanks

[rlogwood]

Hi @vijayrkn, I did run the update for Feb 7 when prompted from VS2017 RC, but I guess it did not work as expected or I made a mistake. I will try to do this again and update you with the results after confirming the version :) Thank You for the help!

[rlogwood]

Hi @vijayrkn , In order to try out your recommended steps I had to setup a new VM with a new fresh install of VS2017 RC to get build 26206 installed. Doing this and the test below took time given my schedule, sorry for the delay.

The new VS2017 RC version did not solve my problem. After investigating, I saw that the Azure instance had gotten too out of sync with the development version (in the course of restarting development with new ASP.NET Core versions, the migrations on my development machine were different from the remote Azure SQL Server).

To solve this problem, I ended up dropping both the local development database and the Azure SQL Server database (which could only be done for a project still in development). My reason for doing this was to create a blank slate for EF Core to apply the migrations.

I have two DbContexts, the standard IdentitySchema created when you use individual accounts with the ASP.NET core template and another for my model objects. I created a migration for both of these contexts and applied them. The local DB was recreated and my application tested fine there. However, when publishing I could not find any way to apply the migrations on my local machine to the remote Azure SQL Server DB instance.

I tried scripting the migration (Script-Migration), but since the resulting script did not create the database, I did not use that script (command: PM> script-migration -from 0 -to CreateIdentitySchema -Idempotent -Context ApplicationDbcontext).

In order to create the remote DB I changed the DefaultConnection in my appsettings.json file to point to the remote database and ran the update-database command for both of my data contexts. Doing this recreated my remote database and the schema. I had to republish my application to get it working again.

Unfortunately I didn't realize I had the error described in this comment 284275427 in my csproj file. Please review comment 284275427.

So if I had made that fix sooner, perhaps the initial republish would have worked. It would be great if the tooling links updated automatically to be in sync with the Nuget dependencies. It looks to be a manual process now.

From this experience, I think it would help if to have (assuming there are none) scripted test scenarios for deployments from VS2017 that include EF migrations for many different use cases, such as: (1) creating the DB for the first time, (2) applying multiple migrations for multiple DbContexts, (3) applying migrations for a target DB that cannot be created from the available local migrations, because things are out of sync (this should give the developer a good error message and suggested remedy), (4) Updating to a new version of EF Core and having publish migrations work. I'm sure you guys can think of many other needed test cases.

You can find my current VS2017 version information below.

Thanks in advance for your help.

Microsoft Visual Studio Enterprise 2017 RC
Version 15.0.26206.0 D15REL
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Enterprise

Visual Basic 2017 RC   00369-50000-00000-AA238
Microsoft Visual Basic 2017 RC

Visual C# 2017 RC   00369-50000-00000-AA238
Microsoft Visual C# 2017 RC

Application Insights Tools for Visual Studio Package   8.6.00201.7
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017   15.0.30206.0
ASP.NET and Web Tools 2017

ASP.NET Web Frameworks and Tools 2017   5.2.50127.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   15.0.30126.0
Azure App Service Tools v3.0.0

Azure Data Lake Node   1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio   2.2.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

KofePackagePackage Extension   1.0
KofePackagePackage Visual Studio Extension Detailed Info

Microsoft Azure Hive Query Language Service   2.2.5000.0
Language service for Hive query

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.50131.1

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Node.js Tools   1.3.50201.08
Adds support for developing and debugging Node.js apps in Visual Studio

NuGet Package Manager   4.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Redgate ReadyRoll   1.13.21.3064
Extend DevOps processes to your SQL Server databases and safely automate database deployments.

Visit https://www.red-gate.com/readyroll for more information.

Copyright (C) 2011 Red Gate Software Ltd. All rights reserved.

This software contains components from Component Owl.
SQL Server is a registered trademark of Microsoft Corporation. 
Visual Studio is a registered trademark of Microsoft Corporation. 

ReadyRoll contains code from the following open source software:

NuGet https://www.nuget.org/
SQL LocalDB Wrapper https://github.com/martincostello/sqllocaldb
Autofac https://autofac.org/
Json.NET https://json.net/
MahApps.Metro http://mahapps.com/
SemVer https://github.com/maxhauser/semver
Menees Diff Controls http://www.menees.com/
Log4Net http://logging.apache.org/log4net/
Extended WPF Toolkit https://wpftoolkit.codeplex.com/
Code InfoBox VSX http://www.codeproject.com/Articles/55196/Code-InfoBox-Visual-Studio-Extension-VSX
OctoPack https://github.com/OctopusDeploy/OctoPack
SQLite https://sqlite.org/

This product contains icons from http://www.visualpharm.com distributed under a free backlink license.

For license details or other notices relating to the above software, please see NOTICE.TXT and EULA.rtf in the ReadyRoll application folder.

Redgate SQL Prompt   7.4.0.464
Write, format, and refactor SQL effortlessly

SQL Server Data Tools   15.1.61701.270
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript   2.1.5.0
TypeScript tools for Visual Studio

[rlogwood]

Hi @vijayrkn, Running the command ef dbcontext -list --json initially let to this error Couldn't read metadata for project '(mypath).csproj'. Ensure the package 'microsoft.EntityFrameworkCore.tools' is installed.

However, after updating the following entries in the csproj file to msbuild3 things seemed to work:

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />  
    <DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="1.0.0-msbuild3-final" />
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
  </ItemGroup>

Now ef dbcontext -list --json returns the expected result:

Time Elapsed 00:00:04.13
[
  {
     "fullName": "MyProject.Data.ApplicationDbContext",
     "safeName": "ApplicationDbContext",
     "name": "ApplicationDbContext",
     "assemblyQualifiedName": "MyProject.Data.ApplicationDbContext, MyProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
  },
  {
     "fullName": "MyProject.Data.MyDbContext",
     "safeName": "MyDbContext",
     "name": "MyDbContext",
     "assemblyQualifiedName": "MyProject.Data.MyDbContext, MyProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
  }
]

It now looks like the publish operation should succeed as expected:

Is there anyway to update the tools other than manually editing the csproj file? When I initially looked at the dependencies after the re-install of VS2017 RC R4, I missed the manual fix that I had previously done to the csproj file and was fooled by this output from the nuget dependencies:

[AtronSeige]

Create a appsettings.json file with a ConnectionStrings property.