Проверете двоичните препратки в решение

Търся начин за откриване на проблеми с препратки към асемблиране в голямо решение на Visual Studio:

  • Двоични препратки към лоши местоположения, като път, който не е в контрола на източника или в изхода на друг проект
  • Двоични препратки към множество версии на едно и също сглобяване в проекти в решението
  • Двоични препратки без път, които могат да бъдат пренасочени към GAC
  • Двоични препратки, които трябваше да бъдат препратки към проекти

Цялата история

Работя върху голям C# проект с почти 200 проекта. Един от проблемите, които се прокрадват с течение на времето, е, че се добавят препратки към сборки, но не винаги към същата версия или към правилното местоположение.

Например, даден проект може да получи препратка към System.Web.Mvc без подсказващ път, което го прави препратка коя версия е в GAC. Visual Studio (и Resharper) също ще предложи да добави липсваща препратка, но може да го направи, като добави препратка към изходната папка на друг проект.

Сега скорошната катастрофа на Windows Update остави някои членове на екипа мъртви във водата, неспособни да създадат решението. Както можете да си представите, това увеличи приоритета на управлението на референтните сглобки за нас.

За да открия някои от най-очевидните проблеми, вече съм настроил файл msbuild, който може да бъде включен във всеки csproj файл и ще открие лоши препратки.

Новите файлове на проекта обаче ще трябва да се редактират ръчно, за да включат този скрипт. Така че това неизбежно ще бъде забравено.

Това, което наистина бих искал, е да проверя всички файлове на проекта в решение за „лоши“ препратки по време на непрекъснатото изграждане, така че всички проекти да се проверяват винаги.

От известно време търсих решение като това в Google и намерих много инструменти за статичен анализ и анализ на код, но нищо за анализиране на файлове на проекта в решение.

Така че, преди да изляза и да напиша собствено решение, има ли начин да направя това вече?

Актуализация

За да почистя кодовата база, създадох малко код на ScriptCS, който ще сканира всички csproj файлове за препратки към сборки в пакети Nuget и ще ги коригира. Има го в GitHub.


static-analysis c# msbuild code-analysis
person Marnix van Valen    schedule 16.10.2014    source източник
comment
Въпросите, които ни карат да препоръчаме или намерим книга, инструмент, софтуерна библиотека, урок или друг ресурс извън сайта, не са по темата за Stack Overflow, тъй като обикновено привличат упорити отговори и спам. Вместо това опишете проблема и какво е направено досега за разрешаването му.   -  person EZI    schedule 17.10.2014
comment
@EZI Моля за конкретно решение на конкретен проблем с разработката на софтуер, бих казал, че се квалифицира като тема на StackOverflow   -  person Marnix van Valen    schedule 17.10.2014
comment
Имахме някакъв свързан проблем. С течение на времето нашето решение ще завърши с две или три версии на един и същ пакет NuGet, защото хората просто ще инсталират най-новия пакет, вместо да използват съществуващата версия. Както и да е... Накрая написах свой собствен инструмент за анализиране на пакетите и идентифициране на всички дубликати. Подозирам, че ще трябва да направите същото.   -  person Craig W.    schedule 17.10.2014

Отговори (2)


arrow_upward
3
arrow_downward

Можете да създадете пакет NuGet, чиято единствена цел е включване на персонализиран .targets файл в проект. Наскоро използвах тази стратегия за разрешаване на друг проблем (съобщения за грешка за липсващи .snk файлове).

Ако създадете подобен пакет, лесно е да щракнете с десния бутон върху вашия възел на решение и да проверите дали той е инсталиран във всички ваши C# проекти.

Ако вашият анализ е по-сложен и изисква използването на асемблиране (персонализирани задачи за изграждане) в допълнение към файла .targets, можете да използвате подход като този, който използвам аз за Antlr4 NuGet пакет, който съдържа задачи за изграждане, ресурси и персонализирани .props и .targets файлове, но няма действителни сборки, които са посочени от проекта, в който се инсталира.

person Sam Harwell    schedule 17.10.2014

arrow_upward
2
arrow_downward

Вместо да го добавяте към всички проекти във вашето решение, защо не създадете някакъв вид тест (единичен тест, компилиращ файл, каквото и да е), който може да вземе проектен файл като вход, да го анализира и да изведе грешка, ако OE или повече препратки са неправилни . Много по-лесно от добавяне (и проверка, ангажиране и т.н.) персонализирани стъпки за изграждане към файловете на проекта.

Дори ако бихте използвали пакет nuget, както беше предложено по-рано, пак ще трябва да проверите ръчно дали всички ваши проекти (200 проекта? Наистина ли?) препращат към пакета.

person brijber    schedule 17.10.2014