Isolatedstorage что это за папка
Перейти к содержимому

Isolatedstorage что это за папка

  • автор:

IsolatedStorage — что это за папка, можно ли удалить?

  • Описание
  • Разбираемся
  • Вывод

Приветствую уважаемые ребята! Будем разбираться сегодня с папкой IsolatedStorage — что это? Можно ли удалить? От какой программы? Постараемся все выяснить. Помните, что просто так удалять нельзя никакие папки, впрочем как и программы, иначе потом компьютер может работать нестабильно.

Описание

IsolatedStorage — папка, представляет из себя изолированное хранилище для настроек, может использоваться некоторыми установленными программами на ПК.

Разбираемся

  1. Скажу сразу, что нормальной информации об этой папки нет. Есть инфа из мира программирования, на основе которой и постараемся понять предназначение папки.
  2. Эта папка представляет из себя изолированное пространство, в котором могут хранится данные разных программ. Доступ к этим данным возможен только программам-создателям, а также контролируется системой безопасностью.
  3. Но зачем это нужно? Программы могут использовать изолированное хранилище для сохранения данных в собственной изолированной части файловой системы без указания точного пути. Это данные с сайта Майкрософт.
  4. Если программа А создала данные в директории IsolatedStorage, то программа Б доступ к ним получить не сможет. Только программа А, потому что она является создателем этих данных и она их в папку IsolatedStorage и поместила. Такие правила.
  5. Какие данные могут хранится в IsolatedStorage? Например настройки или служебные данные. Но повторюсь, что точной информации о предназначении папки — нет. Известно одно — она может использоваться разными приложениями, которые установлены на вашем ПК. Удалять эту папку я категорически не советую.
  6. Изолированное хранилище используется не только в обычных Windows для компьютера, но и в мобильных системах Windows Phone 7.

У меня на ПК данная папка тоже есть:

Что важно — создана была папка еще в январе (сейчас у меня октябрь).. примерно тогда я вроде и устанавливал операционку. То есть она была с самого начала. Внутри — папка с непонятным названием, которая тоже была создана в январе:

Ну и внутри этой папки — непонятный файл, был создан уже вначале февраля:

Все. Больше никаких данных в папке нет. Поэтому я делаю вывод, что ничего страшного нет, это не вирус, не левое ПО, это системная директория Windows, которую некоторые программы могут использовать для хранения данных. Весит IsolatedStorage у меня очень мало, меньше мегабайта, поэтому удалять точно смысла нет и вам не советую.

Но если папка весит много — можно попробовать почистить систему утилитой CCleaner, правда сомневаюсь что поможет. При желании — можно пойти на эксперимент, переименовать IsolatedStorage в IsolatedStorage_ и посмотреть что будет. Перед переименованием желательно создать точку восстановления. Если при переименовании будут проблемы — используйте программу Unlocker. Но если после переименования не будет никаких проблем — пусть папка лежит так.. если и дальше не будет проблем, тогда думаю ее можно удалить. Но все это на свой страх и риск.

Заключение

  • IsolatedStorage — директория, является изолированным хранилищем, где могут хранить данные некоторые установленные программы на компьютере.
  • Удалять эту папку думаю не стоит — могут быть проблемы при работе некоторого ПО.

Удачи и добра, до новых встреч друзья!

Что за папка IsolatedStorage? Для чего она нужна?

конкретнее, где размещена эта папка и что в ней? может ты см ее создал на раб столе?

Она, как вариант, может принадлежать плагину Vegasaur. Удаление папки c:\ProgramData\IsolatedStorage (при незапущенном Sony Vegas) иногда приводит к сбросу 30-дневного триального периода плагина.

Похожие вопросы

Ваш браузер устарел

Мы постоянно добавляем новый функционал в основной интерфейс проекта. К сожалению, старые браузеры не в состоянии качественно работать с современными программными продуктами. Для корректной работы используйте последние версии браузеров Chrome, Mozilla Firefox, Opera, Microsoft Edge или установите браузер Atom.

Изолированное хранилище

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

Изолированное хранилище недоступно для приложений Магазина Windows 8.x. Вместо этого используйте классы данных приложений в пространствах имен Windows.Storage , включенных в API среды выполнения Windows для хранения локальных данных и файлов. Дополнительные сведения см. в статье Доступ к данным приложения в Центре разработки для Windows.

Секции данных и хранилища

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

В изолированном хранилище данные всегда изолированы по пользователю или сборке. Сборка идентифицируется учетными данными, такими как источник или строгое имя. Данные также могут быть изолированы по домену приложения при помощи подобных учетных данных.

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

