Este artigo foi traduzido por máquina.

SharePoint

10 Práticas recomendadas para criando soluções do SharePoint

E. Wilansky, T. Stojecki, P. Olszewski and S. Kowalewski

Download do código disponível na Galeria de código do MSDN
Procure o código on-line

Este artigo discute: Tirando proveito dos recursos internos do SharePoint Implantação de soluções do SharePoint Criar código de teste Identificação de marca SharePoint de escala e manutenção

Este artigo usa as seguintes tecnologias: WSS, Visual Studio Extensions for SharePoint3

Conteúdo

1. Saber quando entre a divisão
2. Tirar vantagem dos recursos do SharePoint nativo
3. Saber tarefas SPDev críticas e fontes de informações
4. Desenvolver soluções fora Server
5. Teste o código e Gerenciando dependências
6. Integração contínua e compilação automatizada
7. Ter SharePoint gerenciar definições de configuração personalizada
8. Saber onde Belong definições de configuração
9. SharePoint de marca de escala e manutenção
10. Desenvolva soluções implantável
Suficiente Said
Dicas adicionais
Usar links relativos quando possível
Criar páginas mestras personalizado
Lidando com projetos do InfoPath em uma compilação automatizada

Os desafios enfrentados pelos desenvolvedores que trabalham com o Windows SharePoint Services 3.0 (WSS) e o Microsoft Office SharePoint Server 2007 (MOSS) são como profundidade e largos quanto a plataforma SharePoint propriamente dito. Se você for novo para essa plataforma, as práticas que exploraremos neste artigo o guiará na direção certa. Se você for um desenvolvedor de SharePoint experiente, estas dicas devem ajudar a reforçar seu conhecimento, incentive discussões e finalmente levar à criação de aplicativos grandes de SharePoint. Além disso, fornecemos um número de referências online onde você pode saber mais sobre os tópicos que discutiremos.

1. Saber quando entre a divisão

Um problema que surge início em um projeto de desenvolvimento do SharePoint é a melhor maneira de interagir com outros sistemas. Como o SharePoint é uma plataforma de aplicativos compostos, essa pergunta é um que você provavelmente terá que responder com freqüência. Exibindo a arquitetura do SharePoint do nível de aplicativo da Web é a maneira mais fácil para ir sobre ele. Uma instância do SharePoint contém vários aplicativos da Web. Se você não estiver familiarizado com a arquitetura de aplicativos do SharePoint, você deve examinar"Visão geral de arquitetura do Office SharePoint Server 2007."

a Figura 1 mostra abordagens típicas para interagir com o SharePoint dentro de um aplicativo da Web, entre os aplicativos da Web e com sistemas externos. Abordaremos cada uma dessas interações no restante desta seção.

Figura 1 modelo de interação do sistema do SharePoint

use o modelo de objeto SharePoint quando você estiver escrevendo Web Parts, ASP.NET code-behind formulário, ou controles da Web que são executadas no contexto de um aplicativo da Web específico (consulte a Figura 1 ). O modelo de objeto SharePoint fornece um rico conjunto de classes através do qual interagir com o SharePoint. O Windows SharePoint Services 3.0 e o SDK do Microsoft Office SharePoint Server fornecem boa cobertura dessas classes.

Contexto é uma consideração importante quando manipulação da Web do SharePoint (SPWeb) ou descarte de site (SPSite). Para obter informações importantes sobre quando é necessário descartar explicitamente desses objetos usando o método Dispose ou usando instrução, consulte "Obter referências a sites, aplicativos da Web e outros objetos de chave"e"Práticas recomendadas: usando descartável objetos do Windows SharePoint Services."

Da perspectiva do modelo de objeto SharePoint, um aplicativo Web do SharePoint é um limite de segurança importantes. Normalmente, você não deve usar o modelo de objeto SharePoint para interações entre aplicativos Web do SharePoint. Consulte"Programação de segurança no SharePoint 2007"para obter informações sobre outros tópicos de segurança importantes do SharePoint.

ao fazer chamadas entre aplicativos Web do SharePoint e entre SharePoint e os aplicativos externos, como um aplicativo de cliente do Office, use a camada de integração de serviço da Web do SharePoint. Isso é uma boa abordagem quando tentar tarefas fora do servidor de desenvolvimento no Visual Studio. Consulte a seção " desenvolver soluções off-Server " para obter detalhes.

para interagir com outros sistemas, fazer chamadas para serviços Web externos é a abordagem mais comum, mas nem sempre é a melhor abordagem. Algumas alternativas podem ser mais fácil de implementar, e eles podem também terá a vantagem de ser significativamente mais rápida — por exemplo, fazendo chamadas para LDAP armazena via os serviços de diretório Microsoft estrutura de programação ou fazer chamadas para o Project Server por meio do ADO.NET para o banco de dados Relatórios do Project Server em vez de por meio a camada de serviços da Web do Project Server interface (PSI). Quando a fonte de dados é um serviço da Web ou banco de dados, utilize o BDC (catálogo de dados corporativos). Para obter mais informações, consulte a próxima seção neste artigo, "assumir vantagem dos recursos do SharePoint nativo".

o serviço de Microsoft é muito clara de mensagens em sua documentação que você deve não fazer chamadas diretamente para o SharePoint conteúdo e os bancos de dados de configuração. Mesmo assim, alguns aplicativos estão usando essa abordagem. Se o desempenho é o argumento para essa técnica de acesso ou simplesmente uma falta de conhecimento sobre a estrutura do SharePoint, há abordagens mais seguras.

O resultado final é que a Microsoft pode alterar o esquema base nesses bancos de dados, e pode haver mais de um conteúdo data­base por aplicativo da Web. Portanto, aparentemente operações de consulta direta benigno podem levar a soluções brittle. Em vez disso, aproveitar os métodos descritos neste artigo ou desenvolver uma estratégia diferente que evita inferior soluções que comprometer a integridade de suas implementações do SharePoint.

2. Tirar vantagem dos recursos do SharePoint nativo

Duas situações podem levar as equipes de desenvolvimento longe pois tiram vantagem dos recursos nativos no SharePoint. Em primeiro lugar, como o SharePoint é uma plataforma extensos, você talvez ache mais fácil criar soluções personalizadas em vez de gastar tempo para entender o que o SharePoint oferece sem codificação personalizada. Em segundo lugar, os proprietários de negócios tendem a criar requisitos detalhados, wireframes e comportamentos de aplicativos que deixa você com pouca flexibilidade quando se trata de usando configuração-a-inicial (OOB) recursos.

Mas embracing que a plataforma do SharePoint oferece geralmente paga dividendos, mesmo se o resultante produto deviates ligeiramente dos requisitos originais. As chaves para obter essa vantagem são para a equipe de desenvolvimento entender completamente a tecnologia e, mais importante, para apresentar claramente o valor e as vantagens e desvantagens de uma implementação específica ao proprietário da empresa.

