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

Commands: Assembly-based Command Line Interface (ef.exe) #646

Closed
4 of 5 tasks
bricelam opened this issue Sep 10, 2014 · 9 comments
Closed
4 of 5 tasks

Commands: Assembly-based Command Line Interface (ef.exe) #646

bricelam opened this issue Sep 10, 2014 · 9 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement

Comments

@bricelam
Copy link
Contributor

bricelam commented Sep 10, 2014

Like dotnet-ef but with less project.json and more *.dll

A rudimentary version of this is available in the Microsoft.EntityFrameworkCore.Tools package (under the tools directory), but it is currently just an implementation detail of the PMC commands.

A few TODO items to make it generally useful:

@rowanmiller rowanmiller added this to the 1.0.0-rc1 milestone Sep 12, 2014
@bricelam bricelam changed the title [Beta Must Have] Migrations: Command Line Interface (ef.exe) Migrations: Command Line Interface (ef.exe) Sep 30, 2014
@bricelam bricelam modified the milestone: 1.0.0-rc1 Nov 25, 2014
@rowanmiller rowanmiller added this to the Backlog milestone Nov 26, 2014
@rowanmiller rowanmiller changed the title Migrations: Command Line Interface (ef.exe) Migrations: Command Line Interface (ef.exe) a.k.a non-DNX non-VS CLI Jul 24, 2015
@bricelam
Copy link
Contributor Author

bricelam commented Mar 8, 2016

We'll probably need a few different versions.

Executable Description
ef.clr AnyCPU, Full .NET
ef.clr.x86 32-bit, Full .NET
ef.coreclr CoreCLR

We could probably have just an ef driver that is smart enough to delegate based on the assemblies passed in.

With the driver, we could even hide the fact that there are multiple versions by packaging them into the driver and extracting them behind the scenes.

I wonder if we could use the fact that .NET Core unifies on Full .NET to our advantage in the architecture... Something like a single "portable" assembly that we run via the appropriate CLR/CoreCLR host.

@bricelam bricelam changed the title Migrations: Command Line Interface (ef.exe) a.k.a non-DNX non-VS CLI Commands: Assembly-based Command Line Interface (ef.exe) Mar 8, 2016
@bricelam bricelam modified the milestones: 1.1.0, Backlog Aug 11, 2016
@bricelam
Copy link
Contributor Author

bricelam commented Aug 11, 2016

