Efcore: Allow namespace in code generated by tools to be specified on the command line

[chassq]

When using scaffold to write to a relative directory in the project the namespace of the target folder does not seem to be honored. For example:

dotnet ef dbcontext scaffold "Server=localhost\SQLEXPRESS;Database=<dbname>;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -c ApplicationDbContext --force --output-dir ..\lib.dal.sql\models

Note that we are writing to a folder of another project. However the namespace of the files created is that of the project namespace not of the folder. The namespace is in this case lib.dal.sql but should be lib.dal.sql.models

Steps to reproduce

Create a scaffold project but write the output to another directory in another project.

Further technical details

EF Core version: 2.0.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Win 10 latest patches
IDE: Visual Studio 2017 latest patches

[smitpatel]

Removing milestone as neither migrations nor scaffolding process any namespace when it is outside of your project directory. (not enough data to compute anything). We just use default namespace.

[ajcvickers]

After discussing in triage we are going to close this as by-design. The namespace resolution works correctly when generating to a location inside the project. When generating to locations that step out of the project (with "..\") it becomes ambiguous and error prone, so we just generate using the root namespace.

[chassq]

Ok, then please add a namespace override to the cmd line args. I assume since scaffold does not support NetStandard (according to the docs I think) we cannot target a NetStandard lib yet.

[smitpatel]

Co-assigned Brice for design.

[ajcvickers]

Note from triage: we will consider allowing the namespace to be specified on the command line. @bricelam to make some proposals.

[bricelam]

Note, we should do this for both Add-Migration and Scaffold-DbContext.

[darkguy2008]

So, is this done? I'm having an issue where my app's directory is "api-users" and it tries to make the namespace as "namespace api-users.Models" which obviously doesn't work and crashes everywhere.

[ajcvickers]

@darkguy2008
This issue is in the Backlog milestone. This means that it is not going to happen for the 3.0 release. We will re-assess the backlog following the 3.0 release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[bricelam]

@darkguy2008 See also dotnet/sdk#1564

[ErikEJ]

EF Core Power Tool offers full control of file locations and namespaces.

[Felza]

@ErikEJ Great tool! This fixed my issue, thanks!
Though I would like to add a comment to the "full control of namespace". Your tool offers the option to control sub-namespaces, but not the option for different root namespace.

[ErikEJ]

I think you have full control if you generate Entity Classes and DbContext separately

[atrauzzi]

Just duplicating my observation from the other issue: Having a Visual Studio specific tool doesn't cover my situation where I'm using .net Core from command line and in linux. Also, relying on Visual Studio addins for functionality does frustrate automation scenarios.

Even if at the very least, forcing people to now include all of VS in their builds. Which isn't possible if they're building on linux.

[darkguy2008]

Okay so we already have .NET Core 3.x, as @ajcvickers said it was on the backlog, so it would be safe to assume it's been done, right? Otherwise this issue wouldn't be open still...

Agreed with @atrauzzi , the problem with all these opensource software is that bugs or features stay open for years and years without any progress unless it directly affects an official developer someday...

[ajcvickers]

@darkguy2008 What specifically makes you think this has been done? (It's open and in the 5.0 milestone.)

[darkguy2008]

@ajcvickers "We will re-assess the backlog following the 3.0 release and consider this item at that time.".

Unfortunately the priorities, again as I said, are not on the end user's needs. A bug/request that's been open for 3 years is enough proof.

[atrauzzi]

@ajcvickers - I've pushed a lot of GitHub suggestions in the past for things that don't present as "popular" through GitHub tickets.

The people here aren't going to be fully representative of demand. I think the better argument here is consistency and aligning with the overall direction of Microsoft tools. The lack of a cross platform, command line equivalent here, accompanied by suggestions to use a VS-only workaround is a bit...off, don't you think?

If I wear my PM hat, something tells me that once built, this will be used and very widely appreciated.

[ajcvickers]

@atrauzzi This is why we have a planning process that considers many factors, not just the number of votes. That being said, there are currently 114 issues with more votes than this one. So while cross-platform tooling is strategically important to Microsoft, this particular issue is still pretty far down the priority list, especially for a small team.

[atrauzzi]

Who do I have to tweet at for you guys to get more resources? 😉

You're like...the 2nd most important .net Core project in the ecosystem IMO!?

[ErikEJ]

@atrauzzi I am planning a .NET Core command line tool that does what the VS extension does (in terms of generating scaffolding code)

[ErikEJ]

You can vote here: https://github.com/ErikEJ/EFCorePowerTools/issues/340

[bricelam]

Related: #3988

[darkguy2008]

This is awesome, thanks a lot for your hard work!!! :D

[lajones]

@darkguy2008 You're very welcome :-)