Квоты для изолированного хранилища

Квота — это ограничение доступного для использования объема изолированного хранилища. Квота учитывает байты файлового пространства, а также служебные данные, связанные с каталогом и другой информацией в хранилище. Изолированное хранилище использует квоты разрешения, которые представляют собой допустимые пределы хранения, устанавливаемые посредством объектов IsolatedStoragePermission . При попытке записать данные в превышение квоты возникает исключение IsolatedStorageException . Какие разрешения даются коду, определяет политика безопасности, которую можно менять с помощью средства настройки .NET Framework (Mscorcfg.msc). Для кода, которому предоставлено разрешение IsolatedStoragePermission , выделяется хранилище, максимальный размер которого определяется свойством UserQuota . Тем не менее, поскольку код может обходить квоты разрешения, используя различные удостоверения пользователя, эти квоты в большей степени имеют характер рекомендаций по работе кода, нежели выступают в роли строгих ограничений.

К перемещаемым хранилищам квоты не применяются. По этой причине для их использования код должен располагать разрешениями несколько более высокого уровня. Значения перечисления AssemblyIsolationByRoamingUser и DomainIsolationByRoamingUser определяют разрешение на использование изолированного хранилища для перемещаемого профиля пользователя.

Безопасный доступ

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

Администраторы могут ограничивать размеры изолированного хранилища, доступного приложению или пользователю, в зависимости от соответствующего уровня доверия. Кроме того, администраторы могут удалить все хранящиеся данные. Чтобы создать изолированное хранилище или получить доступ к нему, коду необходимо предоставить соответствующее разрешение IsolatedStorageFilePermission .

Для доступа к изолированному хранилищу коду должны быть назначены все необходимые права операционной системы собственной платформы. Должны быть выполнены требования списков управления доступом, которые определяют, какие пользователи имеют права на пользование файловой системой. Приложения .NET по умолчанию имеют права доступа к изолированному хранилищу на уровне операционной системы, если только они не выполняют олицетворение (специфическое для платформы). В таком случае ответственность за обеспечение наличия у олицетворяемого пользователя прав, необходимых для доступа к изолированному хранилищу, несет приложение. Такой доступ позволяет коду, запускаемому или загружаемому через Интернет, выполнять чтение и запись в области хранения, относящейся к конкретному пользователю.

Для управления доступом к изолированному хранилищу среда CLR использует объекты IsolatedStorageFilePermission . Каждый объект имеет свойства, которые определяют следующие значения:

  • Разрешенное использование, которое указывает тип разрешенного доступа. Значения являются членами перечисления IsolatedStorageContainment . Дополнительные сведения об этих значениях см. в таблице в следующем разделе.
  • Квота хранилища, описанная в предыдущем разделе.

Среда выполнения требует разрешения IsolatedStorageFilePermission при первой попытке открыть хранилище. Решение о предоставлении этого разрешения определяется с учетом надежности кода. Если разрешение выдается, значения квоты использования и хранилища определяются политикой безопасности и запросом кода на получение разрешения IsolatedStorageFilePermission. Политика безопасности задается с помощью средства настройки .NET Framework (Mscorcfg.msc). Все вызывающие программы в стеке вызовов проверяются на наличие по меньшей мере одного соответствующего разрешения на использования. Среда выполнения также проверяет наличие квоты у кода, открывшего или создавшего хранилище, в которое записывается файл. Если все эти условия выполнены, то выдается разрешение. Квота проверяется каждый раз при записи файла в хранилище.

Коду приложения не нужно запрашивать разрешение, поскольку среда CLR выдаст соответствующее разрешение IsolatedStorageFilePermission , исходя из политики безопасности. Однако имеет смысл запрашивать определенные разрешения для своего приложения, включая IsolatedStorageFilePermission.

Разрешенное использование и угрозы безопасности

Разрешенное использование, заданное при помощи IsolatedStorageFilePermission , определяет степень, в которой коду разрешено создавать и использовать изолированное хранилище. В следующей таблице приведено соответствие между разрешенным использованием и типами изоляции, а также кратко описаны риски безопасности, связанные с каждым из видов разрешенного использования.

