Novo site de VBA da Microsoft

O VBA tem um papel importante no posicionamento do MS-Office no mercado, já que permite um nível de customização que nenhuma outra ferramenta tem.

Assim, nada mais adequado que a Microsoft voltar a dar um espaço de destaque ao VBA, com conteúdo atualizado para o Office 2010:

http://msdn.microsoft.com/en-us/office/ff688774.aspx

O link direto é, na verdade, este: http://www.iheartmacros.com/

Na primeira vez que vi o link, eu li “hate”, mas é “heart” o correto! 

Excel – Erro de formato ao abrir planilha a partir de Internet Banking

Depois de instalar o Office 2007 ou 2010, muitos usuários de Internet Banking passaram a ter problema ao usar o comando de exportar para Excel oferecido por alguns bancos. Trata-se da mensagem “The file you are trying to open ‘arquivo.xls’ is in a different format than specified by the file extension” ou, na versão em português, “O arquivo que você está tentando abrir, “arquivo.xls”, está em um formato diferente do especificado pela extensão do arquivo”. Ao clicar em “Sim”, a planilha abre normalmente, mas é uma mensagem um tanto incômoda para quem usa com frequência este tipo de funcionalidade.

 

O motivo deste alerta é que o Excel 2007 trouxe um recurso novo de segurança chamado Extension Hardening, que verifica se a extensão do conteúdo a ser aberto é a mesma do comando shell que tenta abrir o arquivo. Se o tipo de arquivo for diferente (HTML, XML, CSV, etc.), o Excel exibe o aviso pedindo confirmação do usuário.

Esta checagem é configurável e eu costumo desativá-la no meu perfil de usuário nas máquinas em que trabalho. Isto é feito no registro do Windows (regedit.exe), na chave HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Security, onde deve ser criado um DWORD com o nome ExtensionHardening e valor 0. Se este valor DWORD não existir, o Excel assume o padrão 1, que faz a checagem e exibe o alerta. Existe ainda a opção 2, que impede a abertura do arquivo sem dar a opção de escolha ao usuário.

 

Definindo valor padrão de datas no Access com VBA

 

Um recurso que facilita o trabalho de quem precisa digitar
dados em um formulário é a definição de valor padrão (default value) para
alguns campos.

Imagine, por exemplo, que você seja responsável por lançar
no sistema os dados de extrato bancário, e que cada dia de extrato tenha de 15
a 20 lançamentos. Provavelmente você não vai querer digitar em cada registro a
data de lançamento, mas sim digitá-la uma única vez e esperar que o sistema a
assuma como padrão para as próximas linhas, até que você informe a próxima
data.

No Access, o valor padrão pode ser definido por código VBA
ou diretamente no modo estrutura do formulário. Neste cenário que descrevi
acima, faz sentido definir o valor padrão por VBA, já que o conteúdo será
dinâmico: sempre que o usuário digitar uma data de lançamento, este valor
digitado tornar-se-á padrão para os próximos registros.

A primeira tentativa de um programador provavelmente será
usar o evento After Update do campo DataLancamento para atribuir o valor padrão
desta forma:

Private
Sub DataLancamento_AfterUpdate()

On
Error GoTo ErrHandler

If
IsDate(Me.DataLancamento) = True Then

    Me.DataLancamento.DefaultValue =
Me.DataLancamento

End
If

ExitHere:

Exit
Sub

ErrHandler:

MsgBox
Err.Description & vbCrLf & Err.Number & vbCrLf & Err.Source,
vbCritical, “DataLancamento_AfterUpdate”

Resume ExitHere

End Sub

 

O código vai até rodar corretamente, porém, a data do
próximo registro não será a esperada. Provavelmente virá com algum dia de 1899.
Motivo: a propriedade Valor Padrão deve ser passada na forma de string, e não
com o tipo de dados do campo em questão.

Portanto, se o campo for do tipo data, use esta sintaxe:

Private
Sub DataLancamento_AfterUpdate()

On
Error GoTo ErrHandler

