2009-12-09 3 views
2

У меня есть сборка, содержащая функцию, которая может быть вызвана из IIS или из консольного приложения.Является плохой идеей иметь разные файлы, сидящие в каталоге bin

Из-за этого я выбрал для следующего, чтобы получить путь:

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location) 

, очевидно, это будет возвращать каталог бен в случае вызываемой функции от IIS.

Я намереваюсь создать txt-файл на этом пути. Неужели такая плохая идея иметь текстовые файлы, сидящие в каталоге bin? Просьба дать обоснованные возражения (если есть), почему это может вызвать проблемы.

ответ

5

Assembly.Location может возвращать неожиданные результаты, например. если теневое копирование включено (например, при запуске через NUnit) или при запуске из местоположения, а не локальной файловой системы (вы можете запускать приложения .NET через HTTP).

AppDomain.CurrentDomain.BaseDirectory является более безопасным вариантом, так как он возвращает исходный путь до теневого копирования (хотя в случае развертывания HTTP я думаю, что он возвращает каталог, в котором находится ieexec.exe).

Самый безопасный вариант - это встраивание любых данных, необходимых в качестве ресурса в сборку, и использование Assembly.GetManifestResourceStream для доступа к нему во время выполнения.

2

Возможно, у вас недостаточно прав для записи в этот каталог. Вместо этого попробуйте использовать папку TEMP (подумайте Path.GetTempPath()).

+0

Тестирование разрешений сейчас .... –

+0

В идеале, используя свойство System.IO.Path.GetTempPath(). –

+0

На самом деле это отличное предложение. Единственное, что мне не нравится, это то, что каталог temp является неясным местоположением и также подвержен внешним силам (например, администраторы, очищающие его) –

2

Если вы удаляете/копируете/перезаписываете файлы в каталоге «bin», IIS перезапускает процессы - поскольку IIS считает, что приложение было изменено, поэтому новые запросы должны быть обработаны «новым» применением.

Таким образом, да Плохая идея.

+0

действительно, поэтому ЛЮБЫЕ изменения в любом файле там будут сброс IIS? –

+0

Я думал, что это просто изменения в DLL и web.config –

+0

Любой файл, вызывающий сброс IIS - потому что сборки могут иметь любые расширения или расширение или файл не является сборкой, но может быть частью приложения. – TcKs

1

У Тима Робинсона есть правильная идея.

Единственное, что я должен сказать, это то, что ASP.NET пишет файл, будьте осторожны с вашим кодом потока; возможно, два запроса для одной и той же страницы будут пытаться написать один и тот же файл одновременно, поэтому будьте осторожны, чтобы заблокировать запись в файл.

Смежные вопросы