Adquirir uma compreensão sólida dos pontos fortes e fracos do SharePoint é considerado mais fácil que realizado. O WSS e MOSS incluem SDKs que contenham documentação técnica, orientações, exemplos de código e as práticas recomendadas para soluções de programação no SharePoint. Além disso, quando informações é difícil encontrar, você pode usar .NET Reflector para examinar algumas dos assemblies de SharePoint Central. a Figura 2 mostra os membros da classe PeopleQueryControl no assembly Microsoft.SharePoint, incluindo o método IssueQuery. O controle de PeopleEditor (aka Seletor de pessoas) delega a responsabilidade pela consulta o armazenamento de identidade do SharePoint para PeopleQueryControl e permite que você substitua o método IssueQuery para modificar a implementação padrão. Como você pode ver na Figura, .NET Reflector oferece uma interna examinar como os componentes interagem.

A Figura 2 .NET Reflector mostrar o método IssueQuery do PeopleQueryControl

Equipado com conhecimento sobre os recursos da plataforma, você precisará articular as vantagens de uma implementação específica para os participantes de uma forma que o valor de seu investimento na tecnologia de sublinhados. É especialmente importante com uma plataforma o tamanho do SharePoint não para obter desligadas início sobre detalhes de implementação, mas para ajudar o cliente saiba o que é possível liberando mais cedo e a iteração com freqüência. Certifique-se que o cliente esteja familiarizado com os recursos do produto, colocando em local um mecanismo de comentários eficaz que mantêm envolvidas durante o ciclo de vida de desenvolvimento de software todo (SDLC).

imagine uma discussão sobre como exibir uma lista grande seleção de entidades para um usuário. Você pode implementar esse recurso de várias maneiras, como com o controle DropDownList do ASP.NET, o controle GridView, um controle personalizado ou um controle de terceiros. SharePoint propriamente dito também fornece um controle de seleção de lista grande na PeopleEditor ou sua classe base, o controle EntityEditorWithPicker, que você pode usar para essa finalidade. Esses controles de Web vir com vários ganchos de injeção de sua própria lógica personalizada e usando-os você tirar vantagem de uma interface de usuário sofisticada e intuitiva e criar uma experiência de usuário consistente no SharePoint. Consulte"Personalizando EntityEditorWithPicker"para um exemplo de como substituir métodos do controle da Web PeopleEditor.

Apresentar dados de linha de negócios (LOB) dentro do SharePoint é outra solicitação comum. Normalmente, comece identificando ouro-fonte dos dados e determinar a melhor maneira receber os dados no SharePoint. Criar proxies de serviço da Web ou estabelecer conexões do ADO.NET para bancos de dados é antigo chapéu para vários desenvolvedores. No entanto, o BDC é provavelmente uma alternativa melhor. Esse recurso do SharePoint permite que você ler dados de fontes de dados externas e apresentá-lo dentro do SharePoint. O BDC oferece suporte a uma ampla variedade de mecanismos de autenticação, permite que você crie associações entre entidades de dados e está fortemente ligado as infra-estruturas de pesquisa e lista SharePoint.

Além disso, o SharePoint inclui um conjunto de Web Parts para apresentar dados LOB por meio do BDC. E Embora o BDC não oferece atualmente suporte criar, atualizar e excluir operações diretamente, você pode criar aplicativos personalizados para executar essas operações e associá-los com o BDC através da interface de ações do BDC. Para obter mais informações, consulte os tópicos do catálogo de dados corporativos na barra lateral "Recursos".

3. Saber tarefas SPDev críticas e informações

O objetivo desta seção é elucidate tarefas comuns que cada desenvolvedor do SharePoint pode precisam concluir durante o desenvolvimento de software. Isso não é uma ferramenta de revisão, nem ele destina a promover uma ferramenta sobre outra. Em vez disso, fornecemos sugestões para ferramentas que você pode usar para concluir tarefas de desenvolvimento comuns do SharePoint.

soluções do SharePoint construção é uma abordagem que você vai querer levar. Ted Pattison soma-lo perfeitamente em sua coluna Espaço do Office"Implantação de solução com o SharePoint 2007"quando ele escreve, "Packaging backup e implantar seus esforços de desenvolvimento do WSS usando pacotes de solução é uma prática recomendada, e saber como fazer isso deve ser considerado uma habilidade essencial". Há várias maneiras para empacotar suas soluções do SharePoint, de criação manual de manifest.xml e diamond arquivos de diretiva (DDFs), para projetos do Visual Studio que usar as ferramentas do Windows SharePoint Services 3.0: Visual Studio 2005/2008 Extensions (VSeWSS).

Usando projetos VSeWSS é significativamente mais fácil que criar DDFs manualmente. No entanto, algumas alternativas são particularmente úteis para implantações comercial ou empresa, incluindo WSPBuilder, STSDev, SPDeploy e DDFGenerator. Avalie as várias ferramentas para localizar um que melhor atenda às suas necessidades. A chave é criar pacotes de solução para implantação em vez de implantar componentes de código manualmente.

comportamento do lado do cliente de depuração pode ser complicado e ferramentas como a barra das ferramentas do Internet Explorer Developer (ferramentas de desenvolvedor no Internet Explorer 8) certifique esse esforço significativamente mais fácil. Barra de ferramentas do Internet Explorer Developer é semelhante ao complementos Firefox, como FireBug. Outra ferramenta que é executado no Internet Explorer é o Web Development Helper. Ambas essas ferramentas são úteis para depuração JavaScript do lado do cliente, verificando estilos e percorrer o DOM. Se você precisar inspecionar interação com o IIS, o IIS 6.0 Resource Kit contém uma gama de ferramentas úteis. Por exemplo, WFetch fornece um recurso útil para inspecionar as informações de saída de página, como a saída de um manipulador HTTP personalizado ou informações de cabeçalho de autenticação para verificar qual protocolo de autenticação você estiver usando, conforme mostrado na Figura 3 .

A Figura 3 WFetch mostrar um cabeçalho de autenticação NTLM

Solucionar problemas de código do lado do servidor pode ser especialmente difícil no SharePoint porque erros são obscurecidos behind moderadamente amigável (embora não muito útil) páginas da Web ou nos logs após Web chamadas de serviço. Os mais importantes takeaways aqui precisam saber onde o SharePoint registra dados e quando fazer uso de um depurador estar familiarizado com ferramentas que podem ajudá-lo a solucionar problemas de seus aplicativos do SharePoint.

