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

Ситуация следующая:

  1. Я хочу выпустить полный исходный код в библиотеку классов
  2. Я также хочу выпустить двоичные файлы, подписанные мной, с ключевым файлом, который я не хочу публиковать
  3. Я предоставлю пакетные файлы и этапы предварительной сборки, которые создают новый файл ключа локально, если он отсутствует, чтобы любой мог быстро начать использовать исходный код.
  4. Тестовый проект требует ссылки на внутренний класс в основном проекте.
  5. Чтобы получить доступ к внутреннему классу, мне нужно добавить атрибут [assembly: InternalsVisibleTo("...")] в файл AssemblyInfo.cs основного проекта
  6. Поскольку я подписываю выходные данные проекта, мне нужно указать часть PublicKey этого атрибута.
  7. Затем он будет привязан к ключевому файлу, который я не хочу публиковать.

Итак, как мне решить эту проблему?

Если я подпишу основной вывод проекта, а не тестовую библиотеку, и укажу только имя сборки в атрибуте InternalsVisibleTo, я получу эту ошибку времени компиляции:

Ошибка 1 Ссылка на сборку друга «Mercurial.Net.Tests» недействительна. Сборки, подписанные строгим именем, должны указывать открытый ключ в своих объявлениях InternalsVisibleTo. C: \ Dev \ VS.NET \ Mercurial.Net \ Mercurial.Net \ Properties \ AssemblyInfo.cs 22 31 Mercurial.Net

Таким образом, очевидно, что не подписывать выходные данные тестового проекта недостаточно.

Есть ли у меня единственный вариант - удалить настройки, которые подписывают проекты, и изменить файлы проекта как часть моего сценария сборки двоичных файлов? т.е. найти элемент <SignAssembly>false</SignAssembly> в файле проекта и изменить его перед сборкой?


.net code-signing internalsvisibleto assembly-signing
person Lasse V. Karlsen    schedule 14.11.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Можно ли выпускать файл SNK только для тестирования?

Затем у вас может быть два InternalsVisibleTo и переключиться, какой из них вы используете, с помощью #if, например:

#if FOR_RELEASE
[InternalsVisibleTo(... your private SNK ...)]
#else
[InternalsVisibleTo(... test SNK which you release ...)]
#endif

Затем вы можете установить FOR_RELEASE при создании своих сборок, которые хотите опубликовать.

person Pieter van Ginkel    schedule 14.11.2010
comment
Да, это похоже на план. - person Lasse V. Karlsen; 14.11.2010
comment
Я использовал только #if DEBUG, для RELEASE-build теперь требуется мой закрытый ключ, и я могу легко создать сценарий для этой части как часть сценария, который будет создавать мои двоичные файлы. Я все равно еще не там, так что займусь этой частью позже. Хорошие варианты из всех ответов здесь, но это было то, что я в конечном итоге сделал, поэтому принял это. - person Lasse V. Karlsen; 14.11.2010
comment
Ну вот и все. Рад, что смог помочь. - person Pieter van Ginkel; 14.11.2010

arrow_upward
1
arrow_downward

То, что я сделал с моими проектами ОС, просто: у меня есть частный SNK, который я использую только при сборке проектов для выпуска. Проекты подписываются только тогда, когда я компилирую для выпуска, и обычно проекты не ссылаются на SNK. Это упрощает использование атрибута InternalsVisibleTo, потому что без SNK он всегда работает.

person Steven    schedule 14.11.2010

arrow_upward
1
arrow_downward

На ум приходит #ifdef с ключом eval, который вам не нужен.

person Hans Passant    schedule 14.11.2010