Разрешенное использование Типы изоляции Риски безопасности
None Нет разрешения на изолированное хранилище. Влияния на безопасность нет.
DomainIsolationByUser Изоляция по пользователям, доменам и сборкам. Каждая сборка имеет отдельное вложенное хранилище внутри домена. Хранилища, использующие это разрешение, также неявно изолируются компьютером. Этот уровень разрешения оставляет возможность несанкционированного чрезмерного использования ресурсов, хотя применение квот делает это затруднительным. Этот процесс называется атакой типа «отказ в обслуживании».
DomainIsolationByRoamingUser То же, что и DomainIsolationByUser , однако хранилище сохраняется в перемещаемое расположение, если применяются перемещаемые профили пользователей и не применяются квоты. Поскольку квоты приходится отключать, то ресурсы хранения более уязвимы к атаке типа «отказ в обслуживании».
AssemblyIsolationByUser Изоляция по пользователям и сборкам. Хранилища, использующие это разрешение, также неявно изолируются компьютером. На этом уровне применяются квоты для предотвращения атак типа «отказ в обслуживании». Та же сборка в другом домене может иметь доступ к хранилищу, что может привести к утечке информации между приложениями.
AssemblyIsolationByRoamingUser То же, что и AssemblyIsolationByUser , однако хранилище сохраняется в перемещаемое расположение, если применяются перемещаемые профили пользователей и не применяются квоты. То же, что и AssemblyIsolationByUser , но без квот; риск атак типа «отказ в обслуживании» возрастает.
AdministerIsolatedStorageByUser Изоляция по пользователям. Обычно этот уровень разрешения используют только средства администрирования или отладки. Доступ с этим уровнем разрешения позволяет коду просматривать или удалять любые файлы и каталоги изолированного хранилища пользователя (независимо от изоляции сборки). Риски, помимо прочего, включают утечку информации и потерю данных.
UnrestrictedIsolatedStorage Изоляция по всем пользователям, доменам и сборкам. Обычно этот уровень разрешения используют только средства администрирования или отладки. Это разрешение может привести к потере защищенной информации всех изолированных хранилищ для всех пользователей.

Безопасность компонентов изолированного хранилища по отношению к ненадежным данным

Этот раздел применяется к следующим платформам.

  • .NET Framework (все версии)
  • .NET Core 2.1+
  • .NET 5.+

.NET Framework и .NET Core предлагают изолированное хранилище в качестве механизма сохранения данных для пользователя, приложения или компонента. Это устаревший компонент, изначально разрабатывавшийся для сценариев управления доступом для кода, которые сейчас объявлены нерекомендуемыми.

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

Чувствительные к безопасности API, которые могут считывать данные из области на уровне компьютера

Компоненты или приложения, вызывающие любой из следующих интерфейсов API, считывают данные из области на уровне компьютера.

  • IsolatedStorageFile.GetEnumerator с передачей области, включающей флаг IsolatedStorageScope.Machine
  • IsolatedStorageFile.GetMachineStoreForApplication
  • IsolatedStorageFile.GetMachineStoreForAssembly
  • IsolatedStorageFile.GetMachineStoreForDomain
  • IsolatedStorageFile.GetStore с передачей области, включающей флаг IsolatedStorageScope.Machine
  • IsolatedStorageFile.Remove с передачей области, включающей флаг IsolatedStorageScope.Machine

При вызове с помощью переключателя /machine влияет на изолированное средство storeadm.exe хранения, как показано в следующем коде:

storeadm.exe /machine [any-other-switches] 

Это средство изолированного хранилища предоставляется в составе Visual Studio и пакета SDK для .NET Framework.

Если приложение не связано с вызовами предыдущих API или если рабочий процесс не подразумевает вызов storeadm.exe подобным образом, этот документ не применяется.

Влияние в многопользовательских средах

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

  1. %LOCALAPPDATA%\IsolatedStorage\ . Например, C:\Users\\AppData\Local\IsolatedStorage\ для области User .
  2. %APPDATA%\IsolatedStorage\ . Например, C:\Users\\AppData\Roaming\IsolatedStorage\ для области User|Roaming .
  3. %PROGRAMDATA%\IsolatedStorage\ . Например, C:\ProgramData\IsolatedStorage\ для области Machine .

Два первых расположения изолированы для каждого пользователя. Windows гарантирует, что разные учетные записи пользователей на одном компьютере не смогут получить доступ к папкам профиля других пользователей. Две разные учетные записи пользователей, использующие хранилища User или User|Roaming , не будут видеть данные друг друга и не смогут повлиять на них.

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

Указанные выше пути могут отличаться в зависимости от используемой версии Windows.

Теперь давайте рассмотрим многопользовательскую систему с двумя зарегистрированными пользователями — Мэллори и Бобом. Мэллори имеет доступ к своему каталогу профиля пользователя C:\Users\Mallory\ и может получить доступ к общему расположению хранилища на уровне компьютера C:\ProgramData\IsolatedStorage\ . Она не может получить доступ к каталогу профиля пользователя Боба C:\Users\Bob\ .