Um lugar para começar ao tentar determinar o que está causando um problema de aplicativo é os logs de eventos do Windows. Em alguns casos, você pode usar opções para o log de eventos crescente. Por exemplo, se você estiver trabalhando com um aplicativo que utiliza A autenticação Kerberos, você pode aumentar log do Kerberos para o log de eventos do sistema. Há vários recursos online excelentes explicando A autenticação Kerberos. Para obter informações concisas sobre Kerberos detalhados logon Windows Server 2003, dê uma olhada"Entradas de registro do protocolo Kerberos e chaves de configuração do KDC no Windows Server 2003."

Os logs do SharePoint e IIS são fundamentais para solucionar problemas de erros de aplicativos do SharePoint. Eis algumas informações breves sobre essas duas origens de registro críticas:

• Os logs do SharePoint estão localizados em <%CommonProgramFiles%> \Microsoft Shared\Web Extensions\12\LOGS do servidor. Você pode simplificar ler esses logs, instalando oFaça o recurso Visualizar.
• Os logs do IIS estão normalmente localizados em <%SystemRoot%> \System32\LogFiles. Examine as propriedades do IIS para que verifique o local raiz dos logs. Como cada aplicativo Web do IIS tem uma identificação exclusiva, você apenas coincidir a identificação do aplicativo IIS para o aplicativo da Web do SharePoint listado no IIS com o nome da pasta no diretório LogFiles.

Para log de aplicativo personalizado, considere a integração da Enterprise Library. Incorporando o registro do Enterprise Library e o Exception Handling Application Blocks em seu código, o destino de log, normalmente um banco de dados, pode conter o log de informações e exceção detalhes essenciais para solucionar problemas de seus aplicativos personalizados.

A ferramenta mais útil para depurar problemas de aplicativo personalizado é o depurador do Visual Studio. Se você tiver o Visual Studio instalada em seu servidor do SharePoint, você terá a capacidade de depuração F5. O ideal é que você não deve ter Visual Studio installed em produção ou sistemas de escritório do modelo. Além disso, você pode desenvolver software no locais de estações de trabalho e depurar soluções remotamente. Depuração remota é completamente suportada no SharePoint conectando-se ao processo w3wp que hospeda o aplicativo personalizado no IIS.

Para determinar qual instância de w3wp está executando seu aplicativo, abra um prompt de comando e execute IISApp.vbs no servidor Windows para identificar o processo de identificação (PID) que estão sendo executados seu aplicativo da Web do SharePoint. Em seguida, no Visual Studio, selecione a instância de w3wp com o PID correspondente.

Outra ferramenta útil éExibição de exceção. Quando você habilitar essa ferramenta em seu farm, ele substitui a mensagem de página de erro SharePoint amigável com um número de tipos de exibição de exceção. Para obter detalhes sobre como instalar e usar essa ferramenta, clique em "Exibir exceções" no link acima.

Se uma Web Part implantado estiver causando uma falha de carregamento de página, você pode abrir a página de Manutenção de Web Part por meio do acréscimo? conteúdo = 1 para o final da URL da página. Na página Manutenção, você pode fechar ou excluir a Web Part incorreta da página.

Finalmente, você pode habilitar o rastreamento em nível de aplicativo no arquivo web.config do seu aplicativo da Web. Consulte a discussão em"Habilitando o rastreamento de nível de aplicativo."

manter Estendendo a estrutura. O SharePoint é mais capaz de integração de soluções personalizadas em uma variedade de formas. Como o SharePoint está contido na parte superior de ASP.NET, ela herda os pontos de extensibilidade dessa plataforma. Com o lançamento do WSS 3.0/MOSS SP1, a Microsoft agora oferece suporte a estrutura do ASP.NET AJAX, que significa que você pode aproveitar as Extensões AJAX do ASP.NET e o AJAX Control Toolkit. Você pode facilitar o procedimento de instalação e configuração usando oAjaxify MOSS stsadm personalizado extensõesatravés de programação que adicionar ou remover entradas de web.config relacionados ao AJAX usando a classe SPWebConfigModification.

Com a estrutura no lugar, você pode usar o conjunto de controle do AJAX e melhorar a capacidade de resposta de suas páginas Implementando retornos de chamada do lado do cliente. Isso é particularmente importante ao fazer Web externa chamadas de serviço em Web Parts personalizadas. Consulte"Chamadas de serviço da Web do cliente com extensões AJAX."

jQuery é outra estrutura do lado do cliente que está ficando muita atenção, especialmente com o aviso recente pela Microsoft que ele terão suporte no Visual Studio. Como a biblioteca de núcleo jQuery está contida em um arquivo .js único, integrar SharePoint é simples. Consulte"jQuery Gerenciador de scripts"para uma abordagem para incorporar jQuery scripts uma página da Web do ASP.NET.

Se você estiver procurando informações sobre a integração do Silverlight, consulte"Acenda SharePoint com o Silverlight 2 Web Parts." Os autores exploram um exemplo de integração de um aplicativo do Silverlight com o SharePoint.

4. Desenvolver soluções fora Server

Sempre que possível, você deve criar suas soluções sem as dependências que SharePoint impõe de desenvolvimento com freqüência. Usando o servidor de desenvolvimento do Visual Studio, suporte a estrutura ASP.NET Web Parts, serviços da Web do SharePoint e ferramentas de terceiros, você pode executar a maioria do desenvolvimento em uma estação de trabalho padrão em vez de um computador que esteja executando o SharePoint.

Como o SharePoint é executado na parte superior do IIS e ASP.NET, o servidor de desenvolvimento da Web incluído no Visual Studio é um ponto de partida excelente para muito o desenvolvimento do SharePoint. Por exemplo, você pode desenvolver Web Parts, manipuladores HTTP e controles da Web neste, relativamente falando, ambiente simples.

Algum trabalho inicial está envolvido em Configurando o ambiente para hospedar seus componentes. Por exemplo, para desenvolver com eficiência uma Web Part de ASP.NET, você deve criar um projeto de classe para hospedar a Web Part, um projeto de aplicativo de Web do Visual Studio, e, opcionalmente, um teste de unidade projeto. Incluímos um exemplo dessa configuração na solução Visual Studio SPTips (fornecida com o código de exemplo deste artigo) que você pode usar para fora do servidor de desenvolvimento de Web Part.

No projeto da Web Part, o construtor padrão contém uma linha que define a propriedade ExportMode da Web Part:

public WebPartOffServerExample()
{
    this.ExportMode = WebPartExportMode.All;
}

Esta linha lhe permite gerar um arquivo de implantação .WebPart com base nas propriedades que configurar para a parte da Web, como mostrado naA Figura 4 .

A Figura 4 A Web Part exportar a opção de menu

Em seguida, você pode importar a Web Part no SharePoint por meio desse arquivo de implantação ( Figura 5 ).Você não deve usar o tipo de arquivo de importação compatível com versões anteriores de SharePoint 2003, .dwp.O esquema XML subjacente para um .dwp não como rich e requer que você referenciar o assembly Microsoft.SharePoint no início do SDLC.

