Когда и если не устанавливать в GAC?

Question

Когда и если не устанавливать в GAC?

Инициируйте свой проект, если у вас еще нет класса, расширяющего Application, просто создайте его.

class App extends Application {

    @Override
    public void onCreate() {
        Realm.init(acti);
        RealmConfiguration otherConfig = new RealmConfiguration.Builder().directory(new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/xMapper/"+fileN)).build();
        Realm.setDefaultConfiguration(otherConfig);
    }
}

Тогда вам просто нужно позвонить Realm.getDefaultInstance(), чтобы получить объект области для запроса / вставки / обновления / удаления вашей базы данных.

44

.net install gac software-distribution

задан Community 23 May 2017 в 12:10

7 ответов

Полезные случаи для GAC:

COM-вызываемый код - т.е. Вы хотите, чтобы некоторый код non-.NET смог получить доступ к Вам, не смешивая с dlls и т.д.
Обслуженные компоненты (COM +)
, Если Вы - написание кода, которое настолько распространено, это на самом деле значимо для использования GAC - прежде всего, компоненты платформы.NET и т.д.
, Если Вы хотите использовать NGEN для предварительного JIT код

Кроме этого, я склонен избегать GAC как чумы. Намного легче просто развернуть необходимый dlls с Вашим приложением через robocopy и т.д.; это дает изоляцию и простое развертывание.

16

ответ дан Marc Gravell 26 November 2019 в 22:10

Если Вы устанавливаете веб-приложения asp.net , и Вы - владелец и имеете полный контроль над машиной, то в некоторых случаях это могло иметь смысл, помещая Ваши блоки, которые Вы планируете на доля через экземпляры сайтов/сети в глобальном кэше сборок.

Вы могли существенно улучшить начальное время загрузки и использование памяти приложения на серверах, которые имеют много несколько экземпляров тех же приложений ASP.NET, если Вы помещаете блоки в GAC. По крайней мере, я видел это на наших серверах с десятками установок.

8

ответ дан Kristina 26 November 2019 в 22:10

Вот ссылка от Chris Sells, позвонившего, "Избегают GAC"

https://sellsbrothers.com/12503

, объяснение довольно долго, но короче говоря, эти два случая, которые он определяет,

Исправляющие критические ошибки, не касаясь затронутых приложений (и ничего не повреждая!)
Совместное использование типов во времени выполнения между блоками, развернутыми отдельно

Примечание: существует очень длинный предмет обсуждения в конце Chris сообщение , очень хороший список комментариев.

3

ответ дан Martin Schneider 26 November 2019 в 22:10

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

0

ответ дан davogones 26 November 2019 в 22:10

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

на случае определенно не GAC

на случае B, если Ваша библиотека будет постоянно изменяться, необходимо будет добавить каждую версию блока в gac каждый раз и обновить к тому блоку, происходит

на случае C рядом, выполнение позволяет Вам выполнять различные версии блока, и Вы не должны добавлять ничего для дифференциации версий.

Используемый, только если Вам действительно нужно к

0

ответ дан Oscar Cabrero 26 November 2019 в 22:10

Если вы отправляете повторно используемую библиотеку, состоящую из нескольких сборок, но лишь некоторые из них образуют фасад, вы можете рассмотреть возможность установки сборок в GAC, если пакет установлен на ПК разработчика.

Представьте, что вы отправляете 6 сборок, и только одна из этих 6 сборок содержит фасад, то есть остальные 5 используются только самим фасадом. Вы отправляете:

MyProduct.Facade.dll - это единственный компонент, предназначенный для использования разработчиками
MyProduct.Core.dll - используется MyProduct.Facade.dll, но не предназначен для использования разработчиками
MyProduct.Component1.dll - то же
MyProduct.Component2.dll - то же
ThirdParty.Lib1.dll - сторонняя библиотека, используемая MyProduct.Component1.dll
ThirdParty.Lib2.dll - то же
и др.

Разработчики, использующие ваш проект, хотели бы ссылаться только на MyProduct.Facade.dll в своих собственных проектах. Но когда их проект запускается, он должен иметь возможность загружать все сборки, на которые он ссылается, - рекурсивно. Как этого добиться? Как правило, они должны быть доступны либо в папке Bin, либо в GAC:

Вы можете попросить разработчиков найти вашу установочную папку и добавить ссылки на все сборки N , которые вы туда поместили. Это гарантирует, что они будут скопированы в папку Bin и будут доступны во время выполнения.
Вы можете установить шаблон проекта VS.NET , уже содержащий эти 6 ссылок . Это немного сложно, так как вы должны ввести фактический путь к вашим сборкам в этот шаблон до его установки. Это может сделать только установщик, поскольку этот путь зависит от пути установки.
Вы можете попросить разработчиков создать специальный шаг после сборки в файле .csproj / .vbproj , скопировав необходимые зависимости в папку Bin. Те же недостатки.
Наконец, вы можете установить все свои сборки в GAC . В этом случае разработчики должны добавить ссылку только на MyProduct.Facade.dll из своего проекта. Все остальное в любом случае будет доступно во время выполнения.

Примечание: последний вариант не заставляет вас делать то же самое при отправке проекта на производственные ПК. Вы можете отправить все сборки в папку Bin или установить их в GAC - все зависит от вашего желания.

Таким образом, описанное решение демонстрирует преимущество размещения сторонних сборок в GAC во время разработки. Это не связано с производством.

Как видите, установка в GAC в основном предназначена для решения проблемы размещения необходимых сборок (зависимостей). Если сборка установлена в GAC, вы можете считать, что она существует «рядом» с любым приложением. Это похоже на добавление пути к .exe в переменную PATH, но «управляемым способом». - конечно, это довольно упрощенное описание;)

6

ответ дан 26 November 2019 в 22:10

Другие вопросы по тегам:

.net install gac software-distribution

Похожие вопросы:

score 38 · Accepted Answer

Общие инструкции MS

никакой
никакой
никакой

GAC являются действительно репозиторием для Microsoft общие библиотеки.NET. Да, они позволяют разработчикам использовать его также, но как показывает опыт, если Вам не нужен GAC, не используйте его. сохраните вещи простыми и локальными, если это не причиняет боль.

я рассмотрел бы GAC только по причинам производительности, например, если у Вас есть некоторые огромные блоки, попытайтесь разместить их в GAC и NGEN их. Это должно значительно увеличить производительность. Microsoft делает это для всех стандартных блоков платформы.NET во время установки (теперь, Вы знаете, почему та установка занимает много времени). Paint.NET делает это также (для улучшения времени запуска их приложения). Однако большинство из нас не работает над огромными платформами или конкурентами фотошопа, поэтому большую часть времени, увеличение производительности от наличия блока в GAC минимально. Не стоящий отказа простое развертывание xcopy.
Некоторые разработчики могли бы использовать GAC, чтобы удостовериться, что пользователи с недостаточными полномочиями не могут удалить или изменить свои блоки.
Для других это могло бы быть по причинам управления версиями, но здесь необходимо действительно пересмотреть. Я не собираюсь повторять то, что было уже сказано, можно читать здесь почему .

И не забывают, что, после того как Вы хотите развернуться в GAC, для Вашего установщика будут нужны права администратора, можно в значительной степени забыть щелчок однажды развертывание, и т.д.