Rutas de reference del website de Visual Studio

En los proyectos del website de Visual Studio (en Visual Studio 2005 o posterior, no en proyectos de aplicaciones web donde todavía hay un file .csproj) ¿cómo se almacena la información de reference, y es posible controlarla en origen sin almacenar binarys comstackdos en el control de código fuente?

Si hace clic con el button derecho en un proyecto de website y selecciona Páginas de properties, la primera pantalla (Referencias) enumera todas las references del proyecto.

Las references de System. * Se enumeran como tipo GAC y otros files DLL se pueden enumerar como BIN o Project.

El problema ocurre cuando incluye algo como reference de proyecto y luego lo asigna al control de fuente (para nosotros, Subversion, ignorando los files .dll y .pdb).

Otro desarrollador obtiene código actualizado del repository y tiene que configurar manualmente todas estas references de proyecto, pero ni siquiera puedo determinar dónde se almacena esta información, a less que esté en .suo, que NO es amigable con el control de fuente.

Si hace reference a un file .dll por nombre de file a través de la pestaña de exploración, debe haber creado un file .refresh (nested en dll en BIN). Los colocamos en SVN y funciona muy bien (puede que tenga que editarlos manualmente para usar routes relativas).

Las references agregadas desde la pestaña .NET se agregan a web.config

Las references de proyecto se almacenan en el file de solución (.sln). Abra el file .sln y los verá en la list:

Project("{xxxxxxx-7377-xxxx-xxxx-BC803B73C61A}") = "XXXXXXX.Web", "XXXXXXX.Web", "{xxxxxxxx-BB14-xxxx-B3B6-8BF6D8BC5AFF}" ProjectSection(WebsiteProperties) = preProject TargetFramework = "3.5" ProjectReferences = "{xxxxxxxx-C3AB-xxxx-BBED-2055287036E5}|XXXXXX.Data.dll; ... 

Los proyectos de "website" en Visual Studio son algo extraño. Parecen ser un bash de atender a los desarrolladores web tradicionales, donde un "sitio" es solo un set de files en un directory. De la misma manera, cuando haces un proyecto de "Sitio web" en Visual Studio, no hay un file de "proyecto" real, como los proyectos de C # tienen un file .csproj. Sin embargo, todavía hay un file de solución (.sln). Normalmente, las references de ensamblaje .dll se guardan en el file de proyecto. Dado que un website no tiene uno, ¿a dónde van?

Referencias a otros proyectos

Si agrega una reference a otro proyecto, se realiza una input en el file .sln de la solución. Termina luciendo así:

 Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "WebSite1", "..\..\WebSites\WebSite1\", "{F25DB9D6-810D-4C18-ACBB-BFC420D33B20}" ProjectSection(WebsiteProperties) = preProject TargetFramework = "3.5" ProjectReferences = "{11666201-E9E8-4F5A-A7AB-93D90F3AD9DC}|ClassLibrary1.dll;" 

Referencias del sistema de files

Si explora el sistema de files y agrega un file .dll, entonces Visual Studio creará un file ".refresh" con el mismo nombre en la carpeta \ Bin. Este file es solo un file de text de 1 línea que indica la ruta desde la que se cargó el file. Entonces, por ejemplo, si agregué "MyAssem.dll" de …. \ libs, en la carpeta del website \ Bin, terminaría con 2 files copydos allí: MyAssem.dll y MyAssem.dll.refresh. El file .refresh contendría el text: "…. \ libs". En cada compilation, Visual Studio verificará la ruta en el file .refresh, y si existe un .dll más nuevo allí, sobrescribirá el que está en el directory Bin.

Advertencia: Visual Studio NO arrojará un error si el file no existe donde el file .refresh lo dice. Simplemente continuará usando el .dll que ya está en la carpeta \ Bin. Sin embargo, emitirá una advertencia.

Referencias del GAC

Si agrega un ensamblaje desde la Caché de ensamblados global, Visual Studio lo ingresará en el file Web.config, de esta manera:

 <comstacktion debug="false"> <assemblies> <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/> 

De nuevo, lo que hay que observar aquí es que Visual Studio asume que si el ensamblado estaba en el GAC en su computadora de desarrollo, ¡estará en el mismo lugar en time de ejecución! Eso puede Oracle.DataAccess problemas si tal vez tiene instalado Oracle.DataAccess en su máquina de desarrollo, lo que lo colocaría en el GAC, pero cuando implemente, simplemente copie el .dll en su lugar en la máquina de producción. Todavía intentará encontrarlo en el GAC y puede fallar en el time de ejecución.

¡Espero que esto ayude a aclarar las rarezas de los sitios web y cómo funcionan las references!

Yo uso copyprojectDll.ps1 powershell.

Mi estructura de carpetas está debajo

  • ClassLibraries
    Tercero
    Sitio web / Bin
    CopyprojectDll.ps1
    Website.sln

Las ClassLibraries son classs de código para mi proyecto, DAL .. El proyecto del website incluye solo files web, aspx, aspx.cs … ThirdParty son bibliotecas obligatorias, AjaxToolkit, etc.

Recopilo ClassLibraries.sln Ejecuto CopyprojectDll.ps1. Utilizo Website.sln después de esto.

El file de muestra de powershell está debajo.

$ folders = @ (); $ folders + = "IB.Security" $ folders + = "ClassLibraries / Core.Classes"

function CopyDllsToWebBin ($ dll_files) {if ($ dll_files -eq $ null) {return; } $ targetfolder = "./Kod/bin/"

 foreach($dll in $dll_files) { copy-item $dll.FullName -destination "$targetfolder" -force #-Verbose } 

}

function CopyDllsToThirdParty ($ dll_files) {

$ targetfolder = "./ThirdParty/"

 foreach($dll in $dll_files) { copy-item $dll.FullName -destination "$targetfolder" -force #-Verbose } 

}

$ dll_output_folder = "/ bin / debug";

foreach ($ carpeta en $ carpetas) {$ dll_files = Get-ChildItem -Path $ carpeta $ dll_output_folder -include * .dll -Recurse | sort-object Nombre CopyDllsToWebBin ($ dll_files) $ dll_files = Get-ChildItem -Path $ carpeta $ dll_output_folder -include * .pdb -Recurse | sort-object Nombre CopyDllsToWebBin ($ dll_files) $ dll_files = Get-ChildItem -Path $ carpeta $ dll_output_folder -include * .xml -Recurse | sort-object Nombre CopyDllsToWebBin ($ dll_files) "Copied $ folder $ dll_output_folder"

}

$ dll_files = Get-ChildItem -Path "ThirdParty" -include * .dll -Recurse | sort-object Nombre CopyDllsToWebBin ($ dll_files) $ dll_files = Get-ChildItem -Path "ThirdParty" -include * .pdb -Recurse | sort-object Nombre CopyDllsToWebBin ($ dll_files) $ dll_files = Get-ChildItem -Path $ carpeta $ dll_output_folder -include * .xml -Recurse | sort-object Name CopyDllsToWebBin ($ dll_files)

"ThirdParty copydo"

date