A Figura 5 A Web Part importada para o ponto de compartilhamento

Observe que você pode garantir a criação de .WebPart arquivos de implantação por herança da classe WebPart no namespace System.Web.UI.WebControls.WebParts em vez do namespace Microsoft.SharePoint.WebPartPages.(Para obter exemplos de quando convém para herdar da classe de WebPart do SharePoint, consulte a fonte na barra lateral "Recursos".)

Microsoft apresenta um subconjunto significativo do modelo de objeto SharePoint por meio de serviços da Web.Usando serviços da Web do SharePoint para acessar o modelo de objeto permite que você desenvolver uma solução sem uma dependência no acesso direto aos assemblies do SharePoint.SharePoint hospeda os serviços da Web no diretório virtual _vti_bin em cada servidor Web front-end (WFE).

No Visual Studio, você adicionar serviços da Web do SharePoint a uma solução da mesma maneira como você faz qualquer referência de serviço da Web.URLs de serviço da Web do SharePoint ter o seguinte formato:

http://<SharePointServer>:port/[sites/][SubSite/]_vti_bin/WebService.asmx

onde <sharepointserver> é o URL associado ao aplicativo da Web. Por exemplo:

https://www.contoso.com:35000/_vti_bin/Lists.asmx

Quando você adiciona uma referência de serviço da Web, o Visual Studio cria classes de proxy para o serviço e os tipos de dados usados pelo serviço.Para obter mais informações sobre interagir com esses serviços da Web, por favor, consulte"Tópico SDK do WSS 3.0: diretrizes do serviço da Web"e"Serviços Web do SharePoint."

implementar uma arquitetura de três camadas furthers o objetivo de isolar o código e remover dependências em SharePoint e outras fontes externas.Essa abordagem pode melhorar sua capacidade para desenvolver desativar servidor por abstraindo os negócios, acesso a dados e lógica de interface do usuário uns dos outros, permitindo que você dividir o código em partes gerenciáveis e reduzir dependências entre elas.Essa abordagem também produz mais códigos de teste; mais sobre isso na seção "teste código e Gerenciando dependências".

Existem outras ferramentas que você pode usar.Remover a dependência no SharePoint entre a base de código todo é irreais.Desenvolvendo para o SharePoint desativar servidor geralmente requer o uso de uma instância do SharePoint, hospedado em uma máquina virtual, logo no início a SDLC.Com o crescimento de desenvolvimento do SharePoint, várias ferramentas foram criadas para lidar com essa dependência significativa.Uma dessas ferramentas é SharePoint de soluções de bambu no auxiliar de instalação do Vista.Esta ferramenta permite que a instalação do WSS 3.0 SP1 ou do MOSS 2007 SP1 no Windows Vista, usufruindo do recurso para desenvolver soluções do SharePoint-dependentes sem a necessidade de Windows Server.

Microsoft não oferece suporte à execução SharePoint dessa maneira.No entanto, essa abordagem tem resonated na comunidade de desenvolvimento do SharePoint porque ajuda a reduzir o espaço que cria essa dependência no SharePoint.Para obter mais informações, consulte" Como instalar o Windows SharePoint Services 3.0 SP1 no Vista x 64/x 86 ."

5. Testar código e gerenciamento de dependências

A adoção ampla de estruturas de teste de unidade e ferramentas de teste relacionadas naturalmente fez seu caminho para o desenvolvimento do SharePoint.Testes de unidade e testes de integração são duas categorias de teste principal.Ambos os tipos de teste apresentam características diferentes e exigem o uso de diferentes ferramentas e técnicas.

quando escrever unidade ou testes de fora do servidor, ele é considerada uma prática recomendada para simular dependências externas com substituições, como os stubs ou simulações.Passando em objetos que imitam cantos de dependências externas, o teste se torna mais rápido e mais concentrado no comportamento que você está testando.Para ser eficiente, essa abordagem requer que você seguem os princípios do design de teste, orientada a objeto, ou usar uma estrutura especializada para isolar fortemente fraco componentes de sua solução.

Identificar os comportamentos e regras comerciais que são independente infra-estrutura e verifique se que você tem uma estratégia para testá-los no isolamento.Para isolar interações com o SharePoint, um banco de dados ou um serviço da Web, você pode introduzir o padrão de repositório para abstrair os detalhes do sistema back-end.Esses objetos de repositório podem ser passados em componentes de nível superiores usando inversão de controle (IoC) e os princípios de inclusão (DI) de dependência.Para obter informações sobre IoC e DI, consulte"Controle de suas dependências de software para aplicativos mais flexíveis."

Para aumentar a testability de sua apresentação componentes implementar o padrão Model-View-Presenter (MVP).Para obter mais informações sobre padrões de código de teste, consulte"Design de Testability."

Outros principais desafios que enfrentam os desenvolvedores do SharePoint ao negócio de teste de unidade com o SharePoint modelo de objeto.Simplificando, testar esses componentes no isolamento é uma tarefa não trivial.Ele é um resultado direto de um número limitado de interfaces e abstrações, bem como um número alto de classes lacradas — classes com dependências internas ou sem um construtor público.

Um produto equipado para lidar com essas limitações é TypeMock Isolator, uma estrutura mocking comercial que permite a simulação de classes sealed, concretos, estáticos ou construídos internamente.Para outras estruturas mocking como aplicável, você precisará seguir os padrões e os princípios que já tenha eluded para.TypeMock Isolator ou sua nova versão de específico do SharePoint, Isolator do SharePoint, irá solucionar essas limitações e permitem cobertura de código maior sem depender de uma instância em execução do SharePoint.Os padrões e práticas (P&P) equipe também usaTypeMock Isolatorno seuArquitetura de referência guia do SharePoint.

em algum momento, que você terá que escrever testes de integração que dependem do modelo de objeto SharePoint.É recomendável para gerenciar seus testes de unidade que são independentes de servidor daqueles que são dependentes do servidor.

Você pode usar o Editor de lista de teste no Test Manager no Visual Studio para separar os testes de unidade e a integração.Por exemplo, você pode criar duas listas de testes: servidor dependente e independentes de servidor (veja a Figura 6 ).Essa abordagem permite que você selecione o conjunto de testes a ser executado, dependendo se você está no servidor.

A Figura 6 Mostrar O Editor de lista de teste uma lista de teste categorizado

Em casos em que o Visual Studio está instalado no servidor, você pode executar e depurar os testes no IDE ou usar a ferramenta de linha de comando MSTest.exe para executar testes dependentes do servidor.Infelizmente, MSTest não executa a menos que o Visual Studio seja instalado no servidor.Nossa esperança é que uma versão futura do MSTest não inclua essa dependência pesada.

