Можно ли в .NET (C#) при компиляции вычистить из подключенной библиотеки лишние функции?
Суть следующая: есть, к примеру, у меня библиотека собственной разработки, куда я добавляю все функции, которые считаю, что могут быть полезны в дальнейшей разработке других утилит, и собственно эту библиотеку я активно использую. Это удобно, но проблема в том, что библиотека разрослась и при написании очередной утилиты она может занять 20 кб, в то время как библиотека весь мегабайт. Соответственно и в память она целиком загружается.
Что меня интересует так это, есть ли какой-нибудь постпроцессор, который после компиляции проанализирует библиотеку, какие функции используются в проекте, и затем вычистит из этой скомпилированной библиотеки неиспользуемые функции?
Вы читали принципы SOLID? первая буква гласит "single responsibility principle- Для каждого класса должно быть определено единственное назначение. Все ресурсы, необходимые для его осуществления, должны быть инкапсулированы в этот класс и подчинены только этой задаче", так и с библиотеками так же, зачем все толкать в одну библиотеку? да и ниже сказали, сделать можно несколько nuget пакетов и подключать нужные. В принципе так и делают.
вычистит из этой скомпилированной библиотеки неиспользуемые функции
Из уже скомпилированной библиотеки ничего вычистить нельзя, ведь для того, чтоб убрать - надо де компилировать, очистить ненужное и скомпилировать обратно.
Но как вариант - использовать .NET 6 (придется так же переписать библиотеку на .NET 6) и использовать совет Роман
Роман, Ну и как это поможет? Библиотека в проекте подключена, некоторые функции из неё используются, таким образом компилятор видит, что эта библиотека используется и исключать её не будет. Если бы эта библиотека была подключена, но вообще не использовалась - то да, при сборке в данном случае она бы была исключена.
я вам даже ссылочку привел, а вы видать даже прочесть не смогли, компилятор анализирует и реально из библиотек вырезает неиспользуемый код, естественно, это касается только dotnet сборок, сторонние либы с неуправляемым кодом не трогаются. А возможно, только потому, что с dotnet сборках находится промежуточный байт код, который потом и компилируется в ассемблер. Подобная вещь используется в JS, в некоторых инструментах для сборку JS, есть вещь под названием tree sharking.
Роман, тут был не прав, не заметил, что речь в статье идет о уже скомпилированных библиотеках. Но это только для net 6 и есть исключения, но возможно автору подойдет.
Простой
