Pergunta

Estamos recebendo novos dev máquinas e movendo-se para Vista 64 Ultimate para tirar vantagem da nossa 8gb de ram.Nosso gerente quer que a gente faça tudo dev em 32 bits máquinas virtuais para se certificar de que não haverá problemas com o nosso código de mover-se em produção.

Existe alguma maneira de garantir a resultante programas irão funcionar em 32 bits so?Eu não me importo de usar máquinas virtuais, mas eu não gosto de como eles forçá-lo de volta para uma "Simples" tipo de monitor de vista.Eu gosto de mover o meu VS barras de ferramentas fora de meu outro monitor.

EDITAR:Estamos usando o Visual Studio 2005 e 2008, VB.NET e/ou C#

EDITAR:Usando Harpreet do responder, estes são os passos que eu usei para o meu Visual Studio IDE para compilar x86 / 32 bits:

  1. Clique em Criar e abrir o Gerenciador de Configuração
  2. Selecione Active Plataforma de Solução de lista pendente
  3. Selecione x86 se ele está na lista e vá para o passo 5, se não Selecionar <New...>
  4. Na Nova Solução de Plataforma de diálogo, selecione x86 e prima OK
  5. Verifique se a plataforma selecionada para todos os seus projetos é x86
  6. Clique Em Fechar.

Desfrute.

Obrigado, Keith

Foi útil?

Solução

Eu faço de desenvolvimento em computadores de 64 bits para 32 bits do Windows.Não é um problema.Você deve se certificar de que os seus projetos são definidos para compilar em x86, de modo a ser conservadora.Você vai querer passar por cada projeto na solução e verifique isso.Você também pode usar a AnyCPU de configuração, mas isso é um pouco arriscado, pois será executado de forma diferente no seu computador de dev do que uma máquina de 32 bits.Você quer evitar o 64bit modo, é claro.

Os problemas que eu tenho que correr em são drivers que não funcionam quando o aplicativo é compilado para 64 bits (explicitamente 64 bits ou AnyCPU compilado e executado no Windows de 64 bits).Os problemas são completamente evitáveis por ficar com o x86 de compilação.Que deve revelar todas as falhas em sua dev máquinas.

Idealmente, você poderia configurar uma compilação de ambiente de teste que pode ser executado em relação a freqüência em uma máquina de 32 bits.Que devem assegurar a sua gestão e permitem que você evite a VM como sua área de trabalho.

Outras dicas

Contanto que você compilar seus executáveis 32 bits, eles serão executados em ambas as versões de 32 bits e 64 máquinas Windows (garantido).O uso de 64 dev máquinas tem a vantagem de que você pode começar a testar o seu código com o de 64 bits compilação (para verificar coisas como ponteiros escalado para 32 bits inteiros), esta forma de fazer a transição para a versão de 64 bits mais fácil no futuro, caso a sua empresa optar por uma versão de 64 bits).

Compilar para 64bit é uma opção do compilador.Você não pode absolutamente compilar para uma 32bit exe a partir de dentro Vista de 64 bits.Quando você executa o aplicativo, em seguida, você pode ver no TaskManager que existe um "*32" avançar para o processo...isso significa que é de 32 bits ;)

Eu acredito que a sua empresa exige um pouco mais de educação no que 64bit significa realmente :)

Não uma resposta para sua pergunta, mas, possivelmente, uma solução para o seu problema:VirtualBox (e provavelmente outras) oferece suporte a "integração" de modo, que apenas dá-lhe uma segunda barra de início e permite que você arraste o windows livremente.

Também, e esta é uma resposta para a sua pergunta, depende do seu compilar definições.Você pode compilar para ambientes diferentes, e você pode perfeitamente compilar programas de 32 bits em um sistema de 64 bits com o Visual Studio.Não posso dizer como, mas tenho certeza de que alguns Visual Studio guru pode ajudá-lo.

Desenvolvemos um aplicativo de 32 bits usando o VS 2005 (2008 logo) e acaba de adquirir algumas novas máquinas com XP Pro x64 ou Vista Business 64 bits sobre eles, para que possamos aproveitar o extra RAM como se estivessem assistindo um breve sobre a possibilidade de fazer uma versão de 64-bit da porta se torna comercialmente necessário fazê-lo.Não tivemos problemas com isso, outras que ajustar alguns scripts em nosso ambiente de desenvolvimento, etc.

Os programadores que não estão incluídas neste ciclo de atualização ainda usam máquinas de 32 bits, por isso, estes devem pegar problemas quando os testes de unidade e a aplicação do conjunto de teste são executados como uma questão de curso antes do check-in.

