Unable to create a constant value of type 'Anonymous type'. Only primitive types ('such as Int32, String, and Guid') are supported in this context.

Question

Can anyone tell me what I am doing wrong here?

var query = from a in bwm.Approvals
.Where(p => p.ProcessId == activity.ProcessId)
join h in activity.Histories
.Where(h => h.ActivityHistoryStatusID == (int)Status.Approved)
.OrderBy(o => o.ModificationDateTime)
.GroupBy(g => g.ModifiedByUserId)
.Select(s => new
      {
        ApprovalUser = s.Key,
        ApprovalDate = s.FirstOrDefault().ModificationDateTime
       })
on a.UserId equals h.ApprovalUser into approvalHistories
from i in approvalHistories
select new ApprovalView
  {
  User = a.User.Name.FirstName + " " + a.User.Name.LastName,
  UserId = a.UserId,
  ApprovalDate = i.ApprovalDate
  };
return query.ToList<ApprovalView>();

I am getting this runtime error: Unable to create a constant value of type 'Anonymous type'. Only primitive types ('such as Int32, String, and Guid') are supported in this context.

 

Answer 1

Hello,

Please check if all the types in your query is Scalared. There is a know issue in linq-to-entities: referencing non-Scalar variables are not supported: http://msdn.microsoft.com/en-us/library/bb896317.aspx#RefNonScalarClosures. Also, please provide us more information about your query.

Thanks a lot!

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!

Answer 2

Does anyone have any clever workarounds to this known issue? I'd really like to hand in arrays of objects to query against that are more complex than string[]. Its about as limiting as only allowing tables with one column...

I'd even be open to reformating of the query to support this but I can't wrap my head around that either...

 

 

 

Answer 3

Does anyone have any clever workarounds to this known issue? I'd really like to hand in arrays of objects to query against that are more complex than string[]. Its about as limiting as only allowing tables with one column...

I'd even be open to reformating of the query to support this but I can't wrap my head around that either...

Yes, a workaround would be nice. This limitation is seriously killing me.