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