Не удается получить временную директорию для веб-сайта .NET, размещенного в службе Azure App.

Question

Мы работаем над проверкой нашего сервиса Loupe для запуска в качестве службы приложений Azure и запускаем шоу-шоу, который мы не можем понять. Все, что попытки разрешить временную папку не удается, за исключением:

 
    mscorlib : System.IO.IOException 
    The directory name is invalid. 
     at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
     at System.IO.__Error.WinIOError() 
     at System.IO.Path.InternalGetTempFileName(Boolean checkHost) 

Трассировка стека имеет это в методе .NET для создания имени временного файла. Эта трассировка стека является общей для почти всех областей, в которых мы получаем отказ. Похоже, что если бы мы заставили сайт перезагрузиться и/или заставили базовый план обслуживания приложений перемасштабировать, он исчезнет, ​​пока мы не обновим сайт, но больше не будем.

С тех пор как единственные результаты поиска, которые мы могли обнаружить, это ошибка возникает, когда олицетворение включено, а пользователь, которому выдают себя за образец, не имеет доступа к временному каталогу пользователей IIS App Pool, который мы выкопали. Во-первых, мы можем подтвердить из нашего ведения журнала, что нить не выдаёт себя за выдачу запроса. Во-вторых, просто для забавы мы добавили это в web.config, чтобы быть в полной уверенности:

<system.web>   
    <identity impersonate="false"/> 
</system.web> 

Все безрезультатно. Если бы это была общая проблема с Azure App Services, я бы предположил, что это сломает многие системы, поэтому я должен сделать вывод, что мы сделали что-то захватывающее и неправильное, чтобы вызвать это.

Answer 1

Возможно, это не тот точный ответ, который вы ищете, но это может помочь вам в правильном направлении.

У меня были подобные проблемы некоторое время назад, используя Azure App Services. Я обнаружил, что доступ к локальной файловой системе был несколько проблематичным. Иногда это работало нормально, а иногда - нет.

В конце концов, я обнаружил, что, когда создается служба приложений Azure, она не всегда использует одинаковые буквы дисков для системы, стоящей за ней. В некоторых случаях это может привести к ошибочным ошибкам среды. Они «думают», что они настроены правильно, но это не всегда так.

Генерация имени файла temp будет использовать эту переменную среды для пути, и если она установлена ​​на C: но вместо этого на машине есть диск D: если произойдет сбой. Дисковод C: не существует, поэтому путь к временному файлу также не существует.

Чтобы определить, если это проблема, вам необходимо включить RDP, чтобы вы могли войти в нее напрямую. https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-role-enable-remote-desktop

Это единственный способ, которым я смог в конечном итоге понять это.

Answer 2

Если вы откроете экземпляр Kudu для своего веб-приложения App App, вы сможете увидеть, что локальная папка Temp находится на управляемой виртуальной машине под ней. Вы можете получить доступ к Kudu, перейдя в «Расширенные инструменты» на blade-сервере App Service на портале Azure или перейдя по домену https: // {имя веб-приложения} .scm.azurewebsites.net для вашего веб-приложения.

Однажды в Куду нажмите «Окружающая среда» в верхней навигационной панели. Каталог Temp обычно D: \ local \ Temp, и этот путь хранится в переменной окружения «TEMP», доступной для вашего веб-приложения.