Come condividere risorse web comuni tra applicazioni Web in Visual Studio?

Question

Ho tre progetti di applicazioni Web che condividono una libreria comune di controlli server personalizzati. Condividere il codice dietro i file è facile: sono compilati in una DLL che faccio riferimento negli altri progetti utilizzando un riferimento al progetto. Ma come gestisco i file come JavaScript, fogli di stile e immagini? Sto cercando di fare questo "modo di Visual Studio" in modo che sia il più semplice possibile per capire e fare il debug.

La configurazione attuale è un po 'come questo:

 
CommonControlsWebApp 
+- CustomControls 
+- resources 
    +- images 
    +- scripts 
    +- stylesheets 

WebApp1 
+- resources* 

WebApp2 
+- resources* 

WebApp3 
+- resources* 

*) directory virtuale in IIS.

La directory virtuale su ogni app Web punta alla directory delle risorse nella mia CommonControlsWebApp. Questo è configurato in IIS. Visual Studio non è in grado di comprendere questo collegamento, quindi il debug richiede l'associazione manuale al processo IIS.

Un'altra soluzione potrebbe essere quella di includere ogni risorsa nella dll comune utilizzando WebResourceAttribute. Ma ciò trasformerebbe i collegamenti di src in qualcosa di simile a WebResource.axd? D = GUID quando visualizzo la fonte delle mie pagine web, e temo che questo renderà piuttosto complicato il debug.

Una terza soluzione sarebbe utilizzare Subversion per includere gli stessi file in tutte e tre le soluzioni. Nessuno nella squadra ci ha provato prima, quindi non siamo sicuri di quanto bene funzionerebbe.

Sento che mi manca una soluzione eccezionale e ovvia su come impostare i progetti. Eventuali suggerimenti?

Answer 1

Molti sviluppatori di controlli raggruppano le loro risorse usando il secondo metodo che descrivi - aggiungendoli come risorse incorporate nel file .dll. In questo modo, puoi distribuire i controlli senza dover copiare un sacco di cartelle e file in tutti i siti web che vogliono utilizzarli e accertarti che i percorsi delle cartelle corrispondano tutti, ecc. Inoltre, ottieni il vantaggio di una localizzazione/internazionalizzazione molto più semplice le tue risorse.

Tuttavia, la cosa WebResource.axd è un inconveniente. Di solito puoi "debugare" l'URL con qualcosa come Firebug per vedere cosa effettivamente è stato restituito dalla richiesta, ma sono d'accordo, può essere un problema se qualcosa non funziona correttamente. Un altro svantaggio è se si hanno dozzine di risorse per un controllo server, specialmente se vengono referenziate più volte ciascuna (si pensi ad una vista ad albero con centinaia di piccole immagini sui nodi) - quindi l'URL può aggiungere una tonnellata di byte effettivi alla finale Output HTML.

Se le esigenze di distribuzione/localizzazione superano le esigenze di ottimizzazione/debug, prenderei in considerazione l'inclusione delle risorse.

In caso contrario, si potrebbe sicuramente fare # 3 - copiare tutto nel sito Web utilizzando Subversion. Controlla SVN Externals per come configurarlo. Un po 'di tempo investito per impararlo ora potrebbe farti risparmiare molte cose!

Answer 2

Ho preso la via più semplice e ho inserito tutti i miei progetti in un'unica soluzione. Quindi ho creato un progetto WebUserControlLibrary in cui ho inserito tutti i controlli condivisi.

Per farli in un altro progetto, quindi configurato l'evento di build per ogni progetto per copiare l'UCS in una cartella speciale:

copy "$(SolutionDir)WebUserControlLibrary\UserControls\*.ascx" 
    "$(ProjectDir)ImportedUserControls\UserControls" 

E naturalmente riferimento alla WebUserControlLibrary dai progetti che ne hanno bisogno.

I vantaggi di questo approccio:

• debug in opere di Visual Studio,
• No duplicazione del codice

Svantaggi:

• soluzione Clunky :)
• Dopo aver cambiato un file .ascx, il progetto ha essere ricostruito. Ciò significa che non è possibile modificare l'html e aggiornare la pagina in IE e vedere direttamente i risultati.

Answer 3

Ho un paio di opzioni per gettare nel secchio:

Opzione 1: Utilizzare un progetto condiviso per le risorse: http://rion.io/2017/03/22/sharing-is-caring-using-shared-projects-in-asp-net/

Opzioni 2 Converti la tua libreria di classi in un pacchetto NuGet. Non credo che devi fare molto quando imballaggio diverso da quello seguito per includere tutte le cartelle ei file nella cartella di progetto withing NuGet:

c: \ nuget.exe imballare YOURPROJ.csproj -IncludeReferencedProjects prop Platform = AnyCPU -Exclude ** .tt -Exclude **. Txt