If
IsDate(Me.DataLancamento) = True Then

    Me.DataLancamento.DefaultValue
= “#” & Format(Me.DataLancamento, “yyyy-MM-dd”) &
“#”

End
If

ExitHere:

Exit
Sub

ErrHandler:

MsgBox
Err.Description & vbCrLf & Err.Number & vbCrLf & Err.Source,
vbCritical, “DataLancamento_AfterUpdate”

Resume ExitHere

End Sub

 

Documentação do Visual Basic 6 e de controles ActiveX

Finalizando a série “sessão nostalgia” (pelo menos por enquanto), comentei no último artigo que a documentação de VB6 e controles ActiveX está sumindo.

Em 99 comprei o VB6 na caixa (que tenho até hoje), vinha com dois manuais MUITO bons e em português, um era o guia de referência, o outro era o guia de componentes, com a explicação e exemplo de todos os controles ActiveX (treeview, listview, grid, etc.). A Makron Books vendia esses livros separadamente também, mas hoje em dia não se encontra nem em sebos.

Esta mesma documentação existe (só em inglês) no site da Microsoft, o MSDN. Antes da reformulação do MSDN, que mudou o visual, era fácil achar este material apenas navegando na árvore lateral da Library. Agora, tem que procurar BASTANTE para achar.

Caso alguém precise, seguem os links. Espero que não tirem do ar!

http://msdn.microsoft.com/en-us/library/aa716285(VS.60).aspx
http://msdn.microsoft.com/en-us/library/aa338033(VS.60).aspx

Para quem tem acesso ao MSDN Subscription, a documentação final do Visual Studio 6 pode ser baixada – item MSDN Library 2001. 

Controles ActiveX no Office

Lembro que quase 10 anos atrás, quando os programas desenvolvidos para Windows tinham mais ou menos a mesma cara, usar controles Activex sempre era um bom diferencial, tanto em termos visuais como em funcionalidades.

Estou falando aqui de controles como Treeview, Listview, Progress Bar e diversos outros que, hoje, também estão batidos. Estes controles estavam disponíveis no Visual Basic 6 e no Office XP Developer, além das versões anteriores destes pacotes.

No Office 2003 em diante, apareceram alguns problemas de compatibilidade, especialmente com o Access, mas, ainda assim, muitos desenvolvedores os usam.

Eu nunca recomende o uso de controles ActiveX no Office, pois há grande probabilidade do usuário final não ter o componente registrado em sua máquina, portanto o aplicativo não funcionará.

O que tem me impressionado é o crescente número de pessoas, em geral novos desenvolvedores começando a estudar VBA, que se encantam pelo visual e funcionalidade dos controles e querem usá-los em seus projetos. Porém, além da dificuldade de achar os controles (arquivos ocx), a documentação está “sumindo” da internet, provavelmente pela idade.

Bem, o objetivo deste artigo é compartilhar aqui um exemplo feito pela Microsoft, com Access 97, que me ajudou muito no final dos anos 90. Trata-se de um MDB (formato Access 97, mas abre normalmente em versões mais novas) com exemplo de uso de cada um dos controles.

 

 

Quem quiser este exemplo, pode baixar do site da Microsoft: http://support.microsoft.com/kb/165437

Ele contém os arquivos ocx usados no exemplo para que vocês possam instalar e estudar o exemplo, porém não inclui licença para redistribuí-los (é necessário ter o antigo Office Developer ou o Visual Basic 6).

Vejam algumas telas de Treeview com Listview e de Progressbar:

 

 

 

 

 

 

Editora Pearson – exemplo de bom atendimento

Quem conhece meus artigos publicados anos atrás na revista Fórum Access e no meu site de Access (www.accessfaq.com.br) sabe que sempre gostei e recomendei os livros de informática da Makron Books (agora editora Pearson). É uma das poucas editoras que fogem da regra que diz que “livro de informática tem que ser básico, fino e barato” e disponibiliza, em português, vários guias de referência.

