Debug dei moduli DotNetNuke

Question

Qual è la migliore configurazione della soluzione VS per lo sviluppo della comunicazione tra moduli di DotNetNuke 4.8?

Al momento ho una soluzione con più progetti di applicazioni Web in esso per i miei moduli DotNetNuke - e in ognuna di quelle pagine sono presenti delle pagine con i controlli su di esse come cablaggio di prova. Tutto ha funzionato bene fino al punto in cui ho bisogno dei moduli per iniziare a parlare tra loro usando IModuleCommunicator e IModuleListener - ma ora che sto facendo comunicazione tra moduli, il debug non funzionerà più in questo modo.

Sono curioso di sapere come gestiscono gli altri: c'è un modo per far deridere le tue pagine di test in un ambiente Nuke? Fai il test direttamente su un sito Web di Nuke? La mia soluzione è in sourcecontrol utilizzando VSS, quindi non voglio aggiungere l'intero sito Web Nuke come progetto nella mia soluzione poiché ciò mi costringerebbe ad aggiungerlo al controllo del codice sorgente e preferirei non avere un sito Nuke completo in controllo del codice sorgente.

Sono stato in grado di eseguire il debug collegandomi al processo di lavoro IIS locale, ma è una specie di seccatura. Qualcuno ha qualche suggerimento su come alleviare il dolore del debug della comunicazione tra moduli?

Eventuali suggerimenti sarebbero molto apprezzati.

Answer 1

Dopo molte prove & amp; errore, ecco cosa ho finito con - e sembra funzionare bene.

1. Creato un evento Post-build sul progetto del modulo da copiare sul sito Nuke locale per il debug. Si trova sotto " Proprietà / Eventi di costruzione / Riga di comando evento di post-costruzione " ... copia $ (TargetDir) $ (TargetName). * C: \ Inetpub \ wwwroot \ bin * / y
2. Modificate le impostazioni Web per avviare il sito Web localhost per impostazione predefinita. Trovato sotto " Proprietà / Web / Server / Usa server Web personalizzato " - modificato in " http: // localhost / "
3. Creato eventi post-build su progetti di libreria di classi di supporto per copiare file anche sul server web locale. Potrebbe anche aver appena cambiato l'evento post-build sul progetto del modulo per includere gli altri file.

Dopo aver impostato tali impostazioni, premendo F5 per eseguire il progetto si avvierà il browser e si collegherà automaticamente al processo di lavoro IIS.

Inoltre, tieni presente che se lo stai eseguendo su una macchina con UAC (Vista, win 2008, win 7) dovrai eseguire VS come amministratore dal momento che sia la copia su wwwroot che il collegamento al processo di lavoro richiedono privilegi elevati.

Answer 2

Tendiamo a testare in un sito DotNetNuke di sviluppo, di solito semplicemente collegandomi al processo di lavoro IIS per il debug (solo perché è più veloce della ricostruzione con F5).

Penso, in generale, più stai facendo uso di ciò che DNN fornisce, meno sarai in grado di testare al di fuori di un ambiente DNN. Poiché IMC è un processo DNN specifico, non è possibile eseguire test completi finché non si consente a DNN di eseguire quello.