Проблема развертывания LINQ to SQL

Question

У меня разработано приложение asp.net. Он использует LINQ to SQL для доступа к базе данных, используя конструктор .dbml в Visual Studio 2008. Мы устанавливаем приложение на клиент, и они решили изменить имя базы данных на своих серверах. Теперь приложение не работает, потому что LINQ не может найти информацию базы данных. Это не проблема со строками подключения, а с файлами, сгенерированными дизайнером .dmbl. Я полагаю, у нас есть несколько вариантов: 1. Измените имя базы данных разработки в соответствии с именем клиента, создайте debml заново, перекомпилируйте и снова отправьте приложение клиенту. 2. Установите VS2008 на клиенте и внесите в него необходимые изменения.

Ни один из вариантов не кажется действительно хорошим. Это не конец света, но это настоящая боль. Я надеюсь, что есть более разумное решение! Есть идеи?

---

ОБНОВЛЕНИЕ
После изучения ваших проблем с помощью ваших ответов, я думаю, что проблема заключается в схеме. Подводя итог, база данных имеет новое имя и новую схему. Я полагаю, что опция sqlmetal.exe является лучшей на данный момент. В любом случае, если это так, я все еще думаю, что это настоящая боль.

Answer 1

Я бы сказал, что это проблема строки подключения, см. Сгенерированный класс:

    public SomeDataContext() : 
        base(global::System.Configuration.ConfigurationManager
.ConnectionStrings["someConnectionStringKey"].ConnectionString, mappingSource)

Пожалуйста, предоставьте больше информации. Возможно, вы имеете в виду изменение схемы, и в этом случае я настоятельно рекомендую сделать то же самое в среде разработчика.

Обновление 1: Возможно, DatabaseAttribute в сгенерированном классе вас смутил.

Используйте свойство Name на Атрибут DatabaseAttribute для указания имя базы данных, когда имя не поставляется соединением

Источник: http://msdn.microsoft.com/en-us/library/bb399355.aspx# (enpashis мной)

Просто укажите базу данных в строке подключения, и все готово.

Обновление 2: Если ваш сгенерированный класс по какой-то причине не имеет вышеуказанного кода (и вы явно не указываете его в параметре), откройте его в конструкторе, откройте свойства и убедитесь, что он настроен в свойстве Connection с настройками приложения, установленными в true.

Answer 2

В составе VS2008 имеется класс SQLMetal.exe, который выполняет важную часть создания файла DataContext.cs. Я думаю, что все, что вам нужно сделать, это изменить файл DBML (это простой файл XML), запустить SQLMetal (создание .CS), а затем запустить csc.exe (часть .NET Framework) для создания сборки ( Будет проще, если вы поместите DataContext в сборку самостоятельно). По сути это сводится к варианту 2, но с гораздо меньшим количеством файлов, которые необходимо установить.

---

Обновление : перечитывая ваш вопрос, я понимаю, что изменились не имена таблиц, а имя database . Это другая проблема (хотя решение, описанное выше, будет работать и для этого).

Когда VS2008 генерирует класс DataContext из файла .dbml, он создает два конструктора: один, который не принимает параметров, и один, который принимает одну строку (плюс еще пару кодов, которые мы можем игнорировать).

Нулевой параметр ctor использует строку подключения, которую вы использовали при создании dbml, который затем встраивает в файл ресурсов. Это невероятно тупой дизайн, и на самом деле его следует использовать только для проверки кода и демонстраций.

Весь реальный производственный код должен использовать ctor, который принимает строку, в частности, строку подключения, которую вы должны прочитать из файла app.config.

Это, конечно, означает, что «правильное» решение - это вариант № 1 - переписать код в вашем офисе и переустановить. Это беспокоит, но в конечном итоге это к лучшему.

Answer 3

Лично я бы сказал клиенту, что смена имени базы данных с того, что было разработано, обойдется им в XX долларов в новых затратах на разработку, и проследил бы, чтобы они сразу же изменили имя.

Answer 4

OP:

Я удивлен, что это может вызвать проблемы. Я разработал около 5 дополнений, используя Linq to SQL. Единственное, что мне нужно было сделать, чтобы обойти это, это сделать следующее:

использование (NamedDataContext ctx = новый NamedDataContext ("{вставить строку подключения из файла конфигурации / записи реестра / и т. Д. Здесь}")) {

... код для базы данных ...

}

и еще не сталкивался с какими-либо проблемами на данный момент. Меня смущает вопрос, почему в вашем приложении нет метода настройки для настройки соединения с базой данных, поскольку обычно это первое, что требуется большинству приложений.