MSTest.exe permite que você especifique quais testes que você deseja executar através de argumentos de linha de comando.Quando você executa MSTest.exe, especifique o os / testcontainer ou a opção / testmetadata.Usando a opção / testmetadata, você pode especificar quais testes serão executados.Por exemplo, para executar todos os testes dependem do servidor, digite:

MSTest /testmetadata:SPTips.vsmdi /testlist:ServerDependentTests

Para executar um teste específico em que os testes dependem do servidor, digite:

MSTest /testmetadata:SPTips.vsmdi /test:GetTasks_ShouldReturnTasks

Para obter exemplos de em servidor testes e testes usando uma estrutura mocking, ver o código de exemplo na solução Visual Studio SPTips incluído no download do código deste artigo.

Compilação automatizada e de integração contínua de 6.

Manter o código no controle de origem, contar com integração contínua e automatizar o processo de compilação são essenciais etapas eficiente lançamento dos ativos de código de alta qualidade. SharePoint faz a instalação desse desafio de ambiente, digamos que o menor. Para esta dica, o ponto de partida mais importante é o " Visão geral de desenvolvimento de equipe"tópico.

Posteriormente na visão geral, você verá o tópico do guia do SharePoint " How to: criar uma solução de implantação e compilação automatizada com o Team Foundation Server Build. " Este tópico se concentra na criação de destinos de compilação para criar e implantar soluções. Embora esse método tenha mérito, não é utilizada quando os TFS cria e servidores do SharePoint não residem no mesmo ambiente, como geralmente é o caso na empresa. Criar seus pacotes de soluções usando destinos limita o uso de pacotes para o ambiente de compilação automatizada e, portanto, não incentive desenvolvimento inicial e o teste de pacotes por desenvolvedores.

A alternativa é usar eventos Post-Build dentro do Visual Studio. Podem configurar os eventos de pós-compilação para executar as mesmas etapas embalagem como os destinos do MSBuild e permitem aos desenvolvedores criar pacotes para implantação em seus próprios ambientes de modo seguro. Essa abordagem também funciona com ferramentas de terceiros, como WSPBuilder e STSDEV.

Ao implantar para a empresa, talvez também seja necessário considerar versão pacotes de soluções. Amarrando a versão da solução para a versão de compilação atual é uma abordagem. Isso pode ser facilitado por meio de aplicativo personalizado código executado no evento AfterBuild MSBuild ou a partir do evento pós-compilação. Além disso considere solução identificações na compilação automatizada e se deseja gerar novas IDs com cada compilação. Essa decisão afetará a capacidade de atualizar soluções no futuro. Como regra geral, gerar nova solução identificações quando altera de versões de montagem. Caso contrário, mantenha a solução identificações o mesmo onde a versão identificações são estáticas entre cria.

Em vez de repetidas informações que você pode obter o SharePoint Server Developer Center, irá aumentar esta dica, enfocando como simplificar ainda mais o processo de compilação automatizada. No SharePoint guia tópico "como para: criar um automatizada criação e implantação solução com Team Foundation Server Team Build" a equipe de P&P pressupõe que você está usando VSeWSS/extensões.

Enquanto VSeWSS é um acréscimo fantástico ao Kit de ferramentas do desenvolvedor do SharePoint, com recursos como o painel WSPView que lhe permite configurar a solução rapidamente, já achamos que não é adequado para médias e grandes implementações ou equipes que seguem as metodologias de desenvolvimento ágil.

A documentação de equipe SharePoint P&P orientação informa que VSeWSS fornece implantação de um clique e depuração F5. O recurso de implantação de um clique certamente é parte VSeWSS, mas a capacidade de depuração F5 tem mais a ver com o fato de que você deve executar Visual Studio local para a instância do SharePoint. Este é um requisito para a instalação VSeWSS. Embora você possa usar um registro a ataques de hackers para obter VSeWSS instalado em uma estação de trabalho, a maioria dos benefícios a extensão é perdida quando instalado em uma estação de trabalho.

A documentação também informa que muitas ferramentas como WSPBuilder e STSDEV requerem que os desenvolvedores manter arquivos Feature.xml e manifest.xml para embalagem de solução do SharePoint em um pacote de solução da Web. Na realidade, essas ferramentas estão em constante evolução. Por exemplo, WSPBuilder agora inclui extensões que permitem fácil manutenção de Feature.xml e manifest.xml no Visual Studio 2005 e 2008.

VSeWSS é mais útil quando você não tiver certeza de como estruturar um projeto do SharePoint. Por exemplo, convém usar um tipo de projeto VSeWSS para determinar a estrutura de uma Web Part ou um projeto de fluxo de trabalho do SharePoint. Depois que você souber como, você pode tomar essas informações como na não gerenciada e movê-lo para um tipo de projeto muito difundidos. As principais questões usando VSeWSS para um meio para projeto de grande porte são os seguintes:

• As extensões são desenvolvidas para ser instaladas em uma instância do Visual Studio em execução em um servidor do SharePoint. Portanto, eles terão uma dependência difícil no WSS.
• Os desenvolvedores que não tem instalado o VSeWSS não terão os tipos de projeto especial que VSeWSS cria e não poderá abrir os projetos que dependem delas.
• Reconstruir uma solução é feita mais complicada pelo VSeWSS.

A documentação de orientação sugere que a outra abordagem é criar um arquivo de solução do SharePoint para cada solução do Visual Studio manualmente, juntamente com a implantação manifesto manifest.xml. No entanto, ferramentas, como WSPBuilder permitem automatizar essa etapa dentro de sua compilação.

As chaves para uma compilação automatizada bem-sucedida são:

• Use tipos de projeto padrão do Visual Studio (isto é, projetos de classe de Web Parts) para que todos os desenvolvedores podem facilmente abrir um projeto.
• Estruture o projeto de código para que a embalagem de solução é integrada ao projeto, como mostrado na Figura 7 . Não é necessário para criar um projeto de implantação separada.
• Configurar um evento de pós-compilação executar WSPBuilder ou outro automatizado solução criando ferramenta para criar o arquivo de solução do SharePoint. Essa abordagem funciona para implantação de local da solução e para o processo de compilação automatizada.
• Use condições de macro para controlar as partes do seu evento de pós-compilação que chamado dependendo de onde a compilação está ocorrendo.
• Uma compilação automatizada é mais complicada por um projeto do InfoPath. Para obter informações sobre isso, consulte a dica "lidando com o InfoPath projetos em uma automatizada compilação" na versão online deste artigo.

A Figura 7 estrutura de compactação solução integrada para o código de projeto de Web Part download

não implantar cache de assembly global (GAC) até que você mova para um ambiente de integração. Manter os assemblies na pasta BIN facilita depuração aplicativos SharePoint personalizados significativamente. Há determinados tipos de projeto que não se encaixam nesse modelo, como manipuladores de eventos do SharePoint e recursos do SharePoint. Colocando módulos (assemblies) compatível na pasta BIN, os desenvolvedores em um ambiente de desenvolvimento compartilhado não precisam endure freqüentes redefine o IIS após a cada implantação.

