Есть ли у вас проблемы со ссылками на Visual Studio 2008 и C #?

Question

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

Я не могу понять, это проблемы с конфигурацией или проблема с Visual Studio 2008. Кто-нибудешь еще столкнулся с этой проблемой? Если да, можете ли вы что-то сделать, чтобы решить эту проблему?

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

Answer 1

Обычно я вижу это с одной из трех вещей

1. Пакеты на машине A, а не на машине B
2. Вещи в GAC (глобальный кэш сборок) на компьютере A, а не на компьютере B
3. Пакеты, не проверенные в системе контроля версий

Visual studio обычно хорошо обрабатывает реляционные пути, и у меня его не было просто проблема с путями.

Также убедитесь, что вы НЕ проверяете файлы .SUO и .csproj.user. Они будут оба обезьяны со ссылками иногда.

Answer 2

Да, ваши проблемы могут определенно быть вызваны путями к ссылочным DLL-библиотекам. Посмотрите на свойства DLL в папке References проекта (щелкните правой кнопкой мыши на элементе ссылки в вашем решении Visual Studio и выберите Propertiers), чтобы увидеть путь, который используется для DLL. Чтобы обойти эту проблему, один из вариантов - убедиться, что у всех одинаковый путь на локальном диске к указанным DLL. Вы также можете использовать страницу «Ссылочные пути» в свойствах вашего проекта, чтобы добавить дополнительные ссылочные пути к проектам.

Answer 3

Начните искать в своих .csproj файлах. У нас была эта проблема много лет назад, но вскоре мы узнали, что это была скорее ошибка оператора, чем что-либо еще. Определенные пункты, чтобы искать: <HintPath> и <ProjectReference>.

Answer 4

1. Ссылки на ваш собственный код в том же решении должны быть "Ссылки проекта". Никогда не добавляйте их как ссылки на DLL напрямую. Для вашего собственного / внутреннего кода добавьте к решению настолько, насколько это практически возможно. В противном случае возьмите стратегию 2C.
2. Следует обсудить ссылки на другой код и выбрать стратегию для каждого типа ссылок. У вас есть несколько вариантов:

а. Добавьте DLL напрямую как часть вашего решения, возможно, в каталог LIB. Проверьте это в системе контроля версий. Каждый член команды будет иметь постоянный опыт.

б. Для сторонних компонентов каждый должен, вероятно, запустить установочный пакет поставщика с согласованными путями установки и т. Д. (Многие сторонние компоненты устанавливаются в GAC, так что это становится частью ссылки. В противном случае это будет c: \ Program files \ etc и т. Д.)

с. Опубликуйте библиотеки DLL в общем каталоге, то есть в сетевой папке. Ссылочные DLL только по этому пути. Убедитесь, что для параметра Локальное копирование установлено значение true.

Убедитесь, что за стратегией следовало проверить XML-файл CSPROJ на наличие таких тегов, как ProjectReference и HintPath.

Наконец, каждый член команды должен знать об этом. Если кто-то делает что-то другое, вы будете чувствовать боль снова и снова с каждым новым «Get Latest».

Answer 5

Похоже, что указанные DLL не включены в систему контроля версий - я помещаю все внешние библиотеки в папку lib под корнем проекта и ссылаюсь на них. У меня никогда не было проблем с разрешением относительных путей в Visual Studio.

Answer 6

Пожалуйста, проверьте, если кто-то случайно зафиксировал / проверил какие-либо файлы csproj.user с их локальными путями внутри <ReferencePath> under <propertygroup>