Я работаю на нескольких сайтах DotNetNuke, и иногда (я еще не выяснил общий фактор), когда я использую Мастер публикации баз данных от Microsoft для создания скриптов для сайта, который я создал на моем сервере Dev, после запуска сценарии на хосте (обычно GoDaddy.com) и загрузка файлов сайта, я получаю сообщение об ошибке ... Я на 99,9% уверен, что это не связано с файлом, поэтому не уверен, с чего начать в БД. К сожалению, с DotNetNuke вы не получаете YSOD, а получаете общую ошибку, без реального способа найти фактическое возникшее исключение.
Мне просто любопытно, были ли у кого-нибудь подобные проблемы с развертыванием с помощью мастера публикации баз данных, и если да, то как они их преодолевали? У меня есть набор инструментов RedGate, но некоторые хосты, такие как GoDaddy, не позволяют вам напрямую подключаться к своим серверам ...


Сценарии, сгенерированные мастером публикации баз данных, обычно необходимо настраивать, поскольку иногда при работе с ограничениями порядок создания таблиц / процедур неверный. Что я делаю, так это сначала создаю резервную копию базы данных, затем запускаю сценарий, и если я получаю сообщение об ошибке, я перемещаю этот запрос в конец сценария. Продолжайте восстанавливать базу данных и запускать скрипт, пока он не заработает.
Вы должны иметь возможность показать основное сообщение об ошибке, установив следующее в web.config:
customErrors mode = "Off"
Не могли бы вы подробнее рассказать о «загрузке файлов сайта»? Новый экземпляр DNN? обновление существующего сайта? обновление версии DNN? При обновлении или обновлении - какие файлы вы добавляете / перезаписываете?
Кроме того, при использовании GoDaddy можете ли вы проверить, что удостоверение веб-сайта (сетевая служба или учетная запись компьютера asp.net в зависимости от вашей версии IIS) имеет достаточные разрешения для файловой системы веб-сайта? У него должны быть разрешения на изменение, и их может потребоваться повторно применить, если вы перезаписываете файлы.
Протестируйте созданные сценарии в новой локальной базе данных (с помощью бесплатного продукта SQL Express или полного предложения еды). Если локально он работает нормально, вы можете быть уверены, что он будет работать и в другом месте, при прочих равных.
Если он сработает при локальном запуске, используйте процесс исключения и пройдите через выполнение скрипта, чтобы найти проблемный код.
Я подозреваю, что порядок сценариев может быть отключен. I считать У меня такое случалось раньше с мастером публикации базы данных.
Просто прочтите ваше продолжение. В каждом случае, когда у меня возникала ваша проблема, это всегда было связано со строкой подключения в web.config. Даже после нескольких часов наблюдения за ней всегда была проблема со строкой подключения в web.config. Вставай, прогуляйся и возвращайся.
Если вы получаете одну из страниц ошибок DNN, есть вероятность, что она записала ошибку в таблицу журнала событий.
Есть две области, на которые я хотел бы обратить внимание:
В зависимости от того, что именно происходит и что вам показывает DNN, вы можете вручную заглянуть в таблицу EventLog, извлечь хранящиеся там XML-данные и проанализировать их, чтобы найти трассировку стека и подробную информацию о конкретной ошибке.
Однако я обнаружил, что в целом я получаю НАМНОГО лучше опыт развертывания с использованием резервных копий и восстановлений моей базы данных, поэтому я на 100% уверен, что все объекты перемещены правильно, и, честно говоря, это работает лучше в моем опыте.
Я знаю, что с GoDaddy еще одной ГЛАВНОЙ распространенной проблемой являются неправильные права доступа к файлам, не позволяющие DNN изменять web.config и другие файлы, которые ему необходимо сделать.