A verdade é que, infelizmente, o mercado editorial no Brasil (na área de informática, pelo menos) despencou em títulos disponíveis e em interesse. É difícil encontrar quem ainda estude por livros, o que resulta em conhecimento cada vez mais superficial dos profissionais. Isto faz com que a maioria das editoras lance em português apenas livros básicos, introdutórios. Material avançado é difícil achar.  A solução, para quem fala inglês, é recorrer à Amazon.com (www.amazon.com) e à Barnes & Noble (www.bn.com). 

Numa das frequentes encomendas que fiz, comprei um antigo clássico de VB6, o Mastering Visual Basic 6, do Evangelos Petroutsos, editora Sybex (agora Wiley). No Brasil, foi lançado como “Dominando Visual Basic 6 – A Bíblia”. Trata-se de um livro com mais de 1200 páginas, fora de catálogo há alguns anos. Na verdade não é um título que eu estava precisando, mas é um livro que eu sempre quis ter na minha coleção e nunca tive a oportunidade. Por fim, consegui uma cópia usada em um vendedor parceiro da Amazon, em impecável estado de conservação.

Bem, mais ou menos impecável… Ele veio sem o CD que acompanha o livro. Para um livro deste tamanho, de coleção, e cheio de exemplos, foi uma decepção.  Por ser um clássico do VB6, imaginei que ia ser fácil conseguir o material na internet. Nada! Nenhum site, nenhum fórum, nada. Entrei em contato com a editora Wiley nos EUA, confiante de que resolveriam, mas também não quiseram mexer uma palha (“I’m sorry” foi a resposta deles).

Minha última tentativa foi a editora Pearson aqui no Brasil, que não tinha motivo algum para ajudar: livro fora de catálogo, minha versão é a americana (e usada), ou seja, nenhuma relação com a Pearson. Mesmo assim, para minha surpresa, a área de atendimento ao consumidor (por meio da Amanda Fabbro) importou-se com o meu caso e, sem qualquer custo, conseguiu e me enviou um CD da versão brasileira do livro, que é idêntico ao da versão americana. Eu já estaria 100% feliz com uma cópia do CD, mas eles foram além e me mandaram um original.

Fiquei bastante impressionado com o serviço. Já era uma editora que eu gostava bastante pelos livros, e agora também pelo atendimento.

 

Como evitar processos pendurados na automação do Excel

 

Em linhas gerais, a automação é o mecanismo que permite um
aplicativo (chamado cliente) acessar e manipular objetos e recursos de outro
aplicativo (chamado servidor). Via de regra, a automação é algo tecnicamente
complexo nos bastidores, pois pode envolver diversas interfaces entre cliente,
servidor e sistema operacional.

O Office é um dos mais importantes (se não o mais
importante) servidores de automação, pois além de oferecer recursos avançados (editor
de textos, planilha eletrônica/gráficos, apresentações, etc.) que complementam
vários tipos de soluções, conseguiu encapsular a complexidade da automação
tornando-a bastante simples ao desenvolvedor. Se compararmos o MS-Office a
outros pacotes concorrentes, a facilidade na programação agrega mais valor
ainda ao MS-Office, já que praticamente todos seus recursos estão disponíveis
programaticamente.

De todas as ferramentas do pacote Office, o Excel é a mais
usada como servidor de automação, especialmente por ser um produto muito
versátil (troca de dados, cálculos, gráficos, relatórios, etc.) e usado no
mercado em praticamente todos os ramos de atividade.

 

Abrir e fechar o aplicativo servidor

Embora a automação do Office seja fácil de se implementar, o
desenvolvedor necessita de uma atenção especial: ao abrir um aplicativo, deve
cuidar de fechá-lo.

De certa forma, a automação funciona como se um usuário
abrisse e manipulasse o aplicativo servidor. Se pegarmos o Excel como exemplo,
a automação funciona de maneira semelhante a um usuário que aciona a aplicação
Excel, abre uma pasta de trabalho, escolhe uma planilha, lê e preenche células.
Assim, um processo do Excel é iniciado no Windows e, quando o usuário fecha o
Excel, o processo é finalizado.

 

 

