Depuração DotNetNuke Módulos

Question

Qual é a melhor configuração de solução VS para DotNetNuke 4,8 desenvolvimento da comunicação inter-módulo?

Actualmente tenho uma solução com vários projetos de aplicativo Web em que para meus módulos DotNetNuke - e em cada uma delas tem páginas com os controles sobre eles como um equipamento de teste. Isso tudo funcionou bem até o ponto onde eu preciso os módulos para começar a falar uns com os outros usando IModuleCommunicator e IModuleListener -. Mas agora que eu estou fazendo a comunicação entre o módulo, a depuração não funciona dessa maneira mais

Estou curioso para saber como outras pessoas lidam com isso - há uma maneira de ter suas páginas de teste zombar um ambiente Nuke? Você testar direito em um site Nuke? Minha solução é em sourcecontrol usando VSS, então eu não quero adicionar o site Nuke integral como um projeto na minha solução, uma vez que me forçar a adicioná-lo ao controle de origem - e eu prefiro não ter um site Nuke completo em fonte de controle.

Eu tenho sido capaz de depurar, anexando ao processo de trabalho do IIS local, mas isso é um tipo de dor. Alguém tem alguma sugestão sobre a forma de aliviar a dor de depuração comunicação entre módulo?

Todas as sugestões seria muito apreciada.

Answer 1

Depois de muita tentativa e erro, aqui está o que eu acabei com -. E parece funcionar bem

1. Criado um evento Post-Build no projeto do módulo para copiar para o site Nuke local para depuração. Encontrado em "Propriedades / Build Events / Post-build linha de comando evento" ... copiar $ (TargetDir) $ (TargetName). * C: \ Inetpub \ wwwroot \ bin * / y
2. alterou as configurações da Internet para iniciar o site do localhost por padrão. Encontrado em "Propriedades / web / Servers / Use Custom Web do servidor" - alterado para " http: // localhost / "
3. criados eventos pós-Desenvolver a apoiar projetos de biblioteca de classe para copiar o arquivo para servidor web local, bem. Também poderia ter apenas mudado o evento pós-compilação no projeto do módulo para incluir outros arquivos.

Uma vez que aqueles configuração estavam no lugar, pressionando F5 para executar o projeto irá iniciar o browser e automaticamente anexar ao processo de trabalho do IIS.

Além disso, mantenha em mente que se você estiver executando isso em uma máquina com UAC (Vista, ganhar 2008, win 7), você vai ter que correr VS como um administrador desde a cópia para wwwroot e anexando ao processo de trabalho exigem privilégios elevados.

Answer 2

Temos a tendência de teste em um site DotNetNuke desenvolvimento, geralmente apenas anexar ao processo de trabalho do IIS para depurar (só porque é mais rápido do que a reconstrução com F5).

Eu acho que, em geral, quanto mais você estiver fazendo uso do que DNN fornece, menos você vai ser capaz de fora do teste de um ambiente DNN. Desde IMC é um processo especificamente DNN, você não pode ter um teste completo até que você deixe DNN ser o único a realizar o processo.