19 10 2016

É sempre a mesma coisa. A cada nova versão do Visual Studio surge aquele frio na barriga com relação à ferramenta de relatórios da Microsoft: será que o Report Viewer foi descontinuado? Isso aconteceu com bastante força no lançamento do Visual Studio 2015, quando a Microsoft decidiu remover o Report Viewer da instalação “típica” do Visual Studio, fazendo com que ele só aparecesse se você selecionasse o item “SQL Server Data Tools” durante a instalação do Visual Studio (inclusive eu mostro como fazer isso neste artigo).

Com a nova versão do Visual Studio (até o momento denominada de Visual Studio “15“), isso não poderia ser diferente. Nessa versão, a sensação é ainda pior. Mesmo instalando o “SQL Server Data Tools“, o Report Viewer ainda não aparece! Por que será? Teria a Microsoft realmente descontinuado o Report Viewer?

Não se assuste, até agora o Report Viewer não foi descontinuado pela Microsoft. Porém, a partir da próxima versão do Visual Studio, o modelo de distribuição dos controles e designers passarão por grandes mudanças. Confira o restante do artigo para ver os detalhes dessa mudança.

O novo modelo de distribuição do Report Viewer

Por ser o produto que eu escolhi focar nos últimos dois anos, eu tenho acompanhado de perto o que está acontecendo no mundo do Report Viewer / Reporting Services 2016. Até configurei uns alertas no Google para alguns termos relacionados a essas tecnologias. Dessa forma, sempre que algum novo artigo é indexado pelo Google, eu fico sabendo e vou lá dar uma olhada.

Foi através desse tipo de alerta que eu fiquei sabendo desta thread nós fóruns da MSDN americana. Nessa thread descobri qual será o novo modelo de distribuição do controle e do designer do Report Viewer / Reporting Services integrado ao Visual Studio.

Vejam só este trecho da thread, publicado pelo Brad Syrupta, engenheiro de software que trabalha no time de SQL Server BI na Microsoft:

Ou seja, o controle do Report Viewer não será mais distribuído em conjunto com o Visual Studio. A partir da próxima versão, ele será distribuído através de um pacote do NuGet. Essa é uma estratégia que a Microsoft tem utilizado com diversas outras tecnologias (como Entity Framework, por exemplo). Já a parte de designer dos relatórios será disponibilizada através de uma extensão do Visual Studio (VSIX), que será publicada na Visual Studio Gallery.

Qual o motivo da mudança?

Não podemos nos esquecer que a Microsoft é uma empresa gigantesca, formada por inúmeros times. Agora, vamos pensar somente na divisão de ferramentas para desenvolvimento de software (Visual Studio, .NET, etc). Já pensou a dificuldade que deve ser para sincronizar os diversos times envolvidos nesse processo?

Desde o Visual Studio 2005 até o Visual Studio 2015, o controle e o designer de relatórios do Report Viewer foram distribuídos juntamente com o Visual Studio. Isso traz um grande desafio para os times, uma vez que nem sempre as releases do Visual Studio estão sincronizadas com as releases do SQL Server (time por trás da experiência de relatórios RDL e RDLC).

Para tentar diminuir esse stress (entre outras coisas, como custos com recursos, manutenção, estratégias do produto, etc), a nova metodologia de distribuição fará com que as releases do controle do Report Viewer não estejam mais atreladas às releases do Visual Studio. Ou seja, nós não vamos mais precisar esperar que uma nova versão do Visual Studio seja lançada para podermos utilizar as novas versões do controle e do designer do Report Viewer.

Veja só este outro trecho do post do Brad Syrupta:

Testando a versão preview do controle do Report Viewer 2016

A primeira versão de testes do controle do Report Viewer 2016 foi lançada no dia 20 de setembro. Tanto o controle Windows Forms quanto o controle Web Forms estão disponíveis através de um pacote do NuGet. Para instalar o pacote, abra a janela de gerenciamento de pacotes do NuGet e procure por “reportviewercontrol“:

Outra opção é fazer a instalação do pacote através do Package Manager Console, utilizando estes nomes de pacotes (WinForms ou WebForms, dependendo do tipo do seu projeto):

– Microsoft.ReportingServices.ReportViewerControl.WinForms.Preview

– Microsoft.ReportingServices.ReportViewerControl.WebForms.Preview

Para mais informações sobre o gerenciamento de pacotes do NuGet através do Visual Studio, confira este artigo.

Para projetos Windows Forms, você não precisa fazer nenhum ajuste e o novo controle deve funcionar normalmente. Obviamente, se você já utilizava uma versão anterior do controle do Report Viewer, você precisa remover as referências antigas antes de adicionar o pacote da versão preview.

Para projetos web, se você já utilizava uma versão anterior do controle do Report Viewer, você terá que alterar algumas referências, apontando para a versão mais nova do controle (13.0.0.0). O primeiro lugar que você tem que alterar é a tag “Register” na página onde você utiliza o controle do Report Viewer:

O novo conteúdo dessa tag deve ser o seguinte:

<%@ Register assembly="Microsoft.ReportViewer.WebForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" namespace="Microsoft.Reporting.WebForms" tagprefix="rsweb" %>

Depois, temos que ajustar alguns pontos do arquivo web.config. O primeiro lugar é a referência para os assemblies (tag “assemblies“, dentro de “compilation“). Você deve assegurar-se que essas referências estejam apontando para a versão mais nova do controle:

      <assemblies>
        <add assembly="Microsoft.ReportViewer.Common, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845DCD8080CC91" />
        <add assembly="Microsoft.ReportViewer.WebForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845DCD8080CC91" />
      </assemblies>