Nos cenários de automação, porém, é muito comum o aplicativo
servidor ser executado nos bastidores, de forma invisível ao usuário que, na
maioria das vezes, nem sabe que o Excel (ou seja lá qual aplicativo for) está
sendo executado. Se o usuário não tem a janela do Excel ativa para poder
fechar, quem deve fazer isto é a própria aplicação que o abriu, caso contrário
o processo ficará pendurado no Windows. Além de consumir memória, isto pode ter
um efeito mais nocivo: deixar a pasta de trabalho do usuário bloqueada de forma
que ele não consiga acessá-la nem abrindo o Excel manualmente, nem por outro
processo de automação.

 

 

Este erro é bastante comum nos fóruns de discussão: “[meu
arquivo] está bloqueado para edição”. O usuário diz que fechou todos os
programas (e de fato fechou), abriu seu arquivo do Excel e recebeu esta
mensagem de erro.

Ao abrirmos o Windows Task Manager na guia processos e
classificarmos por nome da imagem, encontramos repetidas vezes o “EXCEL.EXE”.
Finalizamos os processos e, momentaneamente, o problema está resolvido. Mais
tarde, porém, o problema volta a se repetir. Motivo: algum aplicativo que usa o
Excel como servidor de automação está falhando em fechá-lo. Geralmente ocorre
algum erro em tempo de execução no código depois que a aplicação foi
instanciada, deixando-a pendurada.

 

Como evitar o processo pendurado

Para evitar este cenário descrito acima, recomendo uma
destas duas práticas, por ordem de prioridade:

a)     
Trazer a aplicação Excel para a tela do usuário:
se o objetivo da rotina de automação for preparar um arquivo e exibir o
resultado final ao usuário, nada mais óbvio que torná-lo visível, certo? Porém,
muitas vezes o desenvolvedor não faz isto: ele abre o Excel, executa as rotinas
de preenchimento, salva, fecha e, por fim, executa o comando Shell para abrir o
arquivo em uma nova instância do Excel.

O que recomendo, nestes casos, é
deixar visível a própria instância usada no preenchimento, e fazer isto logo no
início do código. Desta forma, se ocorrer algum erro durante a execução do
código, o processo não ficará perdido no Windows, pois o usuário terá domínio
da janela.


 

Sub MySub1()

Dim xlApp As Excel.Application

Dim xlWkb As Excel.Workbook

 

On Error GoTo ErrHandler

 

‘Instancia o Excel

Set xlApp = New Excel.Application

 

‘Deixa o Excel visível para
o usuário

xlApp.Visible = True

 

‘Seu código aqui…

 

ExitHere:

Exit Sub

 

ErrHandler:

MsgBox Err.Description &
vbCrLf & Err.Number & vbCrLf & Err.Source, vbCritical,
“MySub”

Resume ExitHere

End Sub

 

 

b)     
Controlar se a aplicação está instanciada e
fazer a finalização no tratamento de erro: é comum alguns desenvolvedores
colocarem um comando para finalizar (Quit) o Excel no tratamento de erro.
Porém, se o erro ocorrer por outro motivo que não a automação e o Excel não
tiver instanciado no momento, este tratamento vai gerar outro erro (“Object
variable or With block variable not set”):

 

 

 

Para que não ocorra este erro, o
mais correto é, antes de fazer o Quit, verificar se o Excel foi instanciado:

 


Sub MySub2()

Dim xlApp As
Excel.Application

Dim xlWkb As
Excel.Workbook

Dim blnIsOpen
As Boolean

 

On Error GoTo
ErrHandler

 

‘Instancia o Excel

Set xlApp =
New Excel.Application

blnIsOpen =
True

 

‘Seu código
aqui…

 

 

‘Finaliza a aplicação

xlApp.Quit

blnIsOpen = False

 

ExitHere:

Exit Sub

 