Algumas dicas para a execução assemblies do SharePoint a partir o BIN são:

• Decore seu conjunto com o atributo [assembly:System.Security.AllowPartiallyTrustedCallers].
• Configurar diretiva de segurança (CAS) de acesso ao código personalizadas ou definir web.config para confiança total, conforme mostrado aqui:

<system.web>
  <trust level="Full" />
</system.web>

(Observe que definir o nível de confiança como completo é apropriada somente para o desenvolvimento interno ou local onde os ativos de código, eventualmente, irão ser implantados no GAC.)

• Assine seus assemblies para implantação eventual ao GAC.

SharePoint ter de 7. Gerenciar definições de configuração personalizada

Como qualquer aplicativo, soluções do SharePoint dependem das configurações para funcionar corretamente. Um aplicativo personalizado com apenas algumas configurações pode ser fácil de gerenciar manualmente. Por outro lado, ao desenvolver a empresa ou aplicativos comerciais no SharePoint, o número de configurações pode ser considerável.

Como resultado, conhecer os tipos de configuração diferente e como gerenciá-los é importante desenvolver, implantar e gerenciar aplicativos. A melhor abordagem é aumentar o número de configurações que gerencia o SharePoint e reduzir o número de configurações gerenciadas manualmente.

Conhecer os tipos de configurações ajuda a identificar onde as configurações pertencem. As definições de configuração do SharePoint geralmente se enquadram em três categorias: principais, personalizados e configurações do SharePoint.

Configurações principais são usadas em um aplicativo Web do SharePoint. Blocos de aplicativos do Enterprise Library e configurações de serviços Web externas são exemplos de configurações de núcleo comum.

Configurações personalizadas são para componentes de compilação personalizada. Essas configurações são usadas para fornecer configurações para o componente personalizado e não são compartilhadas fora do componente. Por exemplo, configurações personalizadas podem ser usadas para fornecer configurações de servidor de diretório para uma pesquisa LDAP.

As definições do SharePoint são necessárias para fazer com que a solução trabalho dentro do SharePoint. Configurações nesta categoria incluem entradas SafeControls, SessionState personalizações ou registrando HttpModules.

Após você categoriza suas configurações, você pode implantá-los para os locais corretas para gerenciá-los. O objetivo é reduzir o número de configurações gerenciadas manualmente. Permitir que o SharePoint lidar com as configurações reduz o número de erros que podem ocorrer quando os aplicativos são implantados.

Configurações de núcleo melhor são gerenciadas no controle de origem. Isso permite manter um histórico de configurações enquanto fornece uma única fonte de verdade para as configurações. Além disso, essa abordagem permite para manter versões distintas dos arquivos de configuração para ambientes de desenvolvimento, teste e produção.

Você pode automatizar a instalação de configurações personalizadas e o gerenciamento usando as ferramentas de modelo e a implantação de objeto SharePoint. Use a classe SPWebConfigModification, implantação de solução e o Diretório CONFIG sob a seção de 12 do SharePoint para formar a estratégia de gerenciamento de configuração. Consulte a seção "criar soluções implantável" neste artigo para obter detalhes adicionais sobre a implantação de soluções.

A classe de SharePoint SPWebConfigModification permite que você registrar por programação configurações no web.config de um aplicativo da Web do SharePoint. Usando SPWebConfigModification, você pode escrever um aplicativo de console ou a extensão de stsadm para lista, adicionar ou excluir entradas de configuração. Essa abordagem permite para modificação rápida e consistente de grandes conjuntos de definições de configuração do SharePoint. A enumeração SPWebConfigModificationType nessa classe contém três valores especificando o tipo de modificação feita: EnsureChildNode, EnsureAttribute e EnsureSection. Tenha cuidado ao usar EnsureSection porque as entradas adicionadas com essa enumeração não podem ser facilmente removidas. Para obter mais informações, consulte" Automatizar a implantação de aplicativo da Web com o SharePoint API."

O diretório do SharePoint CONFIG permite que você declarativamente registre configurações mantendo XML arquivos nesse diretório. WSS aplica configurações nos arquivos XML para o arquivo web.config quando o SharePoint cria um aplicativo da Web. Configurações nessa pasta são aplicadas a todos os aplicativos da Web. Para obter informações sobre essa abordagem, consulte" Gerenciando personalizações de Web.config."

8. Saber onde Belong definições de configuração

A dica anterior explorou diferentes tipos de definições de configuração do SharePoint e como gerenciá-los. Como um aplicativo for promovido a ambientes, como de teste para a produção, as alterações nas configurações configuração, especialmente aqueles apontando para sistemas externos, podem se sentir como areia alternância sob os pés. Saber onde configurações pertencem pode colocar o gerenciamento de configurações de ambiente em Terrestre mais sólida.

desenvolvimento de aplicativos compostos aumentou confiança em configurações. O poder e a facilidade de uso de configurações, indiscutivelmente, levou a seu uso em excesso. Uma maneira de reduzir constantes alterações nessas configurações é aplicando o paradigma de convenção de configuração sobre pelo inferir em vez disso, valores de itens como convenções de nomenclatura. Descrevem um exemplo do paradigma de convenção sobre de configuração na seção "contínua integração e automatizada compilação" demonstrando como integrar pacotes de solução do SharePoint em seus projetos do Visual Studio. Um exemplo relacionado desse paradigma é exibido na dica conteúda da Web, "usar relativo links quando possível."

configurações específicas de instância são exclusivos a cada instância de uma Web Part. Por exemplo, você pode ter uma Web Part que exibe uma lista de projetos na página de um gerente de programas, enquanto o na página de um desenvolvedor ele mostra detalhes de projetos e tarefas. Configurações específicas de instância melhor são armazenadas em uma Part ferramenta personalizada ou nas propriedades de ferramenta Part diversas uma Web Part.

definições de configuração que está sendo usadas por mais de um componente são consideradas configurações globais. Exemplos de configurações nesta categoria são URLs para serviços Web externos, configurações de objeto de negócios e configurações de dados. Essas configurações são melhores mantidos em web.config e gerenciada conforme descrito na seção "com SharePoint gerenciar personalizar configuração configurações".

SharePoint 9. marca de escala e manutenção

Marca o site do SharePoint fornece aos usuários com a indicação visual mais óbvia de finalidade do aplicativo. Identificação de marca envolve trabalhar com vários artefatos, como páginas mestras, páginas de conteúdo, layouts de página, as definições de site e CSS. Para uma dica sobre como criar páginas mestras personalizado, consulte a dica on-line "Criando páginas de mestre personalizada".

Recursos

Microsoft Office SharePoint Server 2007 e o Windows SharePoint Services v3

