Pular para o conteúdo principal

Não misture Visual Studio 10 com o Developer Preview!

Infelizmente, eu caí na asneira de experimentar o Visual Studio 11 Developer Preview no meu sistema principal de desenvolvimento.

O Developer Preview é razoável, e a presença dos testes de unidade para C++ me fizeram muito satisfeito.

Porém, o Visual Studio 10 não funciona direito quando misturado com o Visual Studio 11 Developer Preview. O instalador do Developer Preview sobrescrever alguma configuração no sistema que é compartilhada com o 10.

O primeiro efeito colateral que eu percebi foi nos projetos .NET, o que me levou a supor a natureza do problema. Projetos .NET começaram a indicar problemas nas referências a outros projetos -- com um ícone de exclamação em vermelho na tela de referências. A Internet me informa que isto é sinal de que os projetos ligados como referência são incompatíveis -- o referido indica uma versão do .NET mais recente que o referente.

Minha hipótese é a de que o instalador do Developer Preview define, em algum lugar central, que o .NET 4.5 beta é a versão que o Visual Studio -- todos! -- devem usar. Apesar de fazer a maior parte do meu desenvolvimento no Visual C++, aprendi como usar os testes de unidade C++/CLI para me beneficiar. É claro que estes projetos são .NET e portanto pararam de funcionar.

Para limpar esta bagunça, removi o Visual Studio 11 Developer Preview e todas as ocorrências de .NET 4.5 do meu sistema. Depois, executei o "repair" do Visual Studio 10 e o "repair" do Visual Studio 10 SP1. Tudo está funcionando normalmente até um dia depois do susto.
Marcadores:

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Análise vs. Projeto

Eu diria que a ruptura entre Análise e o Projeto acontece quando acabam as considerações sobre o problema e começam as considerações sobre a solução. Em outras palavras, o papel do Analista é considerar o problema, enquanto o papel do Projetista é o de considerar a solução. Assim, o Analista aparece quando um problema aparece, e dá lugar ao Projetista quando o problema foi devidamente analisado, restando produzir para ele uma solução. E diria que a ruptura entre a Especificação e a Implementação acontece quando acabam os artefatos para consumo por humanos e começam os artefatos para consumo por máquinas. Em outras palavras, o papel do Especificador é produzir artefatos para consumo por humanos, enquanto o papel do Implementador é produzir artefatos para consumo por máquinas. Assim, o Especificador aparece quando a atividade é produzir efeitos sobre humanos, e dá lugar ao Implementador quando os humanos estão devidamente satisfeitos e a atividade prossegue para produzir efeito...
Postar um comentário
Leia mais

JNDI e Plan 9

Acabei de realizar quão similar é o J2EE e o Plan 9 quando observados pela lente da arquitetura de componentes: no Plan 9, o sistema de arquivos é tão capaz quanto o JNDI no J2EE. Um componente no qual eu estou trabalhando agora depende de um componente de banco de dados e de um componente de correio eletrônico. O modo de ligação entre esses componentes se dá através de JNDI: meu componente faz referência aos nomes "dataSource" e "mailSession" no seu contexto local de nomes. Na configuração do componente em uma instalação, esses nomes locais são ligados aos nomes globais que o administrador preparou para oferecer as dependências. É claro que tanto o meu componente quanto suas dependências mantém um contrato entre si, na forma das interfaces java EntityManager e Session. No Plan 9, meu componente seria um programa que faz referência a dois arquivos no seu file system -- um arquivo que repr...
Postar um comentário
Leia mais

O Problema de Gestão de I/O

A palestra que dei no Sétimo Encontro do Grupo de Usuários de C e C++ do Brasil apresentou meu resultado atual na pesquisa de um framework baseado em uma forma de orientação a aspectos em C++ descrita no "Modern C++ Design" do Alexandrescu. Minha palestra não apresentou, porém, o que é exatamente o problema a resolver, assumindo que fosse razoavelmente conhecido. Seu foco foi apresentar todos os mecanismos disponíveis para se resolver o problema no Linux 2.6, suas peculiaridades e seus aspectos comuns. Uma certa razão me motivou, após esta apresentação, a rebobinar meu raciocínio e considerar o problema original. [1] O que há exatamente de tão problemático na gestão de I/O em um programa? A imagem inicial é a de um programa cujo objetivo é interagir com um dos dispositivos ligados ao computador. A forma básica dessa interação é a cópia de dados do dispositivo para a memória e da memória para o dispositivo, sendo que trabalho útil por parte do programa ocorre enquanto os...
Postar um comentário
Leia mais