|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Доброго времени суток. .Net Framework 4.8. Можно ли как-то сделать так, чтобы прокси, получаемые для объектов, инициализированных в другом домене (AppDomain), имитировали не только методы и свойства целевого объекта, но и предоставляли информацию о пользовательских атрибутах класса? Я объявил атрибут: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Затем класс, его использующий: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
В консольном приложении загружаю сборку AntPluginExample1.dll в отдельный домен. Затем создаю экземпляр ICommand и пытаюсь посмотреть кастомные атрибуты у типа: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.
Однако вижу, что по факту у сгенерированного прокси присутствует только один атрибут - SerializableAttribute: Код: powershell 1. 2. 3. 4. 5. 6. 7.
Можно ли как-то сделать так, чтобы прокся имитировала и атрибуты? С уважением, Андрей ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2019, 19:13 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Compositum, Нет. Вы грузите из внешней сборки конкретный тип по текстовому полному имени. Атрибут это тоже конкретный тип, который мало того, что вы не грузите, так и ещё не знаете о нём, он может лежать где угодно. Во-вторых, решение лежит на поверхности: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
Получаем ID: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
Попробуйте, я не проверял :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2019, 00:41 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
hVosttАтрибут это тоже конкретный тип, который мало того, что вы не грузите, так и ещё не знаете о нём, он может лежать где угодно. Ну почему же не знаю? Ведь я же сборку, в которой определены атрибут CommandIdAttribute и интерфейс ICommand , загружаю как в основной домен приложения (в методе Main() я выполнял явное приведение прокси к типу ICommand ), так и в тот AppDomain , с которым взаимодействую посредством прокси. Т.е. эти типы известны по обе стороны. hVosttПопробуйте, я не проверял :) Спасибо, :) Я тоже думал о подобном решении, но надеялся, что получать информацию об атрибутах из проксей каким-то образом всё же можно. Да, наверное так и придётся поступать. Ещё раз спасибо за ответ :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2019, 11:29 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
CompositumТ.е. эти типы известны по обе стороны. Известен интерфейс на уровне ссылке на общую сборку. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2019, 16:20 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Хм. FW 4.7.1, всё в точности так, как описано выше, только для чистоты эксперимента интерфейс ICommand вынесен еще в одну сборку, и главный проект имеет референс только на неё, на сборку с классом атрибута у главного проекта референса нет: Консольный вывод: Код: plaintext 1. 2. 3. 4. 5. 6.
Код: c# 1. 2. 3. 4. 5. 6.
Попробуйте, я не проверял :) Это видно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2019, 07:26 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Сон Веры Павловны Код: plaintext 1.
Ого... Подтверждаю. Странно... Вот уж не ожидал такого сюрприза. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2019, 22:41 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Сон Веры ПавловныХм. FW 4.7.1 В 4.7.2 тоже всё норм. Проблема только в 4.8. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2019, 22:42 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Compositum, На этом странности не закончились: переключился обратно на .Net 4.8 и... Всё работает! Я не знаю что это было. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2019, 23:05 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
CompositumЯ не знаю что это было. Можно попробовать воспроизвести начальную ситуацию (когда искомого атрибута нет), и распотрошить сборку плагина ildasm'ом. У меня это выглядит так: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
и в метаданных сборки Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
- т.е. всё на своих местах, и этого атрибута просто не может не быть. Возможно, в изначально описываемом случае это могло выглядеть как-то иначе. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 06:36 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Сон Веры Павловны, Я уверен в том, что это я где-то накосячил и затем исправил (сам не заметив как). :) Правда я так и не понял в чём был этот самый "косяк"... Ну ок, главное - это то, что теперь всё работает. Вы не в курсе, какой механизм в .NET Core пришёл на смену AppDomain? В .Net Framework я загружаю каждый плагин в отдельный AppDomain. Это позволяет мне управлять настройками безопасности для каждого плагина индивидуально (если это понадобится), а так же выгружать плагин, если он начтёт работать криво, без необходимости перезагрузки приложения в целом. Хотелось бы такой подход применять и в .Net Core, но, насколько сейчас помню, я получал сообщение о том, что не может быть более одного AppDomain... Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:07 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
CompositumВы не в курсе, какой механизм в .NET Core пришёл на смену AppDomain? Ответ нашёл у Майкрософта здесь . ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:53 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Compositum, Не пробовали поработать c MEF, если хочется загружать сборки динамически? Всё же, несмотря на то, что атрибут таки получить можно, от себя рекомендовал бы работать по контрактам. Хотите, например, получать каталог команд (Type, Id), лучше это делать через выделенный провайдер. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:56 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
Compositum, Core это кроссплатформенное приложение. Вроде под десктоп MS еще ничего не сообразил как будет. Поэтому у нас пишут на С++ и Qt. Про безопасность, то в линуксе она решается другими мерами. Например сертифицированная Ось астра производстра РФ и мандатная система безопасности. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:59 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
hVosttНе пробовали поработать c MEF, если хочется загружать сборки динамически? Не пробовал. :) hVosttВсё же, несмотря на то, что атрибут таки получить можно, от себя рекомендовал бы работать по контрактам. Хотите, например, получать каталог команд (Type, Id), лучше это делать через выделенный провайдер. Можете пояснить? У меня слово "контракты" ассоциируется либо как синоним слова "интерфейс", либо с WCF. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:05 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
CompositumВы не в курсе, какой механизм в .NET Core пришёл на смену AppDomain? AssemblyLoadContext. Я уже даже делал простенькую плагинную систему для демо с ним. Каждая сборка-плагин грузится в свою "песочницу" и может иметь свои собственные зависимости, не конфликтуя с другими. Вроде бы в третей коре обещали все это даже упростить. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:05 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
hVosttMEF +1 [Exprort("Shell", typef(ConainerControl))] ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:16 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
fkthatAssemblyLoadContext. Я уже даже делал простенькую плагинную систему для демо с ним. Каждая сборка-плагин грузится в свою "песочницу" и может иметь свои собственные зависимости, не конфликтуя с другими. Вроде бы в третей коре обещали все это даже упростить. Да, я уже читал про AssemblyLoadContext: MicrosoftСоздание дополнительных доменов приложений не поддерживается. И мы не планируем добавлять эту возможность в будущем. Вместо нее для изоляции кода мы рекомендуем использовать отдельные процессы или контейнеры. Для динамической загрузки сборок рекомендуется использовать новый класс AssemblyLoadContext. В материале, касательно AssemblyLoadContext вижу такой фрагмент текста: MicrosoftAssemblyLoadContext Представляет контекст загрузки. По существу контекст загрузки создает область для загрузки, разрешение и потенциально выгрузки набор сборок . Не совсем понял слово "потенциально" в данном контексте. Да и "набор сборок" - тоже не совсем понятен. В .Net Framework сборку выгрузить нельзя - можно выгружать только домен целиком. Т.е. складывается впечатление, что на .Net Core можно выгружать отдельно сборку (если посмотреть на неё как на набор, состоящий из одного элемента). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:19 |
|
Возможно ли через прокси получать информацию о пользовательских атрибутах класса?
|
|||
---|---|---|---|
#18+
CompositumНе совсем понял слово "потенциально" в данном контексте. Да и "набор сборок" - тоже не совсем понятен. В .Net Framework сборку выгрузить нельзя - можно выгружать только домен целиком. Т.е. складывается впечатление, что на .Net Core можно выгружать отдельно сборку (если посмотреть на неё как на набор, состоящий из одного элемента). Не знаю, у них сейчас все что связано с этим как-то почти что не задокументировано. Приходилось гуглить по всяким блогам. У меня было как-то так: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Затем: Код: c# 1. 2. 3. 4.
Я не знаю, насколько это все корректно, так как документации вообще нет, но оно работало. Я даже проверял на предмет возможного конфликта зависимостей - все было ок. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:34 |
|
|
start [/forum/topic.php?fid=20&fpage=20&tid=1398963]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 149ms |
0 / 0 |