Не удается загрузить ресурс манифеста с помощью GetManifestResourceStream()
Я создал пользовательский раздел конфигурации с помощью XSD. Чтобы проанализировать файл конфигурации, который следует за этой новой схемой, я загружаю ресурс (my .xsd файл) с этим:
public partial class MonitoringConfiguration
{
public const string ConfigXsd = "MonitoringAPI.Configuration.MonitoringConfiguration.xsd";
public const string ConfigSchema = "urn:MonitoringConfiguration-1.0";
private static XmlSchemaSet xmlSchemaSet;
static MonitoringConfiguration()
{
xmlSchemaSet = new XmlSchemaSet();
Stream xsdStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(ConfigXsd);
XmlReader schemaReader = XmlReader.Create(xsdStream);
xmlSchemaSet.Add(ConfigSchema, schemaReader);
}
}
кстати, мой ресурс: MonitoringConfiguration.XSD-файл. И пространство имен другого частичного класса (который представляет код позади.файл xsd) составляет MonitoringAPI.Configuration
.
проблема находится здесь:
Stream xsdStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(ConfigXsd);
xsdStream имеет значение null, поэтому я думаю, что ресурс не может быть нашел! Но почему?
спасибо
8 ответов
имя ресурса всегда:
<Base namespace>.<RelativePathInProject>.<FileName>
поэтому, если ваш ресурс находится в " Resources/ Xsd/", а пространство имен проекта по умолчанию - "MonitoringAPI.Конфигурация", имя ресурса:
"MonitoringAPI.Configuration.Resources.Xsd.MonitoringConfiguration.xsd"
также убедитесь, что действие сборки для вашего ресурса установлено в "Embedded Resource"
простой и правильный способ получить фактическое имя встроенного ресурса:
string[] resourceNames =
Assembly.GetExecutingAssembly().GetManifestResourceNames();
затем просто проверьте массив resourceNames, и вы точно знаете, что передать методу GetManifestResourceStream.
в моем случае,
при попытке доступа к файлу через GetManifestResourceStream()
. Вы получите ошибку из-за недопустимого пути файла, и поток будет равен null.
устранение:
щелкните правой кнопкой мыши файл, который вы добавили в решение, и выберите Свойства.
выберите Build Action
as Embedded Resource
. (Вместо Content
- по умолчанию)
по умолчанию visual studio не внедряет xsd-файл, поэтому необходимо убедиться, что свойство "Build Action" xsd-файла имеет значение "Embedded Resource", чтобы он работал
просто добавьте свои ресурсы в form1.resx Файл -->Добавить существующие элементы
дважды щелкните ресурсы, добавленные в папку ресурсы.перейдите в свойства и выберите "встроенные ресурсы" вместо "нет".
затем попробуйте отладить строку:
string[] resourceNames=Assembly.GetExecutingAssembly().GetManifestResourceNames();
проверьте, что добавленные вами ресурсы находятся в массиве. затем скопируйте имя ресурса точно из этого массива и попробуйте поместить имя в свой код..он отлично работает!!
вы можете получить поток ресурсов, передав имена ресурсов, которые приведены ниже...
-
получить имя ресурса, например.
сборка objAssembly = сборка.GetExecutingAssembly();
string[] strResourceNames = objAssembly.GetManifestResourceNames();
-
передайте имена ресурсов ...
Stream strm = objAssembly.GetManifestResourceStream (strResourceNames);
теперь у вас есть поток вы можете делать все, что захочешь...
У меня была проблема, когда я вставлял целую кучу .xsd-файлы во многих разных сборках; все работало (GetManifestResourceNames возвращал файлы, которые я ожидал увидеть), за исключением одного. Тот, которого не было, назывался:--2-->
Something.LA.xsd
Я не имел дело с конкретными культурами и тем .LA бит в конце имени файла был подобран компилятором, так как этот файл был для культуры LA - имя файла в манифесте шло как-то.схемы xsd (под культура LA) - следовательно, я не могу найти его (он оказался в спутниковой сборке). Я уклонился от проблемы, переименовав файл-предположительно, можно явно указать культуру данного встроенного ресурса.
на самом деле, быстрый Google показывает: как я могу предотвратить установку культуры встроенного файла ресурсов на основе его имени файла
согласно этому ответу, вы должны делать хакерские вещи-так что, возможно, переименование файла было не так уж плохо :)
в моем случае это было что-то совершенно другое:
мое приложение UWP скомпилировано правильно в конфигурации отладки и выпуска, но GetManifestResourceStream вернул Null только конфигурацию выпуска.
проблема заключалась в том, что в файле конфигурации сборки UWP (и только там) параметр "компиляция с .NET Native tool chain". После отключения GetManifestResourceStream работал так, как ожидалось.