Trabalhando com DLLs externas em plugins ou atividades customizadas de workflow

by Pedro Azevedo 13. April 2016 08:38

Boas pessoal,

Hoje venho falar de um mecanismo que é o meu dia-a-dia no desenvolvimento de plugins ou atividades customizadas de workflow. Sempre que começamos um projeto vamos verificar que muito código pode ser reutilizado, ou seja, código que se repete em vários plugins por exemplo. Imaginem por exemplo um requisito que qualquer email temos que usar o mesmo utilizador, então em cada plugin teríamos que fazer o mesmo código.

A solução pode passar por colocar num projeto a parte e daí gerar uma DLL, assim podemos usar esse código nas atividades de workflow e em múltiplos projetos. O problema é que o CRM não deixa que coloquemos referências externas a DLLs, principalmente no CRM Online.

A solução passa por usarmos o ILMerge uma ferramenta gratuita e muito usada, onde o seu principal objetivo é fazer merge entre DLLs e gerar apenas uma. Assim a restrição de registar múltiplas DLLs fica ultrapassada, pois o plugin e a nossa biblioteca vão na mesma DLL. Antes a sua configuração ainda era complicada, mas a uns anos descobri este post que utiliza uma tarefa do MSBuild que permite otimizar muito o processo.

Presumindo que vocês já têm a vossa solution montada, vamos instalar o pacote NuGet chamado MSBuild.ILMerge.Task sobre o projeto do nosso plugin\atividade de workflow:

image

Depois de instalarmos este pacote NuGet, vamos adicionar a DLL da nossa biblioteca. Esta tarefa de MSBuild vai ter a função de fazer “merge”  de todas as DLLs que estejam na pasta bin do nosso plugin. Se forem a essa pasta vão visualizar mais DLLs e principalmente as quatro principais para desenvolvermos sobre o CRM:

image

Sobre estas referências temos que ir as propriedades dessas DLLs e mudar a configuração, “Copy Local” e colocamos a false. Assim essas DLLs não ficam no merge.

image

Antes de compilarmos podemos ver a estrutura atual da pasta bin:

image

Depois de um clean e se recompilarmos novamente o projeto passamos a ter apenas uma DLL:

image

Para confirmarmos que realmente as duas DLLs estão juntas, podemos recorrer a ferramenta ILSpy, que inspeciona a DLL:

image

Com isto podemos continuar com o registo da nossa DLL sem quaisquer problema.

 

Até a próxima.

Tags: , ,

Como fazer debug de um plugin e atividade customizada no CRM On-Premise

by Pedro Azevedo 4. December 2014 02:23

Boas pessoal,

Vou continuar a série de fazer debug. Até agora abordamos como realizar debug sobre plugins online e em Web Resources. De referir que a prática que usamos no CRM Online pode-se usar no on-premise também.

Hoje quero falar sobre fazer debug em plugins num ambiente on-premise, que vai permitir realizar um debug em real-time. Para ser mais exato este procedimento é para código servidor, ou seja, tanto dá para plugins como para atividades workflow.

A primeira premissa é termos a nossa DLL do plugin ou da atividade de workflow e o ficheiro PDB (contém informações para realizar debug). Temos que colocar estes dois ficheiros na pasta: “<pasta de instalação>\Microsoft CRM\server\bin\assembly” (C:\Program Files\Microsoft CRM\server\bin\assembly), nesta pasta também devem ser todas as DLLs que se dependa a não ser que estas estejam registadas no GAC.

Uma vez que temos estes ficheiros podemos chegar ao nosso servidor de desenvolvimento e com o projeto do plugin aberto anexarmos um destes processos:

  • w3wp.exe para os plugins síncronos;
  • Microsoft.Crm.Application.Hoster.exe para quando temos uma ligação offline através do Outlook.
  • CrmAsyncService.exe quando se trata de um plugin assíncrono ou uma atividade workflow
  • Microsoft.Crm.Sandbox.WorkerProcess.exe quando temos o plugin registado no modo sandbox.

Vejam a seguir alguns screenshots de como fazer attach a alguns dos processos acima:

Com esta configuração o próximo plugin ou atividade de workflow irá parar no breakpoint definido.

As vezes pode ser frustrante porque o breakpoint não é ativado. Quando isto acontece podemos seguir uma espécie de checklist:

  1. Reset ao IIS (diretamente no IIS ou na linha de comandos escrever iisreset)
  2. Se for uma atividade de workflow ou plugin assíncrono, restaurar o serviço Assync do CRM
  3. Recompilar (em vez de Rebuild, podemos efetuar também o clean) o projeto do plugin ou atividade workflow
  4. Colocar a DLL e o PDB na pasta referida
  5. Registar o assembly pelo Registration Tool
  6. No Visual Studio colocar o breakpoint e anexar os processos referidos.

 

Se no Visual Studio se houver a seguinte mensagem sobre o breakpoint, quer dizer que temos que efetuar a lista acima:

Se o breakpoint apresentar a mensagem a seguir não se preocupem que em principio ele para no breakpoint:

E aqui está um exemplo, neste caso este plugin é lançado aquando da criação de um cliente:

Esta estratégia funciona bem nos ambientes de desenvolvimento, onde temos o visual studio instalado na mesma máquina onde está o servidor de CRM. Caso não tenhamos este cenário necessitamos de um auxiliar que é o Remote Debugger instalado. Podem ver aqui um bom artigo para auxiliar a sua instalação. Depois de estar instalado o Remote Debugger é colocarmos no campo Qualifier o nome do servidor.

 

PS: A versão do CRM usado neste post foi o CRM 2011 com o VS 2010, mas em outros ambientes é praticamente igual.

 

Até a próxima.

Tags: , , ,

About

Muito bem casado, Pai babado e um gosto muito grande pela tecnologia.

Tenho um lema "Sharing is Learning"

Mais aqui -> http://www.psazevedo.com

Month List