ErrHandler:

 

‘Verifica se o
Excel está instanciado

If blnIsOpen =
True Then

    xlApp.Quit

End If

MsgBox
Err.Description & vbCrLf & Err.Number & vbCrLf & Err.Source,
vbCritical, “MySub”

Resume ExitHere

End Sub

 

 

Conclusão

Estas duas técnicas são bastante simples, mas ajudam a
evitar problemas muito comuns e recorrentes quando fazemos automação de
aplicativos, especialmente do Excel. Podem ser usadas a partir de qualquer
linguagem, seja VBA (como nos exemplos acima), seja VB6, VB.Net, C# ou outra
linguagem.

 

Recursos do Access removidos na versão 2010

Sempre quando sai uma versão atualizada de algum produto,
vemos muitos artigos sobre as novas funcionalidades, mas quase sempre passa
despercebido algo igualmente importante: os recursos que ficaram para trás.

Este artigo tem por objetivo justamente isto: listar os
recursos do Access que não estarão mais disponíveis na versão 2010. Mesmo que
você hoje desenvolva com versões anteriores do Access e não esteja planejando
migrar tão cedo para o 2010, vale a pena ter conhecimento dos recursos com os
quais não poderá contar no futuro e assim planejar melhor a arquitetura dos
novos aplicativos que venha a construir.

 

 

Formato Snapshot