catálogo de dados corporativos

SharePoint 2007: BDC — O catálogo de dados corporativos

classe WebPart (Microsoft.SharePoint.WebPartPages)

Certifique-se de que sua estratégia de escala e a manutenção do aplicativo leva em consideração como você gerenciará esses artefatos de identificação de marca. Para obter detalhes no SharePoint identificação de marca, consulte "Microsoft Office SharePoint Server 2007 e Windows SharePoint Server v3" na barra lateral "Recursos".

antes de escolher uma ferramenta de personalização, considere o tamanho de sua implementação do SharePoint, a extensão de seu esforço de identificação de marca e a experiência dos desenvolvedores do aplicativo de suporte. Iremos nos concentrar na duas ferramentas: SharePoint Designer e o Visual Studio.

O SharePoint Designer tem suas raízes no FrontPage e é uma ferramenta de design da Web útil para editar páginas mestras e CSS. No entanto, a facilidade de uso fornecido pelo SharePoint Designer vem com um preço:

• Não há nenhum suporte de controle de origem integrado.
• As alterações feitas no resultado do SharePoint Designer no conteúdo modificado se tornando unghosted.

Em um estado unghosted, cópias do conteúdo são armazenadas no banco de dados conteúdo em vez do sistema de arquivos. Como resultado, unghosting possui os seguintes efeitos:

• Torna a implantações difícil de gerenciar porque o conteúdo pode ser atualizado apenas em SharePoint ou o SharePoint Designer
• Desconecta um site de conteúdo atualizado implantado para o sistema de arquivos
• Leva a possíveis problemas de desempenho em implementações de SharePoint grandes e ativas

Por esses motivos, acreditamos SharePoint Designer é mais adequado para pequenas e implementações de médio porte e protótipos.

O Visual Studio fornece um ambiente de desenvolvimento consistente para os componentes de aplicativos e artefatos de identificação de marca, mas ele não possui a funcionalidade de edição gráfica encontrada no SharePoint Designer. Por isso, os desenvolvedores devem ser mais proficient com a edição de HTML e CSS. Uma estrutura de projeto boa deve ser configurada para manter os artefatos de identificação de marca. Com suporte de controle de origem integrado do Visual Studio, é mais fácil gerenciar configurações específicas de ambiente e pacote marca artefatos a ser implantado em vários ambientes. Além disso, artefatos marca permanecem fantasmas. Por isso, Visual Studio é nossa ferramenta de marca de SharePoint preferencial para grandes empresas e implementações comerciais.

Há três abordagens aplicando a identificação de marca: modelos de site, definições de site personalizado e OOB site definições junto com as personalizações por meio de recurso de grampeamento e. A criação de modelos de site personalizado pode ser a abordagem mais rápida para implementações pequenas e protótipos. No entanto, sites criados a partir de um modelo não serão atualizada quando um novo modelo é carregado. Modelos personalizados não permitem que você especificar a identificação de modelo, o que exigirá alterações a qualquer código provisionamento que faz referência os modelos. Além disso, os modelos de site criar somente conteúdo unghosted, que pode afetar o desempenho.

Definições de site são mais flexíveis e portáteis que modelos de site. Você pode gerenciar o arquivo de definição de site (onet.xml) e o conteúdo associado no controle de origem e implantar conteúdo fantasma, permitindo que um site para ser atualizado com novo conteúdo desde que ele não tiver já foi feito. Definições de site podem ser difícil criar devido à complexidade do XML é necessário editar. Essa tarefa fica mais fácil usando definições de site OOB (encontradas no 12\Template\SiteTemplates como um ponto de partida) ou exportar uma definição de site usando VSeWSS. Para obter informações sobre definições de site, consulte" Definições de site desmistificadas."

Ao lidar com médias e grandes implementações, combinar OOB definições de site com recursos personalizados é a melhor abordagem. Recursos podem ser usados para estender as definições de site e fornecer uma abordagem modular para configuração de sites. Para uma boa visão geral dos recursos, olhar na coluna Espaço do Office" Recursos do SharePoint." As extensões de VSeWSS, bem como algumas ferramentas de terceiros, fornecem modelos para criar recursos comuns usados em sites de identificação de marca.

Grampeamento de recurso permite que você anexar um recurso a uma definição de site e que ele habilitadas quando um novo site é criado. Isso é uma maneira excelente para aplicar sua marca as definições de site do SharePoint OOB.

10. Desenvolva soluções implantável

Você pode obter os componentes em um aplicativo da Web do SharePoint de diversas maneiras. Esta seção aborda como utilizar o empacotamento e estruturas de implantação que o SharePoint fornece, incluindo pacotes de solução da Web Solutions/WSPs, recursos e o modelo de objeto SharePoint.

decidir como pacote componentes depende amplamente de onde os componentes são implantados. Soluções conter arquivos que serão implantados para o servidor. Recursos contêm conteúdo que será implantado no banco de dados de conteúdo.

Uma solução do SharePoint contém os assemblies e recursos a ser implantado para aplicativos Web do SharePoint. Soluções são CD, simples para implantar e Cancelar e alças de SharePoint espelhamento atualizações de arquivo em soluções do SharePoint em vários servidores em um farm. Você também pode usar soluções de SharePoint para as modificações de web.config. Consulte as seções "saber crítica tarefas SPDev e fontes informações" e "com SharePoint gerenciar personalizar configuração configurações" para obter detalhes adicionais sobre soluções e modificações de web.config. a Figura 8 lista os locais comuns da pasta suporte soluções e seu conteúdo. A "seção 12" refere-se a raiz do aplicativo SharePoint ou <%CommonProgramFiles%> \Microsoft Shared\Web servidor extensions\12 por padrão.

Figura 8 comuns locais de arquivos acessíveis de WSPs

Pasta na seção 12	Contém
\ISAPI\HELP\[LCID]	Arquivos de Ajuda do SharePoint. Implantar seus próprios arquivos .chm para essa pasta (ou uma subpasta localizada)
\CONFIG	Personalizações de Web.config
\ISAPI	Serviços de web do SharePoint (implantar os serviços da web personalizada aqui também); mapas para /_vti_bin
\Resources	Arquivos .resx global acessados de recursos personalizados e definições de site
\TEMPLATE\CONTROLTEMPLATES	Controles de usuário .ascx; mapas para /_controltemplates
\TEMPLATE\FEATURES	Recursos, do curso!
\TEMPLATE\LAYOUTS	Páginas do site; mapas para /_layouts comuns
\TEMPLATE\IMAGES	Arquivos de imagem de site; mapas para/_layouts/imagens comuns
\TEMPLATE\SiteTemplates	SharePoint todas as definições do site; criar um \xml <subfolder> para implantar a definição de site personalizado do onet.xml
\TEMPLATE\THEMES	Todos os elementos de interface do usuário usado em temas, clonagem uma pasta de tema existente para criar seu próprio
\TEMPLATE\[LCID]\XML	Webtemp.xml arquivos para definir as definições de site disponíveis; adicionar um arquivo xml aqui para sua definição de site personalizado
\TEMPLATE\ADMIN	Páginas usadas pelo administrador central; mapas para /_admin
\ADMISAPI	Serviços da web de administração; mapas para /_vti_adm

