Olá pessoal,
Se você está començando um projeto para Dynamics 365 CE ou uma Model-Driven App e está procurando uma solução para Visual Studio que contenha a estrutura base ou inicial dos componentes de desenvolvimento, este post é para você!
Todo projeto precisa de seu início, sempre investimento um tempo considerável criando os “alicerces” de nossa solução. Assim, estou criando esta série de posts irei demonstrar como criar uma solução do Visual Studio com os componentes base para customizarmos nossas aplicações.
Assim, a ideia é que estes posts/solução sirva como etapa inicial para criarmos nossos projetos ou que de alguma forma possa melhorar ou acelerar algo que você venha fazendo atualmente.
Ao final desta série de posts teremos uma solução com estes projetos/componentes:
Para baixar a solução de Visual Studio contendo tudo que será discutido a solução completa, vá até o meu GitHub!
Por ser uma série de 3 posts, vou dividir da seguinte forma:
- Componentes da solução, bibliotecas NuGet e geração das classes Early Bound
- Classes Base para acelerar sua produtividade nas criação de Plugin e Workflows
- Web Resources e Testes
Vamos à prática!
Estruturar Solução, Projetos e pastas
Crie uma solução em branco (Blank Solution) no Visual Studio, estou chamando a minha de “D365.BaseSolution“, depois precisamos criar mais 3 projetos do tipo Class Library (.Net Framework) da seguinte forma:
- D365.BaseSolution.Plugins
- D365.BaseSolution.WebResources
- D365.BaseSolution.Workflows
Agora, vamos criar nosso projeto base para os demais, porém, não criaremos uma class library e sim um Shared Project, chamado “D365.BaseSolution.Base.Shared”
Em seguida crie um projeto do tipo Unit Test (.Net Framework) para termos nossos testes unitários, estou chamando este projeto de “D365.BaseSolution.Tests“.
Teremos esta estrutura ao final desta etapa:
Por termos projetos (dlls) que serão registrados no Dynamics 365, precisamos adicionar chaves fortes nos assemblies (assemblies with a strong name). Assim o projeto de Plugins e Workflows precisam ter estas chaves (se precisar de ajudar para criá-las, veja este link). Irei chamar minhas chaves de D365.BaseSolution.chk.
Organização sempre irá lhe poupar tempo, sendo assim, vamos criar algumas pastas dentro dos projetos para termos esta vantagem (irei falar sobre o propósito delas logo logo ;)):
Adicionar pacotes NuGet
Com projetos e pastas criados, agora precisamos adicionar os assemblies do Dynamics 365, para isso, precisamos instalar alguns pacotes NuGet. Adicione Microsoft.CrmSdk.CoreAssemblies para todos os projetos com exceção dos WebResources (vale lembrar que Share Project não será listado e não precisará de NuGet):
Depois adicione o NuGet Microsoft.CrmSdk.Workflow para os projetos Workflows, Tests e Plugins (sim, Plugins também, este é o único ponto negativo que me deparei ao utilizar um Shared Project, por não adicionarmos as dlls dentro do projeto em si, toda vez que usamos o projeto como referência é obrigatório termos todas os assemblies para o funcionamento adequado do Shared Project).
Por fim os pacotes para nosso projeto de testes, vou utilizar o FakeXrmEasy, assim precisamos adicionar:
- FakeXrmEasy.9 (para versões Dynamics 365 v.9.x.x.x):
- xunit e xunit.runner.visualstudio pois FakeXrmEasy fica ainda mais fácil com xunit:
Gerar e adicionar classes Early Bound
Como a grande maioria dos profissionais de Dynamics 365 sabem, temos duas formas de trabalhar com objetos no server-side:
- Early Bound – classe fortemente tipada, sendo checada no momento da compilação do código
- Late Bound – classe genérica (Entity) que será checada apenas no momento de criação do objeto
Não vou utilizar este post para discutir vantagens e desvantagens, eu irei na minha preferencia, que é Early Bound. Bom, para isso, precisamos criar nossas classes, vamos utilizar o plug-in de geração de Early Bound do XrmToolbox para gerar o arquivo.
Dica, apenas selecione as entidades com que irá trabalhar no momento e vá adicionando conforme a necessidade, vejam que apenas adicionei duas entidades Contas e Contatos (account e contact). Click em “Create All”:
Copie as classes recém criadas e adicione no projeto Base dentro da pasta Common:
Compartilhar classes Early Bound
Com as classes Early Bound criadas agora temos que pensar numa estratégia de usá-las em todos os demais projetos sem ter que fisicamente incluí-las, além disso, não gosto de realizar merge de dlls, assim, a ideia de utilizar um ILMerge está fora dos planos.
Para resolver este problema, é exatamente ai que entrar o projeto Base. Por ser um Shared Project, ao incluirmos sua referência nos demais projetos, as classes serão incluídas em cada projeto de forma virtual, não gerando uma referência tradicional como é o caso de uma dll.
Para isso, já até um projeto como o Plugins, clique para adicionar uma referência (Add Reference…), depois selecione “Shared Project” e selecione o projeto Base:
PS: Não esqueça de repetir o mesmo procedimento nos projetos de Workflows e Tests.
Para utilizar as classes do projeto Base, basta apenas adicionar a namespace e a mágica está pronta!
Bom assim termina este primeiro post! Criamos uma solução e projetos no Visual Studio, adicionamos as bibliotecas NuGet que nosso código irá precisar e por fim geramos nossas classes early bound para trabalharmos com objeto fortemente tipados.
No próximo post, iremos criar as classes base para plugins e workflows voltem aqui para conferir!
[]’s,
Tiago
Power Platform by Tiago Michelini Cardoso 