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.

[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: ErikEJ/EFCorePowerTools#340

[bricelam]

Related: #3988

[darkguy2008]

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

[lajones]

@darkguy2008 You're very welcome :-)