Не удается загрузить ресурс манифеста с помощью 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 - по умолчанию)

Build action property set to embedded resource


по умолчанию visual studio не внедряет xsd-файл, поэтому необходимо убедиться, что свойство "Build Action" xsd-файла имеет значение "Embedded Resource", чтобы он работал


просто добавьте свои ресурсы в form1.resx Файл -->Добавить существующие элементы

дважды щелкните ресурсы, добавленные в папку ресурсы.перейдите в свойства и выберите "встроенные ресурсы" вместо "нет".

затем попробуйте отладить строку:

string[] resourceNames=Assembly.GetExecutingAssembly().GetManifestResourceNames();

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


вы можете получить поток ресурсов, передав имена ресурсов, которые приведены ниже...

  1. получить имя ресурса, например.

    сборка objAssembly = сборка.GetExecutingAssembly();

    string[] strResourceNames = objAssembly.GetManifestResourceNames();

  2. передайте имена ресурсов ...

    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 работал так, как ожидалось.