O formato Snapshot (*.snp) é bastante usado por
desenvolvedores, especialmente em aplicações corporativas, para salvar
relatórios. O visualizador deste formato é o Snapshot Viewer, que vinha na
instalação do Office e também fica disponível para download gratuito no site da
Microsoft (http://support.microsoft.com/kb/175274/pt-br).

Era (na verdade, ainda é) um bom utilitário, com ótima
visualização e navegação de páginas. Porém, a partir do Access 2007 SP2, o
Snapshot passou a “concorrer” com o formato PDF, que é muito mais difundido e
utilizado, então o Snapshot perdeu um pouco o sentido.

 

 

 

Controle calendário (Calendar control – mscal.ocx)

O controle calendário foi o ActiveX mais usado com o Access
durante um bom tempo, mais até que o Treeview control. Não que fosse uma grande
maravilha – pois não é -, mas o fato de estar ali disponível pela própria
instalação do Access levou muitos desenvolvedores a utilizá-lo em suas
aplicações.

O visual do controle é ok, além de ser fácil de programar e
utilizar, porém muita gente – sem saber – acabava tendo problema na
distribuição, pois é um controle ActiveX, não é nativo do Access, além de ter
diferentes versões de acordo com o idioma do Access.

 

Particularmente, não deixa saudades. O Access 2007 já traz o
date-time picker (que é uma espécie de combobox em que o drop-down é um
calendário suspenso) nativo, e mesmo para quem desenvolve para versões
anteriores, há boas alternativas de calendários desenvolvidos dentro do próprio
Access, com formulários e controles nativos, mais funcionais e sem nenhum
problema de distribuição. Aqui há alguns links: http://www.accessmvp.com/JConrad/accessjunkie/calendars.html

 

 

Página de acesso a dados (Data Access Pages – DAPs)

Outro recurso que não deve fazer falta (não por ser ruim,
mas por ser pouco usado) são as páginas de acesso a dados (DAPs). Esta foi a
primeira tentativa de levar front-ends do Access para a web, porém não foi bem
sucedida. Disponível a partir do Access 2000, a tecnologia era baseada em ASP,
ADO e DHTML. O desenvolvedor, por meio de um simples assistente, gerava um
formulário (semelhante a um formulário Access), que na verdade era uma página
ASP que acessava o banco de dados (DHTML fazendo data binding com ADO).

Considerando que a primeira bolha da internet estava sendo
inflada naquela época, todas as empresas demandavam sites dinâmicos (com acesso
a dados) e os desenvolvedores focavam na web, era de se esperar que as DAPs
fizessem mais sucesso, afinal representavam uma forma fácil e rápida de colocar
uma página no ar. Porém, ficou só na expectativa mesmo, não sei ao certo por
quê. Provavelmente por uma combinação de fatores: o visual das DAPs era de
formulários enlatados; a customização era difícil; as DAPs tinham o estigma de “sites
de mentira”; o desenvolvedor acabaria tendo que escrever muito código ASP para
atender os requisitos do cliente, então as DAPs representavam pouco ganho de
produtividade dentro do escopo todo do projeto.

 

 

 Provavelmente muitos vão dizer que o desenvolvimento para
Access Services – os bancos de dados web (ou web databases) do Access 2010 – é
o substituto das DAPs. Embora os web databases, mesmo em sua versão inicial,
sejam muito melhores e mais completos do que as DAPs jamais foram, não podem ser
considerados substitutos. Os web databases são publicados apenas em sites
SharePoint 2010 com Access Services (portanto, na versão paga do SharePoint),
enquanto as DAPs podiam ser jogadas em qualquer servidor com IIS.

O Access 2010 ainda consegue armazenar as DAPs no arquivo e
convertê-las para versões anteriores do Access, porém não permite editar nem
executar. O Access 2007 também não permitia editar a estrutura, mas executar
era possível.

 

 

Visualizador de conflitos de replicação

Como desde a versão 2007 o suporte a replicação de dados
foi deixado de lado, nada mais natural que parar de suportar o visualizador de
conflitos. Embora eu poucas vezes tenha usado os mecanismos de replicação nativos
do Access, gostava muito deles. Era um recurso muito profissional disponível
num banco de dados considerado de amadores (assim como a segurança em nível de
usuário, que também foi descontinuada). Como eu tinha 0,5% de esperança de ver
estes recursos de volta no Access, fiquei triste por ter agora 0,0%.

Quanto ao visualizador de conflitos em si, é possível criar
uma versão customizada, já que tudo é baseado em objetos programáveis. Anos
atrás escrevi sobre isto na revista FórumAccess, quem tiver interesse pode dar
uma olhada nas edições 63 e 64, ou aqui tem o eletrônico do primeiro deles: http://linhadecodigo.com.br/Artigo.aspx?id=1220

 

 

 

Conexão com Paradox (3 a 7), Lotus 1-2-3 e Access 1.0 e 2.0

Dos recursos que estão ficando para trás, este item é o que
mais me preocupa. Não que seja comum encontrar aplicativos que precisem permanentemente
destes conectores específicos, mas sempre foi da essência do Access a
facilidade de conexão com diversos bancos de dados. Isto tem se perdido ao
longo das versões. Se compararmos o Access 97 com o 2010, por exemplo, veremos
que o 97 se conectava com qualquer coisa, e o 2010 apenas com alguns gatos
pingados. Seguindo este caminho, daqui poucos anos o Access só falará com
Access, SQL Server e SharePoint.

O que perdemos com isto? Estes são os principais pontos:

a)     
O Access é a melhor ferramenta de migração de
dados que conheço. Posso (ou podia) vincular qualquer origem, qualquer destino
e rodar consultas de acréscimo para carregar dados, consultas de atualização
para manutenção de dados e consultas de exclusão para limpar bases. E é comum
os desenvolvedores precisarem fazer manutenções ou migrações em bases antigas.

b)     
Quando precisamos criar um sistema que consome
dados de uma base antiga, ou nem tão antiga, se o Access não tem os conectores,
ficamos praticamente sem alternativa de como atender o requisito. Recentemente,
por exemplo, precisei criar um sistema que consumia dados de planilhas Lotus
1-2-3 enviadas diariamente, e com o Access e o Excel não é mais possível. Quem
vai acabar ocupando este espaço é o OpenOffice.

 

 

Conclusão

Tão importante quanto conhecer os novos recursos
do Access 2010 (para explorá-los melhor) é saber o que está parando de
funcionar, e assim avaliar e criar alternativas. Muitas vezes surgem oportunidades
de mercado em cima de recursos removidos.

