CODEWITHSUNDEEP
c#entity-frameworkdebugginglambdavisual-studio-2017
Marcus Vinicius Pompeu
Marcus Vinicius Pompeu

Reputation: 1261

Visual Studio 2017 on Windows Server 2016 - Cannot inspect lambda LINQ expression on debugging

I hit a very serious fault when debugging a C#, Entity Framework, application.

The evaluation of a LINQ for Entities lambda either on Watch or Inspect windows yelds: Evaluation of method System.Linq.Enumerable.ToList() calls into native method System.Diagnostics.Debugger.get_IsAttached(). Evaluation of native methods in this context is not supported.

This occurs in a, just built from scratch, development Windows Server 2016 VM with Visual Studio 2017 Enterprise. All settings defaulted.

Getting back to an ol'n'gold Windows 2012 VM, same VS, same settings, the fault reoccurs.

The (actually not the very) faulty code's snippet bellow:

enter image description here

Has anyone there a hint on the problem?

This has to be related to EF, maybe to SQL drivers, or IIS process attachment space.

I've devised a simple scenario with lists and lambda and found no problems:

enter image description here

Upvotes: 2

Views: 595

Answers (1)

Marcus Vinicius Pompeu
Marcus Vinicius Pompeu

Reputation: 1261

OK, I gottit: VS Web Host shan't yield the result of a parameterized LINQ for Entities to the Visual Studio IDE's Immediate/Watch windows whenever a DB access is involved.

Such evaluation yields calls into native method System.Diagnostics.Debugger.get_IsAttached() ... in this context is not supported.

In my understanding that's because of DB accesses rely on calls to unmanaged code from SYS drivers.

I'm sure there shall be a set of tweaks on the Source Project, VS Debug, VS Web Hosting, and host IIS Pool settings that circunvent this.

But I could not devise them, either exploring the IDE settings neither googling for it.

So, as I still had a troubleshooting at hand, instead of trying to evaluate something like

BaseContext.DbContext.Set<SupMedResult>()
    .Where(r => r.CPF == "58243143149")
    .ToList()

I otherwise casted

BaseContext.DbContext.Set<SupMedResult>()
    .ToList()
    .Where(r => r.CPF == "58243143149")

The way I see this:

  • the first approach reached EF decision branches envolving DB schema queries (for graph mapping)
  • the second approach rendered a single straight-forward full table fetch

(why a full table fetch did not hit any native method? I dunno!)

There forth I was able to do my fiddles and devise where the query was mistaken.

By the way, the actual query was way, WAY, more complex than the one I used in the question and this answer.

Upvotes: 3

Related Questions