Cenários para exemplos de implantação
Vamos supor que temos MyApplication.exe e MyLibrary.DLL, ambos criados com o MFC.MyApplication.exe depende MyLibray.DLL, ambos usam MFC em uma DLL compartilhada e ambos podem ser misto ou nativo (/ clr) os binários.No caso mais simples, ambos são gerados pelo assistente sem alterar as configurações padrão.Os exemplos nesta seção descrevem como implantar esse aplicativo para outro computador no qual o Visual Studio não está instalado.Esta seção aborda principalmente Implantando a versão do aplicativo; no entanto, as alterações necessárias para implantar a versão de depurar de um aplicativo estão apontadas.
Observação: |
---|
Redistribuindo depurar V isual Programas do C++ não é permitida por esse acordo.No entanto, você pode implantar-las temporariamente para fins de depuração .Consulte o que EULA para o Visual Studio 2008 de termos de licença de software . |
Configuração inicial
Há três computadores a serem considerados nessa situação.
Computador de desenvolvimento é no qual o aplicativo é criado.Ele tem Visual Studio 2005 (STD, PRO ou TS) instalado.
Os computadores de destino dois implantação não são necessário Visual Studio 2005 instalado. Implantação de destino 1 é um computador que executa um sistema operacional que suporte vinculação baseada em manifesto de aplicativos para suas dependências (Windows XP Home Edition, Windows XP Professional, Windows Server 2003Windows Vista). Implantação de destino 2 executa um sistema operacional sem esse suporte (Windows 2000).
O meta é criar o aplicativo no computador de desenvolvimento, implantá-lo para os computadores de destino de dois e executá-lo.
Preparação
Quando você criou um Visual C++ binário que vai ser executado em outro computador, você precisa determinar quais DLLs este binário depende. Uma ferramenta útil para isso é dependência Walker.Nesse cenário, você deve considerar o Visual C++ DLLs em determinado CRT e MFC. Se você em em aberto a versão de depurar do MyApplication.exe no Visual Studio e navegue por meio de seus recursos, você pode ver o recurso RT_MANIFEST.Este é o manifesto incorporado dentro de binário.Se você exportá-lo e em em aberto sistema autônomo um arquivo XML, consulte o seguinte:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugMFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Isso significa que este aplicativo depende desses assemblies:
Assembly Microsoft.VC90.DebugCRT, versão 9.0.xxxxx.yy para x86
Assembly Microsoft.VC90.DebugMFC, versão 9.0.xxxxx.yy para x86
Controles Microsoft.Windows.Common de assembly, versão 6.0.0.0 para x86
O binário do versão, você verá isso:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Isso significa que este aplicativo depende desses assemblies:
Assembly Microsoft.VC90.CRT, versão 9.0.xxxxx.yy para x86
Assembly Microsoft.VC90.MFC, versão 9.0.xxxxx.yy para x86
Controles Microsoft.Windows.Common de assembly, versão 6.0.0.0 para x86
Você vê manifestos semelhantes no MyLibrary.dll, tanto para depurar e versão.Observe que a ID de manifesto é 1 para um EXE, 2 para uma DLL.Além disso, se o manifesto não está incorporado no binário, ele é armazenado sistema autônomo <binaryname>. .manifest <extensão>e tem o mesmo conteúdo.
Observação: |
---|
Visual Studio 2005 não oferece suporte ao C++ de criação de aplicativos sem um manifesto e vinculação a bibliotecas Visual C++ da maneira antiga usando % caminho %. Além disso, Visual C++ DLLs pode detectar isso, impedir que a DLL seja carregado e relatar o cenário sem suporte e as alterações necessárias.Não use /manifest:no ou excluir o manifesto. |
Métodos de implantação
Neste exemplo, você instalará MyApplication.exe para a pasta % destino % que pode ser especificado pelo cliente durante a instalar.MyLibrary.dll será instalado em % destino%\MyLibrary e \MyLibrary adicionados ao caminho.
Vamos examinar dois métodos para implantar aplicativos do VC ++:
Criando um pacote de instalação usando um programa de instalação e o projeto de implantação.
Implantação do XCopy.
Para cada método, exploraremos a dois cenários:
Implantando bibliotecas Visual C++ sistema autônomo assemblies compartilhados.
Implantar bibliotecas Visual C++ sistema autônomo conjuntos privados.
No cenário 1, há apenas uma cópia do Visual C++ DLLs na pasta WinSxS.Cenário 2, você terá duas cópias das DLLs Visual C++, instalados no aplicativo do EXE e da DLL pastas locais.
Observação: |
---|
Cenário 2 não é suportado em Windows 2000 porque a implantação em pastas de aplicativo local cria problemas quando se trata de serviço. |
Consulte também
Tarefas
Como: Implantar uma configuração e projeto de implantação