Я работаю над новым проектом, который находится в .net 3.5.
В настоящее время клиент использует хранимые процедуры, и мы действительно хотели бы вместо этого использовать LINQ to SQL.Основная причина, по которой они используют хранимые процедуры, заключается в том, что они считают, что их проще обновлять, и поэтому они не используют никаких специальных разрешений или таких, которые, как я вижу, оправдывают использование хранимых процедур через LINQ to SQL, просто они не хотят менять.
Я полагаю, что если я смогу представить им решение, с помощью которого они могут легко развернуть изменения в LINQ to SQL, они могут быть более открыты для изменения своего мнения.
Как таковой, мне любопытно с asp.net project (не mvc), как выполнить обновление различных сборок, созданных в процессе сборки.
Скажем, например, весь мой код LINQ находится в проекте System.DataAccess и развертывается в рабочей среде,затем ошибка идентификатора идентифицируется с помощью LINQ.Насколько сложно просто развернуть измененный проект DataAccess (или, точнее, любой проект, в котором произошли значительные изменения после развертывания prod).
Одна вещь, я не уверен, что это поможет ситуации, заключается в том, что каждый раз, когда естьсборка Номер сборки обновляется во всех проектах независимо от того, действительно ли произошли изменения или нет, просто взглянуть на номер версии проектов будет недостаточно для определения проектов, которые необходимо перераспределить.
Я даже не уверен, возможно ли изменить сборку, чтобы обновленная версия была обновлена только у измененных проектов?
Так что в основном мне просто любопытно узнать о различных процессах исправления, а также о плюсах и минусах.(т.е. требуется сброс iis и т. д.).
Приветствия