VB.NET определяет импортированные пространства имен проекта во время выполнения

Как в VB.NET (или C #) определить во время выполнения, какие пространства имен импортируются в свойствах проекта? Я буду использовать это для динамической компиляции, я бы хотел, чтобы динамический код автоматически имел те же импорты, что и его родительский проект.

Я уже видел «Поиск всех пространств имен в сборке с использованием Reflection (DotNET)». Это и другие примеры, которые я нашел, похоже, не решают мою проблему, поскольку я обнаружил, что они предоставляют список всех ссылок на проекты. Да, я хочу, чтобы все они были доступны, но некоторые через полностью определенные имена, а не все импортированы в корневое пространство имен. И я хочу выбирать только через существующий список «Импортированные пространства имен» свойств проекта, а не поддерживать отдельный и избыточный список в моем классе динамического выполнения.


.net reflection vb.net namespaces assembly-references
person Chris C.    schedule 25.03.2016    source источник
comment
Возможный дубликат Поиск всех пространств имен в сборке с использованием Reflection (DotNET)   -  person thehennyy    schedule 25.03.2016
comment
Спасибо, но не то, что мне нужно. Я отредактировал свой исходный вопрос, чтобы лучше объяснить, что требуется.   -  person Chris C.    schedule 25.03.2016
comment
Для меня до сих пор непонятно, чего вы хотите достичь. Вы можете привести полный пример? Какой результат вы ожидаете при каких условиях?   -  person thehennyy    schedule 26.03.2016
comment
У моего проекта много ссылок. Один из них - System, и это то, что я хочу импортировать для всего проекта, поэтому я всегда могу ввести Convert вместо System.Convert. Другой - Maat, библиотека классов, созданная пользователем. Хотя я ссылаюсь на него, я никогда не импортирую его ни на уровне проекта, ни на уровне файла; частично по личным предпочтениям, а частично потому, что у него есть классы, такие как Maat.Convert, которые будут конфликтовать с классами в System, что приведет к двусмысленности. Так что, если я хочу использовать Maat.Convert, я привык печатать его полностью. (продолжение в следующем комментарии)   -  person Chris C.    schedule 26.03.2016
comment
Теперь при динамической компиляции кода я должен сообщить компилятору, на что будет ссылаться мой динамический код, который я хочу, чтобы он был идентичен родительскому проекту. Это то, что решает ваша ссылка, позволяя динамическому коду обращаться как к System.Convert, так и к Maat.Convert - но через эти полностью определенные имена. Чтобы сохранить мои стандартные соглашения об именах / доступе в динамическом коде (доступ к System.Convert только как Convert, а Maat.Convert как Maat.Convert), мне также нужно продублировать импорт, указанный в свойствах проекта, а не импортировать каждую ссылку . (продолжение снова)   -  person Chris C.    schedule 26.03.2016
comment
И я бы очень предпочел делать это автоматически, а не жестко программировать отдельный список импорта. Но я не могу найти способ узнать во время выполнения, что такое импорт всего проекта в первую очередь.   -  person Chris C.    schedule 26.03.2016
comment
Вы хотите работать с исходным кодом или скомпилированными сборками родительского проекта?   -  person thehennyy    schedule 26.03.2016
comment
Я хотел бы вытащить список импорта из скомпилированных сборок родительского проекта, если это возможно.   -  person Chris C.    schedule 26.03.2016
comment
Нет, то, что вы описываете, невозможно с скомпилированной сборкой, потому что это своего рода функция компилятора. После компиляции остается только информация об используемых типах (то, что вы можете получить с помощью отражения), а не то, как они были указаны в исходном коде. Я предлагаю немного поиграть с декомпилятором .net по вашему выбору и вашей сборкой, чтобы понять, что осталось после компиляции. Возможно, вы можете использовать платформу roslyn со своим исходным кодом, чтобы получить эту информацию.   -  person thehennyy    schedule 26.03.2016
comment
Я полностью уверен, что вы правы, импорт используется только в качестве входных данных для компилятора и не выводится в скомпилированную сборку в какой-либо форме. Спасибо, теплый. Если вы можете сделать репост, что это невозможно в качестве ответа, я официально приму это.   -  person Chris C.    schedule 27.03.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

person thehennyy    schedule 27.03.2016