Автоматическое связывание только ссылочных компонентов управляемой коллекции классов C # в dll или приложение

Question

Недавняя, не подлежащая обсуждению, миграция платформы партнера по разработке вынудила меня перейти к разработке .NET 3.5 Compact Framework для Windows CE 6.0 с использованием Visual Studio 2008.

В других средах я привык объединять большие рамки классов «модулей» / модулей / и т. Д. в статическую библиотеку, которая должна быть связана с меньшими частями кода «конфигурации продукта», чтобы генерировать разнообразные образы приложений и / или динамических библиотек, содержащие только те компоненты, на которые фактически имеются ссылки.

Несмотря на то, что статическая связь является случайной, критическое значение имеет анализ неиспользуемого кода : он удовлетворяет не только потребностям, но и требованиям безопасности на рынке, где клиенты просматривают неиспользуемый код, особенно любой, который может добавить возможность, если выполняется - как неприемлемая уязвимость.

К сожалению, это, похоже, противоречит мировоззрению .NET (не говоря уже о решениях и шаблонах проектов, поставляемых с VS2008), которое, по-видимому, предпочитает создание библиотек DLL (сборок, библиотек классов, сетевых модулей и т. Д.) Для повторного использования через развертывание в полном объеме. Действительно, информация в поддержку этого подхода находится в таком подавляющем большинстве, что я быстро расстраиваюсь, пытаясь найти что-то противоположное.

Таким образом, может Я достигну эффекта разделения мертвого кода, эквивалентного артефактам статической связи, когда ссылки на исходный код на компоненты в сочетании со ссылкой на продукт или решение для их совокупного набора достаточно. чтобы все и только необходимые компоненты были включены в развертывание?

Например, может ли такой инструмент, как ILMerge , выполнить это без значительного ручного вмешательства или затрат на обслуживание (например, списки компонентов, отличные от кода клиента или конфигурации сборки библиотеки фреймворка) и только с ограниченным объяснением другим разработчикам, сталкивающимся с еще более крутыми кривыми обучения; или, что еще лучше, в VS2008 уже есть какие-то средства?

-
EGR

Answer 1

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

1. Без внедрения сторонних инструментов партнер по развитию моей компании откажется от поддержки, стало очевидно, что единственный способЧтобы создать закрытую, полностью используемую подсистему, соответствующую требованиям клиента , вероятно, нужно явно управлять коллекцией классов, включенных в конечные сборки продукта, в конфигурации сборки, независимо от ссылок других классов.

2. Чтобы избежать подверженной ошибкам, ручной, параллельной модификации исходного кода, становится необходимым сделать наличие или отсутствие ссылочных классов в конечных сборках продукта достаточным для включения или отключения поддерживаемых ими функций, не оставляя висячих ссылок, доступных для эксплойта .

3. На данный момент не обращая внимания на висячую проблему ссылок, на ум приходят два подхода: использовать рефлексию для поиска потенциальных референтов, реализующих интерфейсы, известные их потенциальным реферрерам;или потенциальные референты наследуют базовый класс со знанием класса реферрера.В любом случае и реферер, и референт должны находиться в одной сборке, и механизм должен ограничиваться этой сборкой.

4. Поскольку системная архитектура нашего партнера по разработке требует не только управляемых компонентов C # .NET, специфичных для этой платформы, но и неуправляемых компонентов C ++, которые мы хотим повторно использовать на других своих платформах, которые не включают ни C # /. NET, ни разрешаютRTTI, последний подход кажется более разумным, для согласованности дизайна.

5. Учитывая выбранный подход, хорошим кандидатом для базового класса референта на любом языке является тот, который вложен в класс реферера (и друг ed в C ++, если компилятор не может обработатьвложенные классы в качестве членов).

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

7. Наконец, поскольку архитектура партнера требует, чтобы наш продукт представлял только небольшое количество четко определенных интерфейсов, подавляющее большинство наших классов C # будут внутренними по отношению к конечным сборкам, требуемое ограничение разрешения составляетдостигнуты.

-
egr

Answer 2

Да, такие инструменты существуют, но они широко не используются в .NET.

Один из упомянутых мной инструментов - Remotesoft Salamander .NET Linker .Я не использовал этот инструмент, поэтому я не могу комментировать его достоинства, кроме того, что есть на их веб-сайте:

Salamander .NET Linker и инструмент мини-развертывания позволяют объединять сборки .NET в единыйфайл, а также для развертывания приложения без установки всего Microsoft .NET Framework.Компоновщик выборочно связывает код MSIL, собирая воедино только необходимые классы и методы, и может связываться с библиотеками классов платформы Microsoft .NET.