Windows Azure Cloud Service - доступ к развернутому файлу xml denied

Question

У меня есть приложение MVC, которое отлично работает в помещении, оно отлично работает на лазурных веб-сайтах. Но при развертывании в качестве облачного сервиса у меня есть доступ, который запрещает доступ к некоторым файлам xml.

Эти xml-файлы - это всего лишь биты данных, необходимые для приложения, которые помогают определить определенные параметры в приложении.

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

Свойства действия сборки файлов xml устанавливаются в контент, чтобы они были развернуты с публикацией. На самом деле у меня есть RDP'd на виртуальную виртуальную машину облачных вычислений, чтобы проверить, что xml-файлы развернуты и могут подтвердить, что они есть.

Однако всякий раз, когда приложение пыталось прочитать один из этих файлов, я получаю следующий отказ в доступе.

Отказано в доступе к пути «E: \ sitesroot \ 0 \ Templates \ Applications \ ControlProperties.xml».

(Примечание: Это не жестко закодированы путь, как предполагается, в ответ ниже, я использую HttpContext.Current.Server.MapPath определить физический путь к файлу относительно корневого веб-каталога)

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

Теперь, если я снова RDP для машины и предоставил всем полный доступ к этому файлу (только для диагностических целей!), Приложение отлично работает, не вызывая ошибки. Таким образом, это доказывает, что это проблема доступа.

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

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

С точки зрения кода, который я использую для чтения XML-файла, я просто использую XmlSerializer для десериализации содержимого файла обратно в объект. (Как показано ниже)

public static T Deserialise(string settingsFile) 
    { 
     using (var fs = new FileStream(settingsFile, FileMode.Open)) 
     { 
      var sr = new XmlSerializer(typeof (T)); 
      var obj = (T) sr.Deserialize(fs); 
      fs.Close(); 
      return obj; 
     } 
    } 

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

Answer 1

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

Однако, сначала изменив код, чтобы сначала прочитать содержимое файла в строке, я смог избежать этой ошибки.

public static T Deserialise(string settingsFile) 
    { 
     var fileContents = File.ReadAllText(settingsFile); 
     using (var fs = new MemoryStream(Encoding.ASCII.GetBytes(fileContents))) 
     { 
      var sr = new XmlSerializer(typeof (T)); 
      var obj = (T) sr.Deserialize(fs); 
      fs.Close(); 
      return obj; 
     } 
    } 

не уверен, почему метод Filestream нужны эти дополнительные разрешения, но выше решение работает для меня в этом сценарии.

Answer 2

Сам проект позволяет добавлять папки и сопоставлять этот путь к файлу в вашем web.config вместо E:\sitesroot\0\Templates\Applications\ControlProperties.xml. Таким образом, проблемы с правами доступа будут автоматически устранены, когда бы вы не размещались в Cloud Service.

Я сделал, как показано ниже,

В сети.конфигурации:

<configuration> 
     <appSettings> 
      <add key="DocsPath" value="http://somesitename.cloudapp.net/Files/"/> 
     </appSettings> 
    <connectionStrings> 

в код:

string Location = ConfigurationManager.AppSettings["DocsPath"] + "ChildFolderName" + "\\" + Filename.XML; 

В облаке URL это не даст никаких ошибок прав доступа. Таким способом web.config можно также отлаживать. Просто вам нужно указать путь, как указано выше, упомянутого в web.config. измените строку соединения и другие вещи тоже в web.config.

Answer 3

Разница заключается в способе доступа к файлу. Оказывается, вы не можете открывать файлы внутри роли Azure Web/Worker для записи. Несмотря на то, что вы просто читаете файлы, File.Open открывает их с доступом для чтения/записи. Так это должно работать также:

using (var stream = File.Open(settingsFile, FileMode.Open, FileAccess.Read)) 
{ 
... 
} 

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