Como configurar um ambiente de desenvolvimento DotNetNuke com controle de origem?

Question

A minha equipa está a desenvolver uma nova aplicação web DotNetNuke e gostaria de saber o que é recomendado para configurar um ambiente de desenvolvimento com controle de origem e compilações automatizadas? Gostaríamos de manter o código fonte DNN separado do nosso código fonte módulos personalizados e extensões.

O modelo Módulo DotNetNuke compilado para Visual Studio quer que armazenar o código-fonte no diretório DesktopModules do código-fonte DNN e saída para o diretório bin código fonte DNN. Não é a estrutura recomendada? Eu preferiria manter os arquivos em locais diferentes, mas, em seguida, torna-se mais difícil de executar e depurar localmente, uma vez que exigiria uma instalação do módulo para cada alteração. Além disso, como deve uma compilação automatizada implantar quaisquer alterações?

Como é que os outros configurar isso? Existe uma prática recomendada?

Answer 1

Nós normalmente furar a manter o código do módulo em uma pasta sob DesktopModules e construir para o diretório bin do site.

No controle de origem, nós apenas mapear os módulos individuais, ao invés de todo o site. Dependendo do que estamos trabalhando, um módulo pode ser um projeto inteiro no controle de origem, ou podemos ter vários módulos relacionados no mesmo projeto, vivendo ao lado do outro.

implantar automaticamente as mudanças é um pouco difícil no DNN. É altamente recomendável ter um script de construção que empacota seu módulo em uma forma instalável. Você pode copiar pacotes instaláveis ??para a pasta Install/Module do site, e obter o /Install/Install.aspx?mode=InstallResources URL, que irá instalar todos os pacotes na pasta.

Answer 2

Para o meu controle de origem, eu desenvolver módulos em seu próprio projeto. Este contém o código do módulo, o código de teste, código de provedor de dados (se aplicável) e qualquer outra coisa. Isso é verificado no controle de origem como qualquer outro projeto. Note-se que o projeto do módulo não contém links para um site específico DNN, e referências DNN são feitas no projeto para um comum diretório "bin" que as referências a sua construção alvo. Por exemplo, na pasta meus projetos, eu tenho \ bin460, \ bin480, \ bin510, \ bin520 etc. Cada uma dessas pastas contém um conjunto de binários para uma versão específica DNN. Dessa forma, você pode construir contra uma versão específica, mas prova contra qualquer versão você gosta.

O problema com a fonte-controlando um módulo no lugar em uma DNN instalação é de - às vezes não todo o código do módulo é facilmente isolado em um único diretório pai - não se presta bem a uma abordagem módulo PA - não é fácil de mudar o projeto para um diferente DNN versão para desenvolvimento ou teste -. Fácil de inadvertidamente partes de controle de origem da solução DNN, particularmente com soluções de controle de origem VS integrados

Esta abordagem compila rapidamente, porque você não está tentando compilar todo o projecto. Para implantação de teste Eu tenho um script de compilação que copia as várias partes do módulo em um site-alvo. Isto pode ser feito através da compilação (vincular o script de construção) ou simplesmente executar depois que você teve uma compilação bem-sucedida em uma janela cmd. Meu script de construção tem um interruptor ambiente 'target', para que eu possa dizer 'dnn520' para implantar a compilação meu teste dnn520 instalar. Note que você precisa criar manualmente a configuração do módulo antes de este trabalho, mas este é um esforço de uma só vez, e você pode usar o recurso de exportação para criar o seu .dnn módulo manifesto.

Para construir o seu pacote do módulo, investir o tempo em um script abrangente, que tomará as várias partes do seu diretório de origem, e zip-los em um pacote de instalação. Mantenha todas as peças na sua pasta de controle de origem, e copiá-los para um diretório temporário, em seguida, executar um utilitário de linha de comando zip (eu uso uma versão antiga da pkzip) para embalá-lo em um arquivo instalável.

Os benefícios desta abordagem é: - separação de código do módulo de código instalado - maneira simples de manter apenas o código do módulo de controle de origem (não tem que excluir todo o código do site) - capacidade para testar rapidamente os módulos em diferentes versões DNN - embalagens de script permite que você construa rapidamente e facilmente uma nova versão de um módulo para instalar testes / implantação

As desvantagens são - não pode usar o verde mágica 'go' botão no VS (tem que anexar manualmente depurador) - mais o tempo de configuração de desenvolver no local

Answer 3

Em resposta a resposta de bduke. Você deve, e não quer projectos de construção na pasta DesktopModules.

1. É onde todo o código fonte para o site fora da caixa vai.
2. É aí que você módulos serão "instalados" e, assim, se alguém "atualizações" ou re-instalar uma, em seguida, ele será substituído
3. Pode fazer atualização de seu aplicativo muito mais difícil. Muitos desenvolvedores não entendem que a idéia de não se tocam os arquivos de código-fonte original para modificar seu comportamento. Porque ele vai apenas ser substituído quando você executar uma atualização.

Se você quiser módulos construir, criar uma pasta solução chamada Módulos e colocar seus módulos do projeto separados lá.

1. Se você deseja depurar-los, fazer o ponto de saída de destino de depuração para a web \ pasta bin.
2. Se você deseja instalar / implantá-los. Construí-lo no modo de versão e instalá-los através do filtro Módulo / Extensão.