Em seguida, temos que alterar o conteúdo da tag “httpHandlers“:

    <httpHandlers>
      <add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845DCD8080CC91" validate="false" />
    </httpHandlers>

Por fim, temos que fazer a mesma alteração na tag “handlers“, dentro de “system.webserver“:

    <handlers>
      <add name="ReportViewerWebControlHandler" verb="*" path="Reserved.ReportViewerWebControl.axd" preCondition="integratedMode"
        type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845DCD8080CC91"/>
    </handlers>

Com essas alterações, o seu projeto deve rodar sem nenhum problema de compilação.

Resultados Windows Forms

Depois de testar o controle do Windows Forms, eu não consegui detectar nenhuma diferença visual no controle. Também fiz um teste de performance com um relatório contendo um milhão de registros e não consegui notar nenhuma diferença na velocidade no processamento. Veja só a “cara” do controle, que é idêntica à da versão anterior:

Resultados Web Forms

Por outro lado, o controle Web Forms foi completamente reformulado. Pelo que andei lendo, a Microsoft decidiu abandonar de vez a utilização de ActiveX para a impressão dos relatórios e está renderizando todo o conteúdo em HTML5. Porém, no relatório que eu testei as coisas não funcionaram muito bem:

Veja só o mesmo relatório sendo exibido sem problema algum na versão anterior do Report Viewer:

Testei o mesmo relatório tanto no Google Chrome quanto no Internet Explorer e Edge. O resultado foi o mesmo. Tentei também adicionar a tag “meta” forçando que sites intranet não sejam renderizados em modo compatibilidade (como indicado na seção “Common issues” deste link), mas, também não tive sucesso.

Consertando possíveis problemas com o controle web

Depois de finalizar a escrita deste artigo, eu estava dando uma olhada no fórum de Reporting Services da MSDN americana e acabei encontrando esta thread. Seguindo as instruções apresentadas nela, a versão nova do controle web do Report Viewer funcionou corretamente:

O problema acontece basicamente porque a última versão do SQL Server Data Tools (instalada com o Visual Studio 2015 e seus updates) adiciona no GAC uma versão do novo controle que ainda não estava finalizada. E como as dlls do GAC têm mais prioridade do que as dlls presentes na pasta da aplicação, o IIS acaba carregando essa versão incorreta do GAC.

Para corrigirmos esse problema, precisamos remover as dlls problemáticas do GAC. Conseguimos remover dlls do GAC utilizando a ferramenta “gacutil“. Essa ferramenta fica armazenada na pasta “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin“. Abra um prompt de comando elevado (como administrador), navegue até esse diretório e tente executar os seguintes comandos para remover todas as dlls problemáticas do Report Viewer do GAC:

gacutil /u "Microsoft.ReportViewer.WebForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /f
gacutil /u "Microsoft.ReportViewer.WinForms, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /f
gacutil /u "Microsoft.ReportViewer.WebDesign, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /f
gacutil /u "Microsoft.ReportViewer.Common, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /f

Se esses comandos forem executados sem nenhum erro, o seu ambiente já estará pronto. Porém, no meu caso eu recebi um erro ao tentar remover as dlls do GAC:

Unable to uninstall: assembly is required by one or more applications

Pending references:

SCHEME: <WINDOWS_INSTALLER> ID: <MSI> DESCRIPTION:<Windows Installer>

Depois de pesquisar um pouco sobre esse erro, acabei encontrando este artigo, que explica claramente que o problema é que essas dlls estão sendo referenciadas pelo Windows Installer no registro do Windows. Se isso também estiver acontecendo no seu ambiente, você terá que primeiramente remover as suas referências do Windows Installer no registro do Windows.

No meu computador, eu encontrei as referências na pasta “HKLM\SOFTWARE\Classes\Installer\Assemblies\Global“. Porém, pode ser que em algumas instalações as referências estejam em “HKCU\Software\Microsoft\Installer\Assemblies\Global“, portanto, é importante procurar nessas duas pastas do registro. Uma vez encontradas as chaves do Report Viewer, delete tudo o que tiver versão “13” (não esqueça de fazer um backup do registro antes de deletar as chaves!):

Em seguida, execute novamente os comandos para remover as dlls do GAC e veja que, dessa vez, os comandos funcionam com sucesso:

Concluindo

Sempre que uma nova versão do Visual Studio é lançada (ou está prestes a ser lançada), surgem os rumores que o Report Viewer esteja sendo descontinuado pela Microsoft. Até hoje, isso nunca se concretizou e espero que não se concretize num futuro próximo.

Como você conferiu neste artigo, por razões estratégicas, a Microsoft está alterando o modelo de distribuição do Report Viewer a partir da próxima versão do Visual Studio. Esse novo modelo não será mais dependente das releases do Visual Studio, ou seja, poderemos ter novas versões do controle e das ferramentas de design independentemente das datas de release do Visual Studio.

O que você achou dessa nova estratégia? E o que você achou do novo visual do controle web do Report Viewer, desenvolvido completamente em HTML5? Fico aguardando as suas opiniões na caixa de comentários.

Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.

Até a próxima!

André Lima

Definindo a estrutura de campos do Crystal Reports sem DataSet ou classe Conheça o que vem aí na próxima versão do Visual Studio