Ef6: Entity Framework update from database regenerates all types with a superfluous namespace

[vsfeedback]

VSF_TYPE_MARKDOWNOur EF code is inside of a VB.net Class Library
The root namespace is "DataLibrary"

In various projects, we reference our EF data types like so
DataLibrary.SomeType_result

Everything works in 2017

In 2019, however, version 16.1.1, the EF types are regenerated and wrapped in Namespace DataLibrary, thus breaking all of the references, because now it is looking for DataLibrary.DataLibrary.SomeType_result

If I undo the changes and try again in 2017, no extra namespace is generated.

I can modify the .tt files to remove the extra namespace declaration, but I do not understand why this was added in the first place. We have over a dozen models, and now we need to either roll back to 2017, or update the .tt files to remove the superfluous namespace.

I am curious though. The .tt files seems to be the same. So why does 2017 not generate them? Could this actually have been a bug in 2017 and they are generating correctly in 2019? I'm confused.

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/589217/entity-framework-update-from-database-regenerates.html
VSTS ticketId: 902147_
_These are the original issue comments:_

ebutler on 5/30/2019, 07:47 AM (28 days ago): Ok, after a little more digging, I realize it is pulling from Custom Tool Namespace. But this property is intentionally left blank. When I enter something, it generates that namespace. If I blank it out, it generates the namespace from my Root namespace. It should not be generating anything if blank
Visual Studio Feedback System on 5/30/2019, 08:31 PM (27 days ago):

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Visual Studio Feedback System on 5/30/2019, 10:30 PM (27 days ago):

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017#faq . In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/ . We'll keep you posted on any updates to this feedback.

_These are the original issue solutions:_
(no solutions)

[lajones]

@bricelam Assigning to you to take a look. Note: both feedback tickets which have reported this seem to have VB projects.

[pedromcrocha]

because i dont use Custom Tool Namespace, i edit "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes\EF6.Utility.VB.ttinclude"

and comment some lines, now work as expected (like in vs 2017)

Public Function VsNamespaceSuggestion() As String
'Dim suggestion As String = _textTransformation.Host.ResolveParameterValue("directiveId", "namespaceDirectiveProcessor", "namespaceHint")
'If String.IsNullOrEmpty(suggestion) Then
Return Nothing
'End If 'Return suggestion
End Function

[Rufistofeles]

I'm also experiencing this issue in a VB.net project.

[dschoeneborn]

Same problem here

[foobarred1]

Ditto!

[TimesliceTechnologies]

Microsoft / EF6 really don't seem to understand the impact this has on existing EF6 / VB.NET applications. In VS2019 (I'm using the latest, 16.4.5) The code generating wraps every EF6 class and context with a namespace that all prior VS did not (IE: VS2017, VS2015 etc.) the result is that everything that references the library is BROKEN. VB.NET has an implicit namespace. When EF6 generates the code, the generated class and contact now double the namespace. EG: in VS2017, the class's namespace might be MyData, and EF6 classes would be MyData.Customer. In VS2019, those classes become MyData.MyData.Customer. For large applications or applications that reference a common data layer there is no simple way to address this. It is necessary to comb through everything that references those objects. The potential to break applications is HUGE. Surely it's not difficult to simply recognize I'm generating for VB.NET, use the same behavior at VS2017. IE: DO NOT BREAK things. This issue has been ongoing for literally 1 year with VS2019. The workarounds are basically, edit the TT files, Temporarily remove the default namespace in project while generating / updating the EDMX, or ultimately comb through every application and modify code (probably breaking a lot of stuff). This isn't some minor inconvenience or tiny regression. How about fixing the problem and restoring the behavior we've relied on for about 8 years or more? I have terabytes of code - VS2019 is otherwise fantastic - but this is a BIG problem for those of us in the VB.NET world.

[alangori]

I am having the same problem, does anyone know if they will be fixing this?

[lajones]

The underlying issue has been tracked down to a text templating issue tracked here.

There is a workaround posted here which resolves the UpdateModel issue but has side-effects on any other code you have in that project.

[TimesliceTechnologies]

The thread referred to in the comment by lajones suggests this was a "bug" in VS2017 that VB.NET developers had relied on. In my opinion the problem that was "fixed" in VS2019 in fact did not FIX a non existent problem. In fact, there was no "bug" in VS2017 in my view. VS2017 properly understands that the namespace is inferred.

It appears to me that VS2017 and prior versions of VS in fact worked correctly and did NOT introduce a namespace to each generated class if one was not specified in the TT files. Fundamentally, VB.NET Infers the namespace when none is specified. That's the typical behavior we expect in VB and what EF6 / VS2017 and prior versions would generate by default.

I suspect that the folks that worked on the changes for VS2019 may have been focused on C#, or possibly were not entirely familiar with the subtle difference between VB and C# with respect to namespace behavior.

For those of use with HUGE applications, or class libraries that other applications rely on this is truly a gargantuan issue to deal with. The response from MS to date has been underwhelming on prior tickets as well as the one I initiated which I believe is currently "under consideration".

For those of us working with EF, this is a very significant problem with VS2019 / EF6 that needs to be resolved so that we can move on to what is otherwise an excellent new version of VS.

And the fact is, it seems that this should be a trivial problem to address. IE: When generating for VB.NET, simply do not wrap the generated classes in a namespace unless one is specified. How hard can that be?

[TimesliceTechnologies]

Here's a link to the same issue I submitted in Feb 2020 to MS develoepr community. You may want to add your request for a fix / comment on that ticket:
https://developercommunity.visualstudio.com/content/problem/926951/vs2019-vbnet-ef6-generates-doubled-namespace-on-ge.html

[lajones]

A fix for this - taking us back to the previous functionality - has been implemented and is set to ship in the 16.6 preview 2 release of VS. Sorry about the long wait. We are tracking this in the developer community issue referenced above - so please see there for any further updates.

[TimesliceTechnologies]

Can you provide an approximate ETA for release of when 16.6 preview 2 ? I see the preview release as of Mar 12, 2020 is only at 16.5 preview 5. We need to make some contingency plans here until a fix is available. An approximate ETA would be most helpful.

[ErikEJ]

@TimesliceTechnologies use VS 2017?

[ajcvickers]

@TimesliceTechnologies I don't think I can share the dates for Visual Studio publicly, but you should hear some news very soon.

[TimesliceTechnologies]

@ErikEJ - As a workaround we are indeed using VS2017 when updating EDMX, then reloading in vs2019.
@ajcvickers - thanks for the news. That is encouraging.

[lajones]

@TimesliceTechnologies FYI - the 16.6 Preview 2 release of VS shipped today and has this fix in it.

[TimesliceTechnologies]

Thanks for the notification. I'll pickup the preview and give it a test run.