Word – como mudar o idioma dos estilos

Hoje eu tinha em mãos dois templates do Word, sendo um para documentos em português e outro em inglês. Além de importar os estilos de um documento para o outro, era preciso também alterar o idioma para que ficassem de acordo com a versão do template (português ou inglês).

Este tipo de alteração em cascata mostra o quanto é importante encadear os estilos na hora de sua criação. O campo “estilo baseado em” faz este papel importante: ao alterar um estilo base (mudar tipo de fonte, idioma, etc.), todos os seus derivados são automaticamente atualizados. Assim, se todos os estilos estivessem devidamente encadeados, bastaria alterar o idioma do estilo Normal para atualizar os demais. Não era o caso.

Para resolver, rodei este pequeno trecho de código:

 

Sub MudarIdiomaEstilos()
Dim s As Style
For Each s In ThisDocument.Styles
    If s.Type = wdStyleTypeParagraph Or s.Type = wdStyleTypeCharacter Or _
    s.Type = wdStyleTypeLinked Or s.Type = wdStyleTypeParagraphOnly Then
        s.LanguageID = wdPortugueseBrazil
    End If
Next s
End Sub

 

Veja que a constante LanguageID nada mais é que o código do idioma (wdPortugueseID=1046, wdEnglishUS=1033, etc.).

 

Distribuindo soluções VSTO para Office 2007 – Pré-requisitos

Desenvolver soluções Office usando o Visual Studio é uma boa evolução para quem tem anos de prática de VBA. O ambiente é mais amigável, mais produtivo (quando bem utilizado) e tem mais recursos que o velho e bom VBA. Tudo uma maravilha, até o momento de distribuir a solução. Nesta hora, sempre penso a mesma coisa: “por que não fiz em VBA?”

Instalar add-ins VSTO do Office em ambientes corporativos é algo realmente penoso. Toda a produtividade ganha na fase de desenvolvimento pode ser perdida quando se faz (ou tenta se fazer) o deployment.

Para começar, é difícil encontrar uma empresa que tenha todos os requisitos atualizados:

- .NET Framework 3.5 com SP1

- VSTO Runtime 3.0 com SP1

- Office 2007 com SP2 (este requisito não é devidamente documentado, mas importante em vários tipos de solução, especialmente se manipular Charts do Office)

 

Em ambientes corporativos, o acesso à Internet não é livre, muito menos a permissão para baixar pacotes como estes que mencionei acima. Para piorar, os links para download da Microsoft costumam trazer a versão bootstrapper, ou seja, um instalador que começa o trabalho mas faz downloads adicionais, o que não resolve o problema. Portanto, se você está montando uma pasta de instaladores de pré-requisitos (PreRecs), precisa procurar pela versão redistributable dos componentes, o que nem sempre é fácil achar.

Segue aqui uma lista de endereços:

- .NET Framework 3.5 com SP1 (este eu demorei a achar!):

 http://msdn.microsoft.com/en-us/netframework/aa569263.aspx

http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe

- VSTO Runtime 3.0:

http://www.microsoft.com/downloads/details.aspx?FamilyId=54EB3A5A-0E52-40F9-A2D1-EECD7A092DCB&displaylang=en

- VSTO Runtime SP1:

http://www.microsoft.com/downloads/details.aspx?familyid=D8EB4921-891A-4B5E-973F-0B96E6CCF376&displaylang=en

- VSTO Runtime Language Pack (para Windows em português):

http://www.microsoft.com/downloads/details.aspx?FamilyId=1DCA6E2D-5C1F-4DF8-BE5A-3D1561B8F0E3&displaylang=pt-br

- Office 2007 SP2 em português

http://www.microsoft.com/downloads/details.aspx?FamilyId=B444BF18-79EA-46C6-8A81-9DB49B4AB6E5&displaylang=pt-BR

- Office 2007 SP2 em inglês

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b444bf18-79ea-46c6-8a81-9db49b4ab6e5

Just another Microsoft MVPs site