2012-02-29 3 views
3

У меня есть библиотека C# с большим количеством внутренней функциональности, отображающей только несколько общедоступных классов и интерфейсов. Я хотел бы поделиться этим кодом между несколькими проектами, и каждому проекту, возможно, потребуется расширить внутренние классы подклассами.Обмен кодом в C# между проектами без создания классов public

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

Это единственная реальная возможность создать копию исходного кода и сохранить эти файлы в синхронизации между проектами? Или можно каким-то образом поделиться кодом и по-прежнему получать отдельную библиотеку для каждого проекта, отображая только несколько предполагаемых общедоступных интерфейсов и классов?

Я использую Visual Studio 2010.

UPDATE

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

С точки зрения дизайна кажется, что ответ окончательно используется для сборки друзей.

+1

Вы получите немного никакой защиты от декомпиляции, сделав это. Некоторые пуристы скажут, что вы растягиваете принципы ООП, делая то, что вы пытаетесь сделать - это непротекающая инкапсуляция. –

+1

Модификаторы доступа не влияют на декомпиляцию. Вы можете использовать любое приложение отражателя, чтобы извлечь код C# из библиотеки DLL. Не тратьте свое время на этот аспект. – Timeout

+0

Это справедливый момент, в этом случае было бы разумнее использовать обфускатор, способный принимать несколько входных библиотек и объединять их вместе даже с их общедоступными соединениями, возможно ли это? –

ответ

3

Создать новый проект. Файл> Добавить> Существующий. Выберите существующие файлы кода. Нажмите кнопку «Открыть» и выберите «Ссылка».

, что делает классы внутренними и общественными, имеет абсолютную нулевую нагрузку на способность декомпилировать.

+0

Ваше последнее утверждение «внутреннее и публичное» не полностью правда. Большинство Obfuscators будут агрессивно переименовывать/обфускать внутренние классы/методы, тогда как они не будут переименовывать общедоступные классы. – Steve

+0

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

+1

@ b1naryj, как это решение сбросит его соглашение о пространстве имен? Если все, что он делает, это связывание необходимых файлов, сохраняющих все неповрежденное, если он не содержит ссылки на проект, в котором действительно находится код, imho это гораздо лучшее решение, чем сборка друзей :) – Jason

0

Я думаю, что это подвергает их слишком много, чтобы легко декомпиляции

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

«Прерывает дизайн» - еще одна проблема. Если вы хотите использовать этот код из отдельных проектов, то сделать их общедоступными - это именно то, что нужно сделать. Если вы не хотите, чтобы они были публичными, подумайте о том, какой интерфейс этот проект действительно хочет выставить снаружи, который все равно выполнит то, что вам нужно ... и постройте это api и сделайте его общественностью.

+0

Проблема в том, что есть две "общедоступные «пользователи: я, когда занимаюсь другими проектами, и фактическим конечным пользователем. –

+0

Я думаю, что ключом здесь является использование ФП классификатора «легким». Согласно моему комментарию на пост «Бу», любой уважаемый Obfuscator будет калечить/переименовывать внутренние и частные классы/методы, где они не будут делать то же самое для публичных. Означает ли это, что обфускация сборки не может быть декомпилирована - нет, но это означает, что пробиться через переименованные/искалеченные проблемы сложнее. Так что - «слишком легко», да. – Steve