Reference Assemblies что это за программа и нужна ли она?
Добрый день ребята Будем сегодня знакомиться с такой прогой как Reference Assemblies — я расскажу что это такое и вы сможете понять нужна вам эта программа или нет. Reference Assemblies относится не к простым программам, а к тем, о которых мало кто что знает, а все потому что это больше вспомогательный компонент, чем отдельное приложение. Данный компонент нужен для правильной работы других программ.
Ситуация необычная — небольшая популярность Reference Assemblies может стать поводом появления вирусов, которые будут косить под эту прогу. Я проанализировал интернет и пришел к выводу, что Reference Assemblies относится к среде разработки Visual Studio, в этой среде (или редакторе) программеры создают приложения, функции, библиотеки. И как я понимаю, Reference Assemblies это дополнение, содержащее уже готовый набор каких-то функций.
Часто программа Reference Assemblies имеет свою папку в директории C:\Program Files, при этом стоит отметить что студия Visual Studio находится в отдельной папке и не пересекается с папкой Reference Assemblies, вот так вот немного закручено…
Нашел в сети такую картинку:
Ну тут видно что само окно это от студии Visual Studio и тут предлагается что-то выбрать.. Но что именно — неизвестно..
Reference Assemblies у вас может быть на компьютере не только тогда, когда стоит студия Visual Studio, но и тогда когда у вас например есть пакеты Фреймворка. Удалять Reference Assemblies ну никак не стоит, это может спровоцировать глюки и лаги в компе — оно вам нужно?
Я посмотрел у себя на компе — папка Reference Assemblies есть, вот она:
Именно эта папка находится в C:\Program Files, я потом пошел в C:\Program Files (x86) и там тоже была эта папка:
Я посмотрел что внутри папок — ничего особенного, только непонятные папки там и библиотеки. Если зайти в папку, то там идет сначала папка Microsoft, потом идет папка Framework, потом идут две папки v3.0 и v3.5, и внутри этих папок примерно одно и тоже. Ну вот например что в папке v3.5:
ОЧЕНЬ ВАЖНЫЙ МОМЕНТ. Я обратил внимание на то, что сама папка Reference Assemblies изменена была аж в 2009-том году — то есть в принципе тогда когда и делали винду и все такое. Вот доказательства, смотрите:
Это только лишний раз показывает что папка Reference Assemblies относится к системе и удалять ее не нужно просто так
Надумал я кое что проверить — зажал кнопульки Win + E, открылось окно где у меня диски все, там я зашел на системный диск, и в окне в правом верхнем углу было поле, туда написал я слово Reference:
Дальше я ждал, ждал.. и вот что нашлось:
И это еще не все. Видите? Эта штука Reference Assemblies — не серая мышка какая-то, а видимо весомый компонент винды все таки..
Но как я уже писал, под данную программу может маскироваться вирус — ибо о проге инфы мало, а та инфа что есть, то она указывает на то что это системная штука. Вот вирусописатели этим могут воспользоваться — подстроят все так чтобы вы думали что это не вирус. Что нужно сделать чтобы исключить заражение вирусом? Первое — это просканировать машину утилитой AdwCleaner:
Вы не смотрите на немецкий язык, это я картинку для примера нашел, AdwCleaner идет на русском и бесплатная эта утилита, скачать в интернете легко, ибо есть она на каждом углу. Данная утилита очистит комп от всего левого и вредного — это псевдовирусы, они не оч опасны, но очень много делают пакостей. Так вот, второе что вам нужно сделать, это проверить комп утилитой Доктор Веб КуреИТ — это уже мощнейшая утилита которая находит опасные и оч опасные вирусы, трояны, черви. Проверить обязательно нужно! Оцените как она выглядит:
Как бы я мог оценить работу Доктора Веба КуреИТ? Работает утилита хорошо, также бесплатная, скачать не проблем. Один косяк в утилите есть — она просит согласится с тем что будет отправляться анонимная инфа о проверке. Это абсолютно безопасно и данный шаг сделан для улучшения работы самой утилиты
Вот и все ребята — я искренно буду надеяться что я смог вам помочь данной статье. Пока..
Удаление неиспользуемых сборок из .NET проекта
Когда-то во время учебы в университете, преподаватель, проверяя лабораторную работу по C++, вдруг неожиданно для меня задал вопрос: “А зачем вам здесь #include “%имя_библиотеки%”? Вы можете пояснить, для каких частей кода нужна каждая директива include?” Та директива, что «бросилась ему в глаза», была добавлена при попытке использовать какой-то класс. Класс, видимо, не прижился в лабораторной и его использование было благополучно удалено, а include остался…
Программируя в С#, с использованием Visual Studio, мы так же сталкиваемся с неиспользуемыми директивами using. Но Visual Studio может помочь справиться с проблемой, достаточно для .cs файла вызвать команду “Remove Unused Usings”. Правда есть еще одно место, которое так же не мешало бы время от времени чистить. Это ссылки (References) проекта. Как ни печально, но для C# проекта такой команды нет. В MS Connect даже баг создали по этому поводу. А вот для VB.NET проектов такая функция есть (найти её можно в свойствах проекта), но по злой иронии судьбы для VB.NET проектов нет команды для удаления неиспользуемых Imports (usings в C#) 🙂
Подогреваемые жаждой сделать полезное коллегам, независимые разработчики решили написать небольшие расширения для Visual Studio. А тут еще и Extension Manager из Visual Studio 2010 так упростил процесс распространения расширений. Пример таких расширений можно найти здесь и здесь. Невозможно судить об алгоритмах, используемых в этих расширениях. Хотя не буду скрывать, что после того как первое расширение бессовестно удалило из проекта приличную часть реально нужных для компиляции сборок, мы все таки посмотрели его рефлектором… Разбираться со вторым уже не стали. В общем-то, проблема одинакова, а ключевое словосочетание можно найти в пред-предыдущем предложении: нужных для компиляции.
Рассмотрим простой пример. Пусть есть 3 проекта – 3 сборки. Сборка Assembly_A определяет класс Class_A, сборка Assembly_B определяет класс Class_B, унаследованный от класса Class_A из сборки Assembly_A. У каждого класса есть различные методы, скажем метод класса Class_A это Method_A, а метод класса Class_B – Method_B. В третьей сборке (Assembly_C) мы хотим использовать класс Class_B. Для этого в проекте добавляем ссылки на сборки Assembly_A и Assembly_B, после чего в каком-то из классов создаем экземпляр класса Class_B, вызываем метод Method_B и компилируем проект. Сборка Assembly_C готова, давайте откроем её с помощью ildasm.exe и взглянем на манифест:
// Metadata version: v4.0.30319
.assembly extern mscorlib
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 4:0:0:0
>
.assembly extern Assembly_B
.ver 1:0:0:0
>
.assembly Assembly_C
// метаданные для текущей сборки
>
.module Assembly_C.exe
// MVID:
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000003 // ILONLY 32BITREQUIRED
// Image base : 0x014C0000
* This source code was highlighted with Source Code Highlighter .
Это что же получается?! Assembly_A мы добавили к проекту, а она и не нужна? Открываем Visual Studio и удаляем из проекта Assembly_C ссылку на сборку Assembly_A. Компилируем и… получаем ошибку “The type ‘Assembly_A.Class_A’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘Assembly_A, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.”
Важно понимать причину такого поведения. В проекте нигде нет явного обращения к типам сборки Assembly_A, поэтому ссылка на эту сборку не включается в манифест сборки проекта (Assembly_C). В то же время один из типов сборки Assembly_B используется в проекте. Фактически, получается, что для времени выполнения (runtime) достаточно иметь ссылку на сборку Assembly_B. А сборки, от которых она зависит, CLR получит уже из её манифеста и так же загрузит. Но для компилятора (compile time) важно иметь в проекте Assembly_C ссылки и на сборку Assembly_B и на сборку Assembly_A, ведь он должен знать все об используемом классе Class_B, в том числе и её предков. Хорошая статья о зависимостях сборок была опубликована в MSDN Magazine, прочитать её можно здесь.
Не важно, где в вашем проекте используется класс: как поле какого-то класса, как параметр метода, как атрибут и т.п. Важно понимать то, что у компилятора должна быть возможность получить полную информацию обо всех типах, используемых в проекте. Мы должны четко указывать сборку, которую хотим использовать, ведь класс может существовать в разных версиях одной сборки (даже если компилятор сможет найти сборку (скажем в GAC), то, как ему выбрать нужную, если их несколько?). Вот, что должно быть основной идеей при разработке программы способной находить неиспользуемые в проекте сборки, т.е. такие сборки которые не требуются для компиляции.
Исследование зависимостей классов проекта служит основой расширения Reference Assistant, которое мы разработали в Lardite Group. Это бесплатное расширение доступное в Visual Studio Gallery, кроме того, вы можете загрузить исходный код Reference Assistant со страницы проекта на CodePlex.
Именно с анализа иерархии классов начался Reference Assistant. Постепенно к нему добавился анализ иерархии интерфейсов, анализ атрибутов и типов их параметров, анализ импортированных типов (например, из COM библиотеки), типов перемещенных в другую сборку. Да, есть и такие! Простой пример — ObservableCollection перекочевал из сборки WindowsBase.dll (fx3.5) в System.dll (fx4.0).
Мне нравится пример с анализом перегруженных методов. Предположим, в сборке Assembly_B определен класс Class_B, в котором метод SetCode перегружен. Пусть две его перегрузки принимают по одному параметру: один типа System.Int32, другой Assembly_A.Class_A. В сборке проекта (Assembly_C) вызывается один из перегруженных методов SetCode класса Class_B принимающий один параметр. В этом случае компилятор должен знать всё о типах параметров обоих методов, чтобы выбрать наиболее подходящий. А это значит, что сборки, в которых есть определения типов участвующих в иерархии, должны быть в ссылках проекта. Т.е. в нашем случае в ссылках проекта Assembly_C должна быть ссылка на сборки Assembly_A и Assembly_B. Описанный пример в виде кода:
// Assembly_B.dll
using Assembly_A;
namespace Assembly_B
public class Class_B
public void SetCode( int code)
// some actions…
>
public void SetCode(Class_A code)
// some actions…
>
>
>
// Assembly_C.dll (проект, который использует Assembly_B)
using Assembly_B;
namespace Assembly_C
public class Class_C
public void Run()
// some actions…
var classB = new Class_B();
classB.SetCode(1);
// some actions…
>
>
>
* This source code was highlighted with Source Code Highlighter .
Это самое основное, что хотелось рассказать. Конечно, во время разработки, мы столкнулись со множеством нюансов, описать которые в одной статье было бы перебором. Но о самых интересных мы непременно постараемся написать в других статьях. В заключении, хочется пару слов сказать об использовании Reference Assistant.
Как я уже говорил ранее, скачать Reference Assistant можно либо с CodePlex, либо с Visual Studio Gallery. Между ними есть небольшое различие – расширение, выложенное в Gallery, нельзя использовать в Express редакции Visual Studio (это ограничение Visual Studio Gallery), но расширение с CodePlex можно.
Самый простой способ установки — использовать Extension Manager, утилиту Visual Studio.
Для удаления неиспользуемых сборок в контекстном меню проекта или ссылок проекта (папка References) выбрать пункт “Remove Unused References”.
Перед удалением неиспользуемых сборок будет показано окно для подтверждения списка. Вы можете редактировать это список, если уверены, что сборка нужна по каким-либо причинам (например, динамически подключается к приложению в зависимости от настроек в файле конфигурации).
Можно так же отключить показ окна “Unused References List” с помощью опции “Don’t show this dialog next time”. Снова включить можно в конфигурации расширения: меню Tools -> Options… -> Reference Assistant.
Более подробную информацию можно найти в документации на http://refassistant.codeplex.com в разделе Downloads. User’s guide описывает работу с Reference Assistant. В нем так же описано, как включить протоколирование ошибок. Описание ошибки вы можете отправить нам по адресу RefAssistant[at]lardite.com или зарегистрировать её в трекере ошибок. Developer’s guide описывает критерии оценки сборки, на которую ссылается проект, а также дает представление об общей архитектуре расширения.
- reference assistant
- remove unused references
- удаление неиспользуемых сборок
- .net
Базовые сборки
Базовые сборки являются особым типом сборки, которая содержит только минимальный объем метаданных, необходимый для представления общедоступного API-интерфейса библиотеки. Такие сборки включают в себя объявления для всех элементов, которые важны при указании ссылки на сборку в средствах сборки, но исключают все реализации элементов, а также объявления закрытых элементов, не имеющих наблюдаемого влияния на их контракт API. Обычные сборки, напротив, называются сборками реализации.
Базовые сборки не могут быть загружены для выполнения, но они могут передаваться как входные данные компилятора так же, как сборки реализации. Базовые сборки обычно распределяются с помощью пакета средств разработки программного обеспечения (SDK) определенной платформы или библиотеки.
Использование базовой сборки позволяет разработчикам создавать программы, предназначенные для конкретной версии библиотеки, без наличия полной сборки реализации для этой версии. Допустим, на компьютере установлена только последняя версия определенной библиотеки, но требуется создать программу, предназначенную для более ранней версии этой библиотеки. При компиляции непосредственно из сборки реализации вы можете случайно использовать элементы API, которые недоступны в более ранней версии, и обнаружите эту ошибку только при проверке программы на целевом компьютере. При компиляции из базовой сборки для более ранней версии сразу же возникает ошибка времени компиляции.
Базовая сборка также может представлять контракт, то есть набор API-интерфейсов, который не соответствует конкретной сборке реализации. Такие базовые сборки, называемые сборками контракта, можно использовать для нескольких платформ, поддерживающих один и тот же набор API-интерфейсов. Например, .NET Standard предоставляет сборку контракта, netstandard.dll, которая представляет набор общих API-интерфейсов, совместно используемых различными платформами .NET. Реализации этих API-интерфейсов содержатся в разных сборках на разных платформах, например mscorlib.dll в .NET Framework или System.Private.CoreLib.dll в .NET Core. Библиотека, нацеленная на .NET Standard, может выполняться на всех платформах, поддерживающих .NET Standard.
Использование базовых сборок
Чтобы использовать определенные API-интерфейсы из проекта, необходимо добавить ссылки на их сборки. Ссылки можно добавлять либо в сборки реализации, либо в базовые сборки. По возможности рекомендуется использовать базовые сборки если они доступны. Таким образом, вы будете гарантированно использовать в целевой версии только поддерживаемые члены API, которые были предназначены для этого разработчиками API. Применяя базовую сборку, вы гарантированно не будете зависеть от деталей реализации.
Базовые сборки для библиотек .NET Framework распределяются с помощью пакетов нацеливания. Их можно получить, скачав автономный установщик или выбрав компонент в Visual Studio Installer. См. дополнительные сведения об установке .NET Framework для разработчиков. Для .NET Core и .NET Standard базовые сборки автоматически скачиваются при необходимости (через NuGet) и на них указываются ссылки. Для .NET Core 3.0 и более поздних версий базовые сборки для основной платформы находятся в пакете Microsoft.NETCore.App.Ref (до версии 3.0 используется пакет Microsoft.NETCore.App).
При добавлении ссылок на сборки .NET Framework в Visual Studio с помощью диалогового окна Добавление ссылки вы выбираете сборку из списка, и Visual Studio автоматически находит базовые сборки, соответствующие требуемой версии .NET Framework, выбранной в проекте. То же самое относится и к добавлению ссылок непосредственно в проект MSBuild с помощью элемента Эталонный проект: необходимо указать только имя сборки, а не полный путь к файлу. При добавлении ссылок на эти сборки в командной строке с помощью параметра компилятора -reference (в C# и в Visual Basic) или с помощью метода Compilation.AddReferences в API Roslyn необходимо вручную указать файлы базовой сборки для правильной версии целевой платформы. платформа .NET Framework файлы эталонных сборок находятся в папке %ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\. Каталог NETFramework. Для .NET Core можно принудительно выполнить операцию публикации, чтобы скопировать базовые сборки для целевой платформы в подкаталог publish/refs выходного каталога, установив для свойства проекта PreserveCompilationContext значение true . Затем можно передать эти файлы базовой сборки компилятору. Для поиска их путей можно использовать DependencyContext из пакета Microsoft.Extensions.DependencyModel.
Так как базовые сборки не содержат реализации, они не могут быть загружены для выполнения. Любые попытки сделать это приведут к возникновению исключения System.BadImageFormatException. Если вам нужно изучить содержимое базовой сборки, ее можно загрузить в контекст только для отражения в .NET Framework (с помощью метода Assembly.ReflectionOnlyLoad) или в MetadataLoadContext в .NET Core.
Создание базовых сборок
Рекомендуется создавать базовые сборки для библиотек в тех случаях, когда их пользователям требуется создавать программы на основе множества разных версий отдельной библиотеки. Распространение сборок реализации для всех этих версий может оказаться нецелесообразным из-за их большого размера. Базовые сборки имеют меньший размер, поэтому их распространение в составе пакета SDK для библиотеки уменьшает объем скачиваемых данных и экономит место на диске.
Интегрированные среды разработки и средства сборки также могут использовать базовые сборки, чтобы сократить время сборки в случае больших решений, состоящих из нескольких библиотек классов. Как правило, в сценариях инкрементной сборки проект перестраивается при изменении любого из его входных файлов, включая сборки, от которых он зависит. Сборка реализации изменяется каждый раз, когда программист изменяет реализацию любого элемента. Базовая сборка изменяется только при ее влиянии на общедоступный API. Таким образом, использование базовой сборки в качестве входного файла вместо сборки реализации позволяет в некоторых случаях пропустить сборку зависимого проекта.
Вы можете создавать базовые сборки:
- В проекте MSBuild с помощью свойства проекта ProduceReferenceAssembly .
- При компиляции программы из командной строки укажите -refonly параметры компилятора (C# / Visual Basic ) или -refout (C# / Visual Basic).
- При использовании API Roslyn путем установки для параметра EmitOptions.EmitMetadataOnly значения true , а для параметра EmitOptions.IncludePrivateMembers значения false в объекте, переданном в метод Compilation.Emit.
Если вы хотите распространять ссылочные сборки с помощью пакетов NuGet, необходимо включить их в подкаталог ref\ в каталоге пакета, а не в подкаталог lib\ , используемый для сборок реализации.
Структура базовых сборок
Базовые сборки являются расширением связанной концепции — сборок, содержащих только метаданные. Тела методов в сборках, состоящих только из метаданных, заменяются одним телом throw null , но такие сборки включают все члены, кроме анонимных типов. Тело throw null используется для того, чтобы могло выполняться средство PEVerify для проверки полноты метаданных, что было бы невозможно при отсутствии тела.
Базовые сборки удаляют метаданные (закрытые члены) из сборок, содержащих только метаданные.
- Базовая сборка содержит ссылки только на необходимые компоненты в слое доступа API. Реальная сборка может иметь дополнительные ссылки, связанные с конкретной реализацией. Например, базовая сборка для class C < private void M() < dynamic d = 1; . >> не ссылается на типы, требуемые для dynamic .
- Закрытые функции-члены (методы, свойства и события) удаляются в случае, если их удаление не скажется заметно на компиляции. Если нет атрибутов InternalsVisibleTo, внутренние элементы функции также удаляются.
Метаданные в базовых сборках продолжают хранить следующие сведения:
- все типы, включая закрытые и вложенные;
- все атрибуты, даже внутренние;
- все виртуальные методы;
- явные реализации интерфейса;
- явно реализованные свойства и события, так как их методы доступа являются виртуальными;
- все поля структур.
Базовые сборки содержат атрибут ReferenceAssembly уровня сборки. Этот атрибут может быть задан в исходном коде, в таком случае компилятору не требуется его синтезировать. Из-за этого атрибута среды выполнения не будут загружать базовые сборки для выполнения (однако они могут загружаться в режиме только для отражения).
Точные сведения о структуре базовой сборки зависят от версии компилятора. Более новые версии могут исключить дополнительные метаданные, если они не влияют на общедоступный API-интерфейса.
Сведения в этом разделе применимы только к базовым сборкам, которые созданы компиляторами Roslyn, начиная с C# версии 7.1 или Visual Basic версии 15.3. Структура базовых сборок для библиотек .NET Framework и .NET Core может отличаться некоторыми деталями, так как они используют собственный механизм создания базовых сборок. Например, они могут иметь совершенно пустые тела методов вместо тела throw null . Но общие принципы по-прежнему применяются: у них нет пригодных для использования реализаций методов и они содержат метаданные только для элементов, которые имеют наблюдаемый эффект с точки зрения общедоступного API-интерфейса.
См. также
- Сборки в .NET
- Общие сведения о настройке для платформы
- Практическое руководство. Добавление и удаление ссылок с помощью диспетчера ссылок
Совместная работа с нами на GitHub
Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.
Reference assembly не обновляется
возникла след проблема — загрузил в отдельный пакет-проект reference assembly, пересобрал ассембли локально и хочу снова загрузить. для этого я удаляю старую дллку с помощью Configuration страницы, загружаю новую, нажимаю Compile All кнопку. после этого все равно остается старая дллка и я не могу проверить новые фиксы/ функционал и тд. в чем может быть проблема?
использую локальную разработку, .net core 3.1 приложение в докере, file mode — false.
2 комментария
18 мая 2022 12:48
Для того чтобы приложение подтягивало сборку из Пакета-Проекта, нужно:
1. Название dll сборки Пакета-Проекта, должно совпадать с названием пакета.
2. dll сборка Пакета-Проекта должна находится в соответсвующей директории:
— TS.Conf/PackageName/Files/Bin/ (для Framework)
— TS.Conf/PackageName/Files/Bin/netstandard (для .NetCore)
3. Для .NetCore флаг Feature-UseSeparateDirectoryToLoadPackageAssemblies (в Terrasoft.WebHost.dll.config) должен быть включен:
4. Cборка должна быть помечена аттрибутом:
[assembly: PackageReferenceAssembly(RefAssemblyMarker.All)]
и добавить: using Terrasoft.Core.Attributes;
Это делается в AssemblyInfo.cs (папка Properties — Properties\AssemblyInfo.cs )
Если используется, новая версия проекта *.csproj, то в нем AssemblyInfo.cs генерируется автоматически на основании проекта.
Для того чтобы не было конфликтов автогенерируемой AssemblyInfo.cs с созданной вручную, нужно в проекте *.csproj, отключить автогенерацию AssemblyInfo.cs.
Для этого в проект *.csproj, надо добавить запись:
.
.
20 мая 2022 10:55
Cherednichenko Nikita,
спасибо за ответ. получилось решить проблему для вызова кода из бизнес процессов.
но все равно осталась проблема вызова рест ендпоинта. не получается сделать вызов если код находится в библиотеке (reference assembly), а не в исходнике кода (source code).
вот такой сервис работает не работает в библиотеке, где содержаться другие классы для бизнесс процессов
using System.ServiceModel; using System.ServiceModel.Web; using System.ServiceModel.Activation; using Terrasoft.Web.Common; [ServiceContract] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] public class GreetingService : BaseService [OperationContract] [WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json)] public string Test() return "test output"; > >в чем может быть проблема? или рест сервисы в reference assembly не поддерживаются/надо что-то еще добавить?