пофиксил такой баг (копипаста из коммента по задаче):
первичная проблема: вызывается SaveChanges датаконтекста внутри foreach'а, перебирающего IEnumerable-результат запроса из БД (без использования ToList) через этот же датаконтекст. из-за этого вылетает исключение. несколько коммитов назад такого не было, код, выбрасывающий исключение, никто не трогал.
обнаружил такую причину этой проблемы: при выполнении партиал-действия (RenderAction) создается отдельный экземпляр контроллера для этого внутреннего действия. так вот, на ~старом коммите DI (Unity) при конструировании экземпляров контроллера в рамках одного HTTP-запроса каждый раз предоставлял (в качестве зависимости конструктора) отдельный экземпляр дата-контекста, не смотря на то, что в UnityConfig соотв. интерфейс зарегистрирован с PerRequestLifetimeManager.
однако в ~новом коммите создание дата-контекста происходит так, как и должно происходить при PerRequestLifetimeManager: во все экземпляры контроллера передается один и тот же экземпляр дата-контекста. из-за того, что это поведение выправилось - и появилась описанная ситуация с SaveChanges, и стало вылетать исключение :)
предполагаемая причина - переход на новую версию Unity (и, в частности, PerRequestLifetimeManager)
нет гарантии, что подобная проблема не появилась и в других местах. в идеале, чтоб исключить подобные ситуации, нужно , чтоб за пределы Dal-уровня коллекции должны выходить будучи уже загруженными в память (напрмиер, через ToList). для этого можно ввести в кодинг-стандарт , чтоб публичные дал-методы возвращали коллекции в List'ах и массивах, а не в IEnumerable
применительно к ~нашим существующим проектам это сделать проблематично, но , думаю, проблему можно купировать, переведя все вид-модели с IEnumerable на List, и введя соответствующее положение в правила разработки
Версии:
Asp.net MVC (не помню, сколько)
.net Framework 4.6.1
старая версия Unity.Mvc: Unity.Mvc.3.5.1404
новая версия: Unity.Mvc.5.0.9
