Референтни DLL файлове в ASP.NET без \Bin или GAC

Имам проект ASP.NET под контрол на източника (Subversion). Поради различни причини не искам да добавя директорията \Bin или нейното съдържание към контрола на източника, така че я оставям svn:ignored. DLL файловете се зареждат тук по време на компилация на Visual Studio и мога да започна с чиста директория и/или да изтрия цялото съдържание на тази директория и пак да имам успешна компилация.

Има два начина, по които препращам към код за включване в проекта:

  1. В елемента Web.config //configuration/configSections/system.web/compilation/assemblies. Мога да <add> всеки DLL, който е в GAC по този начин. Правя това за всички системни dll.
  2. Във VS Solution има настройка в Project/ProjectSection/ProjectReferences, която позволява ми да посоча включени препратки към други проекти в решението.

(Имайте предвид, че това е различно от неуеб проекти, където всички препратки към външни зависимости се съхраняват във файла на проекта. Няма файл на проекта за VS уеб проекти, така че те трябва да се съхраняват някъде другаде.)

Сега имам DLL, компилиран от трета страна, който бих искал да включа в проекта. За съжаление нито една от опциите за препратка, които открих, изглежда не работи за мен:

  1. Препращането чрез web.config/system.web/compilation/assemblies не работи, освен ако DLL не съществува в GAC; не можете да използвате път към файл. Наистина бих искал да избегна зависимост от GAC, тъй като това ще означава допълнителна стъпка, за да накарате проекта да работи на всяка целева машина.
  2. Не намерих начин да включа препратка към файл в решението, както мога да направя с препратки към проекти.
  3. Всеки път, когато добавя препратка към файл с помощта на диалоговия прозорец „Добавяне на препратка“ на VS, той просто копира DLL в директорията \Bin. Това няма да работи за мен, тъй като моята директория \Bin не е постоянна в различните системи.

Има ли друг начин да направя препратка към DLL файл и да го запазя?


reference asp.net web-config dll
person Craig Walker    schedule 13.01.2010    source източник

Отговори (5)


arrow_upward
5
arrow_downward

Благодаря за помощта. Аз съм нещо като MySQL n00blet, така че това беше хубаво въведение към подизборите. :)
person Neal    schedule 15.01.2010
comment
Решението, което предоставяте, не работи: не можем да добавим събитие за предварително изграждане към уеб сайт. - person remi bourgarel; 04.08.2011

arrow_upward
2
arrow_downward

Технически, в стъпка 3 се случва малко повече. Visual Studio копира DLL във вашата директория \Bin и добавя файл name.dll.refresh, който съдържа пътя до оригиналния DLL. При SourceSafe файлът .refresh е под контрол на версиите, така че когато настройвате нова система и получите най-новия код от SourceSafe, Visual Studio може да намери и копира DLL от посоченото място. Трябва да можете да поставите .refresh файла в svn и всичко да работи.

Освен това обикновено създавам директория \Common над моята директория на проекта, където поставям DLL файловете, и включвам тази директория в решението (и контрола на източника), така че всяка версия на моя проект в контрола на източника да има правилните DLL файлове .

person Jason Berkan    schedule 13.01.2010
comment
Чудех се за това. Въпреки това, за да вкарам .refresh в SVN, трябва да имам \bin и ако имам \bin, бих могъл просто да копирам DLL там. - person Craig Walker; 14.01.2010
comment
Поправете ме, ако греша, но дори и с \Common в решението пак трябва ръчно да копирате DLL и/или .refresh в \Bin, нали? - person Craig Walker; 14.01.2010
comment
.refresh се създава автоматично, когато добавите DLL чрез Добавяне на препратка. Докато го поставите в контрола на източника и имате DLL на едно и също място на всички машини, всичко работи. Други машини изтеглят .refresh от контрола на източника и по време на изграждане копират DLL от посоченото място. Предимството на поставянето на .refresh в контрола на източника вместо DLL е, че .refresh файлът не се докосва по време на компилация. DLL е, което води до ненужна проверка всеки път, когато компилирате. - person Jason Berkan; 14.01.2010

arrow_upward
0
arrow_downward

Единственият начин, за който се сетих досега, е моят скрипт за изграждане на NAnt да копира DLL от външна (с версии) директория lib в директорията \Bin преди изграждането. Това не ми харесва много, защото въвежда зависимост от процеса, която е извън Visual Studio: разработчиците трябва да гарантират, че библиотеката е копирана, преди да се опитат да изградят вътре във VS.

person Craig Walker    schedule 13.01.2010

arrow_upward
0
arrow_downward

Запазвам сборки на трети страни без изходен код в контрола на източника. В тяхната собствена директория извън проекта - `C:\Projects\3rdPartyAssemblies' По този начин всички проекти/разработчици, които имат нужда от тях, могат да ги препратят.

person Shawn    schedule 13.01.2010
comment
Но как да накарате препратката към DLL да се придържа към проекта? Това е същината на въпроса ми. - person Craig Walker; 14.01.2010
comment
Съжалявам, не съм сигурен дали те разбирам. Можете да включите препратка към файл по същия начин като препратка към проект, като изберете раздела за преглед. Той го копира в директорията bin, но все още поддържа препратката. - person Shawn; 14.01.2010
comment
Всъщност, при моето тестване, той не поддържа препратката извън присъствието на файла в директорията \bin. Ако затворите решението и изтриете DLL/.refresh, тогава, когато отворите отново решението, препратката ще изчезне от диалоговия прозорец. За разлика от препратките към проект или GAC, препратките към файлове се поддържат само от присъствието на файла в \Bin -- освен ако няма друг начин да го направите, което е, което питам. - person Craig Walker; 14.01.2010
comment
Виждам. Това проект за уеб приложение на ASP.NET ли е или просто обикновен уебсайт на ASP.NET? Тъй като създадох нов проект за уеб приложение, добавих препратка към външен dll, използвах dll в код, създадох, изтрих bin dir, стартирах отново и всичко заработи. - person Shawn; 15.01.2010

arrow_upward
0
arrow_downward

Препратките към проекти се съхраняват във файла .csproj или .vbproj, който трябва да бъде под контрол на източника. Файлът .refresh е напълно без значение и е само помощен файл за студиото. Ако създадете директория, локална за проекта или решението, и съхраните всички компилирани препратки, които все още не са в GAC, в тази директория, след това можете да добавите тази директория към контролата на източника и да направите справка директно от там. По този начин се гарантира, че всички разработчици имат най-актуалното копие (от контрола на източника) на .dll, когато извършат следващото си компилиране и това никога няма да повлияе на /bin.

Накарайте вашите разработчици да „Вземете най-новата версия“ ... вие сте сами за това. Все още не съм го разбрал.

Може би друга бележка.

person Joel Etherton    schedule 14.01.2010
comment
Уеб сайтовете нямат .csproj или .vbproj, следователно използването на .refresh файла. - person Jason Berkan; 14.01.2010
comment
Вие сте прав, сър. сгреших. Препратките за проект на уебсайт всъщност се съхраняват под ключа ProjectReferences във файла .sln (който уебсайтът трябва да изисква, но може и да не). Уф! - person Joel Etherton; 14.01.2010