Короткий ответ: вы не можете помешать его запуску, и это сделано специально , но вы можете обойти эту проблему.
Причина в том, что PreApplicationStartMethod
(или WebActivator , основанный на нем) можно использовать для вещей, которые фактически влияют на компиляцию , так что если вы пропустили его, сайт может не скомпилироваться.
Чтобы дать вам пример, вы можете добавить пространства имен к компиляции в методе PreAppStart
, который затем влияет на компиляцию ваших страниц Razor.
Очевидно, что не каждый метод PreAppStart
нуждается в для запуска при использовании aspnet_precompiler, но мы запускаем их все в случае необходимости.
Если код там ломается под aspnet_compiler, может потребоваться добавить условную логику в метод PreAppStart
для обнаружения ситуации и пропустить запуск код.
Вы можете взглянуть на свойство System.Web.Hosting.HostingEnvironment.InClientBuildManager
, чтобы определить, работает ли ваш метод PreAppStart
в контексте aspnet_compiler.exe (где он будет true
), или во время выполнения (где он будет false
) , InClientBuildManager
также относится к созданию веб-сайта в VS, который использует в основном тот же путь кода, что и aspnet_compiler.exe.
Обратите внимание, что WebActivator также поддерживает PostApplicationStartMethod
, и те не будут работать в aspnet_compiler. Этот код запускается после Application_Start
, поэтому он может соответствовать или не соответствовать вашему сценарию. Но это может быть решением для вас.
Непосредственно не связан, но полезен для отладки: вы можете передать -errorstack в aspnet_compiler.exe, чтобы получить более полный стек при возникновении ошибки.
Что такое ~ / server / svntest? Веб-сервер обычно не имеет доступа к домашнему каталогу или даже к оболочке, попробуйте заменить им полный путь.
Попробуйте запустить
svnadmin verify ~/svntest/svn
в репозитории. Если это сообщает об ошибках, введите:
svnadmin recover ~/svntest/svn
Вы должны попробовать:
ln -s /home/subversion/repos /var/www/html/
измените разрешения на chown -R apache:apache /your repo
Если эта проблема возникла, выяснилось, что она вызвана несовместимой версией SVNadmin и Apache. Я обновил SVN на машине (и забыл, что у меня был). Я просто использовал полный путь (/usr/local/subversion-1.3.0/bin/svnadmin на моем старом компьютере с CentOS) к старому bin svnadmin (версия 1.3, в отличие от 1.6.11, до которой я обновился). Тогда это сработало сразу. Нет проблем с правами доступа к файлам.