Olá Pessoal!
Hoje em um dos projetos que estou realizando com a versão 2011 do CRM, me deparei com o seguinte problema:
A equipe que esta tocando o projeto, atualizou uma atividade de workflow customizada adicionando um parâmetro de saída. Ao fazer o update na ferramenta, através do plugin registration tool, a equipe não conseguia visualizar o novo parâmetro de saída.
Após alguma pesquisa e lida em documentações conseguimos achar o motivo:
O processo de update/upgrade de atividades de workflow mudou! Agora a plataforma se baseia na versão do assembly (dll) para realizar essas ações.
Como Funciona:
Primeiramente precisamos entender como funciona o versionamento do assembly…
As informações de versão de assembly ficam no arquivo AssemblyInfo.cs do seu projeto do visual studio, vamos observar um exemplo abaixo:
using System; using System.Reflection; using System.Runtime.CompilerServices; using System.Runtime.InteropServices; // General Information about an assembly is controlled through the following // set of attributes. Change these attribute values to modify the information // associated with an assembly. [assembly: AssemblyTitle("1")] [assembly: AssemblyDescription("")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Microsoft")] [assembly: AssemblyProduct("Workflow")] [assembly: AssemblyCopyright("Copyright © Microsoft 2013")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")] [assembly: CLSCompliant(true)] // Setting ComVisible to false makes the types in this assembly not visible // to COM components. If you need to access a type in this assembly from // COM, set the ComVisible attribute to true on that type. [assembly: ComVisible(false)] // The following GUID is for the ID of the typelib if this project is exposed to COM [assembly: Guid("c12206f4-777c-402f-9f43-ddc3fee7d592")] // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.3.0")] [assembly: AssemblyFileVersion("1.0.3.0")]
Agora reparem o seguinte trecho:
[assembly: AssemblyVersion("1.0.3.0")] [assembly: AssemblyFileVersion("1.0.3.0")]
Nesta parte é que definimos o versionamento sendo estruturado da seguinte maneira:
1 <major_version>.0 <minor_version>.3 <build_number>.0 <revision>
Trabalhando com o versionamento do CRM:
Entendo o versionamento do assembly, o Dynamics CRM trabalha separadamente para fazer upgrade/update da atividade utilizando a versão.
Para o update de uma atividade, uma alteração de código que não envolva as classes públicas da atividade de workflow, você deve alterar o build_number ou revision.
Ex: Você fez um código para criar uma mascara do telefone em um campo do CRM, porém agora se faz necessário fazer com que ele suporte 9 digitos. Neste caso vamos atualizar a validação do 8 para 9, sem afetar as classe da atividade. Com isso alterariamos para 1.0.3.1 ou 1.0.4.0
Agora suponha que vamos criar um parâmetro de entrada para validar a aplicação da máscara com 9 ou 8 digitos, neste caso estaremos alterado a classe da atividade e com isso o CRM nos obriga a alterar major_version e minor_version. Para isto teriamos que alterar para 1.1.0.0 ou 2.0.0.0.
Ao alterar a major_version ou a minor você deve registrar como um novo assembly, e não fazer um update ao assembly. Isto irá gerar duas linhas do mesmo assembly somente com a versão diferente.
Com isso quando você estiver em um workflow e adicionar a ativdade no processo será exibida opção de versão para utilizar:
Com isso você pode ir evoluindo sua solução sem causar um impacto em algo que não precisa atualizar no momento. Eu particularmente achei muito bom com isso, as dependências para uma atualização fica mínimas para o cliente.
Para mais informações leia o link a seguir http://msdn.microsoft.com/en-us/library/gg328011.aspx