O que também podemos fazer é certificar-se de que nós temos um conjunto de "teste de criar" máquinas " composta de "típico" configurações (XP/Vista, 2/4/8 núcleos, etc.) que construir e testar conjuntos de check-ins - temos vários conjuntos de teste para a estabilidade, desempenho, etc.- antes de serem adicionados à área de integração adequada.Novamente, estes ainda não pegou qualquer problemas com a execução de um aplicativo de 32 bits construído sobre um sistema operacional de 64 bits.

De qualquer maneira, como outros já disseram, eu não esperaria que isso é um problema, porque é o compilador que gera o código apropriado para o sistema operacional de destino, independentemente do sistema operacional que o compilador está realmente sendo executado.

sim, como adão estava dizendo.Há 3 opções:MSIL (padrão), x64 e x86.Você pode segmentar x64 e ele irá gerar a dll especificamente para sistemas de 64 bits, ou você pode fazer x86 que será executado em versões de 32 bits e de 64 bits, mas vai ter as mesmas restrições de 32 bits em uma versão de 64-bit do sistema.

MSIL será, basicamente, deixe o JITer questão específica da plataforma de instrução (em uma pequena penalidade de desempenho em comparação a uma imagem nativa)

EDITAR:nenhum idioma, por isso que eu estou falando .net framework idiomas como vb.net e c#, c++ é completamente diferente do animal.

Encontrei este de hoje:

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

Desenvolvimento x64 com .NET

No início deste ano eu fiz a mudar para um sistema operacional de 64 bits - Vista Ultimate x64, para ser exato.Para a maior parte, este processo tem sido relativamente indolor, mas houve alguns percalços ao longo do caminho (x64 compatíveis drivers, principalmente, mas não é esse o ponto desta discussão).

No mundo do desenvolvimento x64, houve algumas dificuldades pontos que eu gostaria de descrever aqui.Essa lista provavelmente vai crescer, então espere posts futuros sobre o assunto.

No maravilhoso mundo dos .NET desenvolvimento, aplicações e montagens podem ser compilado para o destino de várias plataformas.Por padrão, os aplicativos e conjuntos são compilados como Qualquer CPU no Visual Studio.Neste cenário, o CLR carregar o conjunto, qualquer que seja o destino padrão é a máquina que está a ser executado.Por exemplo, ao executar um executável em uma máquina x64, ele será executado como um processo de 64 bits.

O Visual Studio também fornece para 3 plataforma específica metas:as arquiteturas x86, x64 e Itanium (IA-64).Quando a construção de um executável como um alvo específico, ele será carregado como um processo desse tipo.Por exemplo, um x 86-alvo executável executar em uma máquina x64 será executado como um processo de 32 bits usando a versão de 32 bits do CLR e WOW64 camada.Quando assemblies são carregados em tempo de execução, que só podem ser carregadas por um processo se o seu destino coincide com o processo de hospedagem, ou ele é compilado como Qualquer CPU.Por exemplo, se x 64 foram definidos como o destino, para uma assembleia, só pode ser carregada por um processo de 64 x.

Este tem entram em jogo em alguns cenários para mim:

  • XNA - XNA está disponível como um conjunto de 32 bits assembléias só.Portanto, ao fazer referência a XNA assembléias, o executável/montagem usando eles devem ser direcionados para a plataforma x86.Se ele é apontado como x64 (ou como Qualquer CPU e executado em uma máquina de 64 bits), um erro será gerado ao tentar carregar o XNA assembléias.

  • O Microsoft Robotics Studio - XInputGamepadService usa o XNA internamente para falar com o controlador Xbox 360.Veja acima.

  • Managed DirectX - Enquanto isso já está obsoleto e foi sendo substituído com o XNA, ele ainda tem seus usos.As assembléias não são marcados para um alvo específico, no entanto, eu tinha dificuldade com a memória exceções, especialmente com a Microsoft.DirectX.AudioVideoPlayback assembleia.

  • Phidgets - Dependendo de qual biblioteca o download e quando, ele pode ou não pode ser marcado como somente de 32 bits.A versão atual (11/8/07) é marcado como tal, e isso exige um processo de 32 bits para host.A maneira mais fácil de determinar se um arquivo executável ou de montagem é direcionado para uma plataforma específica é usar o corflags aplicação.Para usar isso, abra um Prompt de Comando Visual Studio a partir do seu menu Iniciar e execute-o em relação a montagem que você deseja verificar.

A maneira mais fácil de determinar se um arquivo executável ou de montagem é direcionado para uma plataforma específica é usar o corflags aplicação.Para usar isso, abra um Prompt de Comando Visual Studio a partir do seu menu Iniciar e execute-o em relação a montagem que você deseja verificar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top