Если Мэллори захочет атаковать Боба, она может записать данные в расположение хранилища на уровне компьютера, а затем попытаться вынудить Боба выполнить чтение из этого хранилища. Когда Боб запускает считанное из этого хранилища приложение, оно будет работать с данными, помещенными туда Мэллори, но в контексте учетной записи пользователя Боба. В оставшейся части этого документа описаны различные векторы атаки, а также действия, которые приложения могут предпринимать для снижения риска таких атак.

Чтобы произвести подобную атаку, Мэллори потребуется следующее.

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

Это не те векторы угроз, которые применяются к стандартным настольным системам с одним пользователем, таким как домашние компьютеры или однопользовательские корпоративные рабочие станции.

Несанкционированное повышение привилегий

Атака, основанная на повышении привилегий, происходит, когда приложение Боба считывает файл Мэллори и автоматически пытается предпринять определенные действия на основе содержимого этих полезных данных. Представьте себе приложение, которое считывает содержимое сценария запуска из хранилища на уровне компьютера и передает эти данные в Process.Start . Если Мэллори может поместить вредоносный сценарий в хранилище на уровне компьютера, то при запуске Бобом его приложения происходит следующее.

  • Его приложение анализирует и запускает вредоносный сценарий Мэллори в контексте профиля пользователя Боба.
  • Мэллори получает доступ к учетной записи Боба на локальном компьютере.
Отказ в обслуживании

Атака типа отказ в обслуживании происходит, когда приложение Боба считывает файл Мэллори и аварийно завершает работу либо перестает работать правильно. Снова представьте себе приложение, упомянутое ранее, которое пытается проанализировать сценарий запуска из хранилища на уровне компьютера. Если Мэллори может поместить файл с некорректным содержимым в хранилище на уровне компьютера, она может:

  • заставить приложение Боба вызывать исключение на раннем этапе процедуры запуска;
  • предотвратить успешный запуск приложения из-за этого исключения.

Таким образом, она помешала Бобу запустить приложение под его учетной записью пользователя.

Раскрытие информации

Атака, основанная на раскрытии информации, происходит, когда Мэллори может вынудить Боба раскрыть содержимое файла, к которому у Мэллори в общем случае нет доступа. Представьте себе, что Боб имеет секретный файл C:\Users\Bob\secret.txt, который Мэллори хочет прочитать. Она знает путь к этому файлу, но не может прочитать его, так как Windows не позволяет ей получить доступ к каталогу профиля пользователя Боба.

Вместо этого Мэллори помещает в хранилище на уровне компьютера жесткую связь. Это особый тип файла, который не имеет содержимого, а указывает на другой файл на диске. Попытка считать такой файл с жесткой связью приведет к считыванию содержимого файла, на который эта связь ссылается. После создания жесткой связи Мэллори по-прежнему не может прочитать содержимое файла, так как у нее нет доступа к целевому объекту ( C:\Users\Bob\secret.txt ) этой связи. Однако у Боба такой доступ есть.

Когда приложение Боба считывает данные из хранилища на уровне компьютера, оно непреднамеренно считывает содержимое его файла secret.txt , как если бы этот файл находился в хранилище на уровне компьютера. Когда приложение Боба завершает работу, если оно попытается повторно сохранить файл в хранилище на уровне компьютера, оно в конечном итоге помещает фактическую копию файла в каталог *C:\ProgramData\IsolatedStorage*. Так как этот каталог доступен для чтения любым пользователем на компьютере, Мэллори может читать содержимое файла.

Рекомендации по защите от подобных атак

Внимание! Если в вашей среде работает несколько пользователей, не обладающих взаимным доверием, не вызывайте API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) или средство storeadm.exe /machine /list . Оба этих компонента предполагают работу с надежными данными. Если злоумышленник может поместить вредоносные данные в хранилище на уровне компьютера, они могут использоваться для атаки с повышением привилегий в контексте того пользователя, который выполняет эти команды.

При работе в многопользовательской среде рекомендуется рассмотреть возможность использования функций изолированного хранилища, предназначенных для области Компьютер. Если приложение должно считывать данные из расположения на уровне компьютера, рекомендуется считывать данные из такого расположения, которое доступно для записи только учетным записям администратора. Каталог %PROGRAMFILES% и куст реестра HKLM являются примерами расположений, которые доступны для записи только администраторам, а для чтения — всем пользователям. Поэтому данные, считанные из этих расположений, считаются надежными.

