Несколько каталогов сборок .NET на моем компьютере (какой из них я использую?)

Возможно, вопрос о дампе (но я не очень опытный пользователь .NET), но, похоже, у меня есть идентичные (или почти одинаковые) версии .NET 4.0 в двух разных местах на моей машине:

  1. C:\Windows\Microsoft.NET\Framework\v4.0.30319

  2. C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0

    • В Visual Studio, когда я добавляю ссылку на проект C++/CLI, я попадаю в каталог №2.

    • Также в Visual Studio я могу указать путь сборки для разрешения #using References (что позволяет мне использовать символические пути на страницах свойств). Там можно использовать макрос $(FrameworkDir), который разрешается (по крайней мере, на моей машине) в C:\Windows\Microsoft.NET\Framework\, который в основном является каталогом №1.

Итак, какой из них я должен использовать?


visual-studio .net .net-assembly
person C Johnson    schedule 08.04.2011    source источник
comment
Неважно, лишь бы версия была правильной. Это одна и та же сборка, просто скопированная в разные места.   -  person richard    schedule 09.04.2011
comment
Я задаю этот вопрос, потому что я получаю предупреждение 4945 из-за некоторых недавних изменений, и мне нужно стандартизировать одно место сборки.   -  person C Johnson    schedule 09.04.2011

Ответы (3)


arrow_upward
2
arrow_downward

В первую очередь следует использовать диалоговое окно «Добавить новую ссылку» на вкладку .NET. Он настроен установщиком для представления правильных.

Для версии 4.0 всегда следует использовать версию 2, поскольку она содержит изолированные эталонные сборки версии. Они особенные, не просто копии, а урезанные до метаданных. Они предотвращают случайное использование открытого метода или свойства, добавленного в пакет обновления. И сломайте вашу программу, когда она запускается на машине без пакета обновлений. WaitHandle.WaitOne(int) печально известен этим, доступен только в .NET 2.0 SP2.

person Hans Passant    schedule 08.04.2011
comment
Да, я должен был присмотреться ко 2-й записи в моем списке, сначала я просто смотрел на имена папок. Позже я снова посмотрел на это и обнаружил только офисные сборки. Я отредактирую свою запись. - person C Johnson; 09.04.2011
comment
Теперь, когда я отредактировал свой исходный пост, ваш ответ также должен быть отредактирован, чтобы сказать ... всегда используйте 2. - person C Johnson; 09.04.2011

arrow_upward
1
arrow_downward

Это новая концепция, появившаяся в .NET Framework 3.5. Подробнее об этом можно прочитать в этом запись в блоге. Я предполагаю, что ваша платформа x64. Следовательно, у вас есть .NET Framework для x86 и x64, установленный на вашем компьютере в обеих папках Program Files.

person Svetlin Ralchev    schedule 08.04.2011
comment
Наше приложение является как 32-битным, так и 64-битным, так что это ответит на ваше первое предположение. Эта ссылка была очень полезной. - person C Johnson; 09.04.2011
comment
К битности отношения не имеет. Или 4.0, в ней используется новая схема эталонных сборок. Это уже не просто копии, они не содержат IL. - person Hans Passant; 09.04.2011

arrow_upward
1
arrow_downward

Из здесь

Кажется, что для управляемых проектов C++ компилятор попытается импортировать зависимости сборок, на которые ссылаются, что имеет смысл, но он не сможет распознать сборки, которые он уже импортировал. Затем общие зависимости будут конфликтовать друг с другом, поскольку они импортируются один раз с исходной ссылкой, а затем снова, если другая ссылка имеет этот общий проект в качестве зависимости.

Итак, в этом примере Common импортируется в Forms. Затем Common импортируется в Main. Однако когда Main импортирует Forms, он затем импортирует зависимости Forms; Обычный, второй раз.

Исправление состоит в том, чтобы использовать флаги «Использовать зависимости в сборке» и «Использовать в сборке» для каждой ссылки на проект VC (через лист свойств VC) и переключать их в соответствии с вашим случаем, чтобы устранить эту ошибку.

person richard    schedule 08.04.2011
comment
Это кажется более актуальным для моей проблемы, устраняя предупреждение 4945. Позвольте мне взглянуть на ваш ответ и посмотреть, поможет ли это. - person C Johnson; 09.04.2011