A seguir estão regras importantes a lembrar-se ao trabalhar com soluções:

• Porque soluções do SharePoint são gerenciadas no banco de dados de configuração, pode haver apenas uma instância exclusiva de uma solução em um farm do SharePoint. Esse ponto é importante se você pretende usar o mesmo farm para versões diferentes do host do mesmo aplicativo da Web — por exemplo, tanto manutenção atual e ambientes de desenvolvimento futuro.
• SharePoint controla soluções pela identificação não pelo nome, portanto, você precisará manter solução identificações em controle de origem se você pretende atualizar soluções no futuro.
• A seção 12 é um espaço de aplicativo da Web compartilhado. Se você planeja hospedar vários aplicativos da Web no mesmo farm, você precisará garantir que as soluções do SharePoint não substituir SharePoint existente arquivos ou arquivos implantados por outras soluções neste espaço.
• Soluções não é possível implantar arquivos fora as pastas listadas na A Figura 8 , incluindo pastas em um aplicativo da Web, como wpresources, _wpresources global ou outras pastas fora a seção 12.
• Soluções não é possível implantar conteúdo dentro de um aplicativo Web do SharePoint. Esta é a função dos recursos do SharePoint.

Recursos podem disponibilizar as Web Parts na galeria, carregar e publicar arquivos em bibliotecas de documentos e executar ações personalizadas, como definir o tema do site ou a página mestra padrão usando o recurso receptor assemblies. Consulte as informações sobre como usar o direito de marca técnica neste artigo para informações sobre como usar recursos para identificação de marca.

Aqui estão algumas advertências para a criação de recursos:

• Recursos não controlar conteúdo adicional, portanto, é responsabilidade do recurso limpeza após a própria quando ela é desativada por meio de um receptor de recursos. Considere a possibilidade de todo o ciclo de vida do recurso e o conteúdo implantado o recurso pode ser necessária por outras partes do aplicativo da Web antes que o conteúdo seja excluído. Por exemplo, a remoção de uma página mestra em desativação de um recurso desconectará as páginas que herdam essa página mestra.
• Desative um recurso de todos os aplicativos da Web antes de remover a solução usada para implantar o recurso. Se você não fizer isso, a implantação de solução irá falhar, e se a pasta de recursos tiver sido removida, será necessário forçar uma desinstalação do recurso usando o STSADM.

Suficiente Said

Usando este artigo como seu mapa, examine as referências fornecidas para obter informações e baixar exemplo de código deste artigo para ajudá-lo a começar. Talvez à medida que você desenvolver aplicativos na plataforma SharePoint, você examinará dessas práticas novamente e também encontrar usado em exemplos de código. Se você precisa de esclarecimento ou deseja nos enviar seus comentários sobre as dicas fornecemos ou outras dicas que você considerar importante, envie-nos seus perguntas ou comentários e irá se esforçar para responder rapidamente. Você pode acessar nós via email no ewilansky@yahoo.com.

Dicas adicionais

Aqui estão algumas dicas adicionais para o desenvolvimento de soluções do SharePoint.

Usar links relativos quando possível

Considere o uso de links relativos em vez de links absolutos. Incluindo links relativos em locais como bibliotecas de documentos, conexões de dados e bibliotecas de relatórios simplifica a implantação de uma instância do SharePoint para outro. No exemplo de biblioteca de relatórios em mente, se você usar um local da Web consistente para a biblioteca de relatórios em todos os seus ambientes de SharePoint, desnecessários alterar os ponteiros para relatórios quando você vai seu aplicativo de um ambiente para a próxima. Normalmente, a convenção sobre configuração se aplica a configuração de código, mas este conceito pode também ser flexível aplicado a outros aspectos da configuração de suas implantações.

Em uma nota relacionada, esperamos que a Microsoft oferecerá suporte links relativos dentro de plataforma do SharePoint, no qual atualmente algumas configurações precisam links absolutos. Por exemplo, especifique uma URL absoluta para a biblioteca de formulário em um InfoPath .udcx dados conexão fi le, e a Web Part de ReportViewer requer um caminho absoluto para a definição de relatório.

Criar páginas mestras personalizado

Uma maneira comum para sites do SharePoint marca com sua aparência é criar páginas mestras personalizado, o que lhe dá mais controle sobre o layout do seu site. Você pode levar a uma página mestra do SharePoint existente e modificá-lo para atender às suas necessidades. Essa abordagem funciona melhor se a página mestra existente está próximo de no layout desejado. Se a aparência desejada é muito diferente de qualquer uma das páginas mestras OOB, talvez inclined iniciar a partir do zero. No entanto, como o SharePoint requer determinada funcionalidade em páginas mestras, recomendável que você iniciar com uma página mestra mínima e criar a aparência de lá. Para saber mais sobre como criar uma página mestra mínima, consulte “ Como: criar uma página mestra mínimo” no. Você também pode baixar algumas páginas mestras mínima do blog ’s Vanessa Solomon, que também é listado na seção Resources.

Lidando com projetos do InfoPath em uma compilação automatizada

Projetos criados no Microsoft InfoPath Designer serão ainda mais desafie seus esforços para automatizar a compilação. O melhor que você realmente pode fazer é permitir que o InfoPath e o SharePoint lidam com a pacotes. Consulte “ automatizar Web aplicativo implantação com o SharePoint API ” na seção recursos para obter detalhes sobre como obter pacotes de soluções portátil de projetos do InfoPath.

Ethan Wilansky é diretor na prática de FTI consultoria de tecnologia e se concentra em criar soluções de SharePoint personalizadas. Como do Directory Services MVP da Microsoft, ele concentra-se na estrutura de programação DS e também é um membro do Office Developer conselho consultivo de mudanças.

Paul Olszewski é um especialista de informações de uma equipe recursos .NET. Ele é especializada em criar e implantar aplicativos de componente reutilizável aproveitando as tecnologias da Microsoft.

Tomek Stojecki funciona no Annapolis computação onde ele é especializada na arquitetura e desenvolvimento de aplicativos .NET usando padrões de design e metodologias ágil. Ele foi consultado em um número de SharePoint com base em projetos.

Stefan Kowalewski é consultor sênior de uma equipe de desenvolvimento do SharePoint. Ele fornece o conhecimento técnico e traz experiência ágil comprovada para personalizado esforços de desenvolvimento do SharePoint.