(Pulling this into 1.1.0 since it is has become an implementation detail of #5334.)

natemcmaster pushed a commit that referenced this issue Aug 11, 2016
Issues:

 - Fix #646 - implements assembly-based command line interface
 - Fix #5273 - Split tools packages into .Tools.DotNet and .Tools.VisualStudio
 - Fix #5334 - Refactor cmdlets/dotnet-ef to invoke ef.exe/ef.dll
 - Fix #5684 - Use nuspec's instead of Sake
 - Fix #5839 - throw warning when architecture is not in {x86, x64, AnyCPU}

Other changes:

 - Add --no-color and --no-appdomain to command line tools
 - Add --json option to 'dbcontext scaffold' and 'migrations remove'
 - Refactor the inside-man invocation for Tools.DotNet to use "ef.dll" instead of invoking .Design.exe.
 - Add native powershell module for processing/forwarding streams
 - Reorganize code
    *  💔 break up DotNet and VisualStudio command line tools into separate packages
    * Push down execution logic dode from Tools.VisualStudio into .Design.
    * Lift code from .Design.Core to .Design
    * Reorganize test projects
    * Create a powershell only project for Tools.VisualStudio
    * Move tests into appropriate test projects and adjust namespaces
@natemcmaster natemcmaster added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Aug 12, 2016
@bricelam
Copy link
Contributor Author

bricelam commented Dec 14, 2016

--assembly always has to be specified. Does anyone think it should be positional instead?

# Current
ef migration list --assembly WebApplication1.exe

# Possible
ef migrations list WebApplication1.exe
ef database update WebApplication1.exe Migration7

Or is it too awkward when combined with sub-commands and other positional arguments?

@bricelam bricelam modified the milestones: 2.0.0, tools-1.0.0 Dec 16, 2016
@bricelam bricelam self-assigned this Jan 3, 2017
@bricelam bricelam modified the milestones: 2.0.0, tools-1.0.0, tools/1.0.0-msbuild3, tools/1.0.0 Jan 3, 2017
@bricelam
Copy link
Contributor Author

We've decided to leave --assembly as a named parameter.

@bricelam
Copy link
Contributor Author

I believe it's ready for prime time. I've filed dotnet/EntityFramework.Docs#328 to document it.

@bricelam bricelam added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jan 12, 2017
@andycmaj
Copy link

andycmaj commented Jul 4, 2018

hello... not understanding which versions --assembly is expected to work in...

i'm trying to run migrations on a published dll and --assembly doesn't seem to fix the missing project error:

(note that i'm using dotnet-ef.dll published along with my app because i added a PackageReference on <PackageReference Include="Microsoft.EntityFrameworkCored.Tools.DotNet" Version="2.1.0-preview1-final" />)

root@82332f775c88:/app# dotnet exec --depsfile KanbanLab.FrontEnd.deps.json --runtimeconfig KanbanLab.FrontEnd.runtimeconfig.json Microsoft.EntityFrameworkCore.Design.dll database update --assembly KanbanLab.FrontEnd.dll --startup-assembly KanbanLab.FrontEnd.dll --verbose --context KanbanContext

Unhandled Exception: System.MissingMethodException: Entry point not found in assembly 'Microsoft.EntityFrameworkCore.Design, Version=2.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Aborted
root@82332f775c88:/app# dotnet exec --depsfile KanbanLab.FrontEnd.deps.json --runtimeconfig KanbanLab.FrontEnd.runtimeconfig.json dotnet-ef.dll database update --assembly KanbanLab.FrontEnd.dll --startup-assembly KanbanLab.FrontEnd.dll --verbose --context KanbanContext
Microsoft.EntityFrameworkCore.Tools.CommandException: No project was found. Change the current working directory or use the --project option.
   at Microsoft.EntityFrameworkCore.Tools.RootCommand.FindProjects(String path, String errorWhenNoProject, String errorWhenMultipleProjects)
   at Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute()
   at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
   at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
No project was found. Change the current working directory or use the --project option.
root@82332f775c88:/app# dotnet exec --depsfile KanbanLab.FrontEnd.deps.json --runtimeconfig KanbanLab.FrontEnd.runtimeconfig.json dotnet-ef.dll --assembly KanbanLab.FrontEnd.dll --startup-assembly KanbanLab.FrontEnd.dll database update --verbose --context KanbanContext

                     _/\__
               ---==/    \\
         ___  ___   |.    \|\
        | __|| __|  |  )   \\\
        | _| | _|   \_/ |  //|\\
        |___||_|       /   \\\/\\

Entity Framework Core .NET Command-line Tools 2.1.0-preview1-28290

Usage: dotnet ef [options] [command]

Options:
  --version        Show version information
  -h|--help        Show help information
  -v|--verbose     Show verbose output.
  --no-color       Don't colorize output.
  --prefix-output  Prefix output with level.

Commands:
  database    Commands to manage the database.
  dbcontext   Commands to manage DbContext types.
  migrations  Commands to manage migrations.

Use "dotnet ef [command] --help" for more information about a command.
root@82332f775c88:/app# ef
bash: ef: command not found
root@82332f775c88:/app# dotnet dotnet-ef.dll
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/app/'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the /app/dotnet-ef.runtimeconfig.json file specifying the appropriate framework.
root@82332f775c88:/app# dotnet exec --depsfile KanbanLab.FrontEnd.deps.json --runtimeconfig KanbanLab.FrontEnd.runtimeconfig.json dotnet-ef.dll --assembly KanbanLab.FrontEnd.dll --startup-assembly KanbanLab.FrontEnd.dll database update --verbose --context KanbanContext

                     _/\__
               ---==/    \\
         ___  ___   |.    \|\
        | __|| __|  |  )   \\\
        | _| | _|   \_/ |  //|\\
        |___||_|       /   \\\/\\

Entity Framework Core .NET Command-line Tools 2.1.0-preview1-28290

Usage: dotnet ef [options] [command]

Options:
  --version        Show version information
  -h|--help        Show help information
  -v|--verbose     Show verbose output.
  --no-color       Don't colorize output.
  --prefix-output  Prefix output with level.

Commands:
  database    Commands to manage the database.
  dbcontext   Commands to manage DbContext types.
  migrations  Commands to manage migrations.

Use "dotnet ef [command] --help" for more information about a command.

@andycmaj
Copy link

andycmaj commented Jul 4, 2018

ended up snatching ef.dll from the package cache during my builds...

    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.1.0-preview1-final" />
    <Content CopyToPublishDirectory="PreserveNewest" Include="$(NuGetPackageRoot)microsoft.entityframeworkcore.tools.dotnet\2.1.0-preview1-final\tools\netcoreapp2.0\*.*" />

so now i can publish with ef.dll and this seems to actually work for migrations, rather than dotnet-ef.dll

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Development

No branches or pull requests

4 participants