Если приложение должно использовать область Компьютер в многопользовательской среде, проверяйте содержимое любого файла, считываемого из хранилища на уровне компьютера. Если приложение десериализует графы объектов из таких файлов, рекомендуется использовать более безопасные сериализаторы, такие как XmlSerializer , вместо опасных, таких как BinaryFormatter или NetDataContractSerializer . Соблюдайте осторожность при работе с глубоко вложенными графами объектов или графами объектов, выделяющими ресурсы на основе содержимого файла.

Расположения изолированных хранилищ

В некоторых случаях рекомендуется проверять изменения в изолированном хранилище, используя файловую систему операционной системы. Могут потребоваться сведения о размещении файлов изолированного хранилища. Место их размещения зависит от операционной системы. Ниже в таблице приведены корневые адреса файлов изолированного хранилища для некоторых распространенных операционных систем. В корневых адресах см. каталоги Microsoft\IsolatedStorage. Для того чтобы отобразить изолированное хранилище в файловой системе, нужно изменить настройки папки, установив для нее отображение скрытых файлов и папок.

Операционная система Местоположение в файловой системе
Windows 2000, Windows XP, Windows Server 2003 (обновление с Windows NT 4.0) Перемещаемые хранилища =

\Documents and Settings\\Application Data

\Documents and Settings\\Application Data

Доступ к картинкам в изолированном хранилище

Выполнив несколько проектов на wp7, я столкнулся с часто возникающей задачей: хранения изображений в изолированном хранилище и последующей отрисовкой этих изображений. При просмотре тематических блогов и статей я не обнаружил ничего кроме самого прямого и простого ресурсоемкого способа это сделать. Как оказывается — так делают все! Итак, давайте поговорим об этом способе и о моем небольшом отркытии.

Для хранения данных на диске используется Isolated Storage. Этот класс позволяет разработчику получить доступ к изолированному каталогу на диске. К этому каталогу может получить доступ только одно приложение и в нем можно создавать иерархическую структуру для хранения данных. Это одновременно и хорошо и плохо — ведь не получится расшарить данные между приложениями. Но задача с изображениями остается все такой же важной. С другой стороны, если эта задача необходима для кеширования изображения для работы офлайн — стоит подумать: ведь система кеширует изображения самостоятельно, возможно в вашем приложении и нет необходимости реализовывать кеширование вручную. Итак:

Способ №1 — самый «простой»

Сохраняем картинки в хранилище любым удобным вам способом. Теперь для отображения изображения необходимо использовать изолированное хранилище. Из хранилища в поток читается изображение, после чего изображение из потока попадает в BitmapImage и этот объект присваивается свойству Source.
Упрощенный конвертор который проделывает вышеописанные действия:

public class IsoImageConverter : IValueConverter < //Convert Data to Image when Loading Data public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) < var bitmap = new BitmapImage(); try < var path = (string)value; if (!String.IsNullOrEmpty(path)) < using (var file = LoadFile(path)) < bitmap.SetSource(file); >> > catch < >return bitmap; > private Stream LoadFile(string file) < using (var isoStore = IsolatedStorageFile.GetUserStoreForApplication()) < return isoStore.OpenFile(file, FileMode.Open, FileAccess.Read); >> public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) < throw new NotImplementedException(); >> 

Этот способ описывается везде как способ для отображения изображения из IS

Теперь способ №2 — самый нетривиальный

Однажды мне была дана задача: исследовать возможность построения offline карт с помощью существующего компонента карт. Я накачал изображений в IS я решил попробовать применить способ номер 1. Ничего не вышло. Поломав голову несколько часов, я вспомнил как когда-то читал где-то про то, что эмулятор, который установлен на виндовой машине можно расковырять и получить путь к приложению и файлам в хранилище. Что ж, если есть путь и доступ по этому пути возможен только из приложения — наверное, можно будет вставить ссылку на картинку в Image и она отобразиться. Итак, что было сделано:

Для начала в дебагере была отловлена ссылка на изображение при сохранении.

Путь: \Applications\Data\AD105BA4-EC12-49E0-9077-B5D95DBA2FEE\Data\IsolatedStore\test\SplashScreenImage.jpg

Теперь имея путь к картинке можно использовать его как Source у изображения. Но, как оказалось, необходимо использовать только абсолютные пути, потому необходимо добавить префикс file:///

Убеждаемся что картинка там и что она не повреждена:

и вставляем такой код в XAML:

С мап компонентом ничего не вышло, но ценный опыт для себя вынес. В итоге был найден более простой способ отображения изображений из IsolatedStorage.

P.S: Картинки из папки Shared таким способом вытянуть не получилось.

  • windows phone 7
  • windows phone
  • wp7
  • wp7 development
  • Silverlight
  • Разработка под Windows Phone

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *