Aprimoramentos no Visual Studio 2005
pela Microsoft
O Visual Studio 2005 fornece aos desenvolvedores de aplicativos Web uma longa lista de aprimoramentos e melhorias em projetos Web.
O Visual Studio 2005 fornece aos desenvolvedores de aplicativos Web uma longa lista de aprimoramentos e melhorias em projetos Web. Por mais poderosos que o Visual Studio .NET 2002 e 2003 sejam, houve muitas reclamações na maneira como os projetos Web foram tratados. O Visual Studio 2005 adiciona um número significativo de novos recursos para resolver essas reclamações. Para aqueles que preferem a maneira como o Visual Studio .NET 2003 lidou com a compilação de aplicativos Web, consulte Projetos de Aplicativo Web.
Neste módulo, abrange bem as melhorias na criação, gerenciamento e desenvolvimento de projetos Web. Em um módulo posterior, abrange bem as melhorias na criação de projetos Web e na implantação deles.
Extensões de servidor do FrontPage
O Visual Studio .NET 2002 e 2003 exigia extensões de servidor FrontPage na caixa para criar ou criar projetos Web. Os desenvolvedores tinham uma opção entre dois modos de acesso diferentes (Extensões do Servidor frontpage ou modo de acesso a arquivos), ambos usavam extensões de servidor FrontPage para executar tarefas como definir a raiz do aplicativo no IIS, etc.
O Visual Studio 2005 remove a dependência de Extensões do Servidor FrontPage para projetos locais. O Visual Studio 2005 agora acessa a metabase do IIS diretamente em vez de usar as Extensões do Servidor FrontPage. O Visual Studio 2005 também adiciona suporte para FTP, que permite o acesso remoto ao projeto sem a necessidade de Extensões de Servidor FrontPage.
Para os desenvolvedores que desejam usar as Extensões do Servidor FrontPage em seus projetos, a opção ainda está disponível. No entanto, com base em comentários fortes da comunidade de desenvolvedores do ASP.NET, isso não é um requisito.
Observação
As Extensões de Servidor do FrontPage ainda são necessárias para criação, abertura etc. de projeto remoto.
Visão geral do servidor de desenvolvimento do ASP.NET
O Visual Studio 2005 é fornecido com um novo servidor Web chamado ASP.NET Development Server. (Este servidor Web era anteriormente conhecido como Cassini.)
Há vários benefícios do servidor de desenvolvimento ASP.NET.
- Agora é possível que não administradores desenvolvam e depurem em um servidor Web.
- O servidor de desenvolvimento ASP.NET mapeia dinamicamente diretórios virtuais para qualquer local no sistema de arquivos, permitindo locais flexíveis do projeto.
- Os usuários do Windows XP Professional que já estão usando o IIS agora poderão criar novos aplicativos Web que não afetarão a estrutura de arquivos ou pastas de seu Site Padrão no IIS.
Nenhuma configuração especial é necessária para aproveitar o servidor de desenvolvimento ASP.NET. Quando um projeto Web hospedado no sistema de arquivos é depurado ou navegado, o Visual Studio 2005 iniciará automaticamente uma instância do servidor de desenvolvimento ASP.NET em uma porta aleatória para atender à solicitação.
Mais informações serão abordadas no servidor de desenvolvimento do ASP.NET mais adiante neste módulo.
Gerenciamento de arquivos aprimorado
No Visual Studio 2002 e 2003, um arquivo de projeto (.vbproj para VB.NET e .csproj para C#) armazenava informações em todos os arquivos no aplicativo Web. A exibição Gerenciador de Soluções baseia-se nas informações do arquivo no arquivo de projeto. Por isso, a Gerenciador de Soluções frequentemente exibia informações imprecisas nos casos em que editores externos eram usados. O Visual Studio 2002 e 2003 geralmente substituiria as alterações de arquivo ou não exibiria a versão mais recente dos arquivos.
O Visual Studio 2005 não tem o arquivo de projeto. Em vez disso, ele lê as informações de arquivo e pasta diretamente do disco, resultando em uma exibição precisa dos arquivos em seu projeto. Como a pasta Referências no Visual Studio 2002 e 2003 não representa uma pasta real em seu aplicativo Web, o Visual Studio 2005 também remove a pasta Referências do Gerenciador de Soluções. Para acessar as referências do seu projeto no Visual Studio 2005, você deve usar as páginas De propriedade para o projeto.
Criando projetos Web
Os desenvolvedores da Web têm muitas novas opções disponíveis para criação de projetos no Visual Studio 2005. Os sites agora podem ser criados em qualquer lugar no sistema de arquivos e, em seguida, podem ser depurados ou navegados usando o novo servidor de desenvolvimento ASP.NET. Os desenvolvedores também podem criar novos sites usando FTP.
Clique aqui para exibir um passo a passo em vídeo da criação de projetos Web no Visual Studio 2005.
Projetos do sistema de arquivos
Como você viu no passo a passo do vídeo, você pode optar por criar sites no sistema de arquivos no computador local ou em um local remoto por meio de um compartilhamento de arquivos. Os sites criados no sistema de arquivos são navegados e depurados usando o servidor de desenvolvimento ASP.NET.
Observação
O servidor de desenvolvimento ASP.NET pode causar alguma confusão para os clientes. Se um projeto Web for criado no sistema de arquivos na estrutura de diretório iiss (ou seja, c:/inetpub/wwwroot), o site ainda será navegado por meio do servidor de desenvolvimento do ASP.NET quando iniciado de dentro do Visual Studio 2005. Portanto, qualquer configuração do IIS (ou seja, métodos de autenticação) não é aplicável.
O projeto Web padrão também remove grande parte da sobrecarga incluindo apenas uma página Default.aspx, um arquivo default.cs e uma pasta App/_Data. Os web.config e pastas especiais (ou seja, aplicativo/_code) são adicionados conforme necessário. Seu projeto Web inclui apenas os arquivos e pastas de que você precisa.
Projetos HTTP
Os projetos HTTP podem ser projetos criados em um site do IIS local ou em um site remoto. O local padrão do projeto é http://localhost. Se você clicar no botão Procurar, haverá duas opções HTTP: IIS Local e Site Remoto. A diferença main nessas duas opções é o método no qual as informações do site são exibidas na caixa de diálogo Escolher Local e em como os arquivos são copiados para o servidor Web.
A opção IIS local lê as informações do site da metabase no computador local e os arquivos são copiados usando o sistema de arquivos. A opção Site Remoto usa as Extensões do Servidor FrontPage e as informações e os arquivos do site são copiados usando chamadas RPC de Extensões de Servidor HTTP e FrontPage.
Observação
O arquivo vs###/_tmp.htm e get/_aspx/_ver.aspx não são mais usados para determinar informações de versão.
A opção HTTP padrão é IIS Local. Essa opção lê o Metabase do IIS para determinar quais sites estão disponíveis e o local no qual criar conteúdo. Você pode selecionar uma pasta ou diretório virtual diferente selecionando-a no modo de exibição de árvore. Você também pode criar um diretório virtual, marcar pastas como aplicativos, bem como excluir diretórios virtuais existentes dessa caixa de diálogo.
Figura 1: a caixa de diálogo Escolher Local
Ao contrário das versões anteriores do Visual Studio, se você marcar caixa de seleção Usar Camada de Soquetes Seguros e o certificado SSL não corresponder à URL que você está navegando, você receberá uma caixa de diálogo Alerta de Segurança perguntando se deseja continuar. Usando o Visual Studio .NET 2003, se o certificado não for correspondente, a criação do projeto falhará.
Figura 2: Alerta de segurança sobre o certificado SSL
Observação sobre cabeçalhos de host
Se você estiver criando um aplicativo Web em um site associado a um IP específico, precisará garantir que um cabeçalho de host esteja configurado. Caso contrário, o Visual Studio criará o site em http://localhost, mas o endereço IP não resolve corretamente quando o site for navegado ou depurado de dentro do IDE.
Se você selecionar a opção Site Remoto, a caixa de diálogo será alterada para permitir que você insira a URL de destino do novo site. Essa URL deve estar em um servidor que tenha as Extensões do Servidor FrontPage habilitadas. Se você quiser trabalhar com o servidor Web local usando as Extensões do Servidor FrontPage, poderá usar a opção Site Remoto e especificar uma URL local.
Figura 3: Criando um site em um servidor remoto
Ao criar um aplicativo em um site remoto via SSL, se o certificado SSL não corresponder, a caixa de diálogo de confirmação será ligeiramente diferente da caixa de diálogo exibida ao usar a opção IIS Local.
Figura 4: o alerta de segurança de site remoto
FTP
O Visual Studio 2005 apresenta a opção de criar sites via FTP. Quando você usa essa opção, o IDE cria os arquivos localmente na pasta temporária usuários e, em seguida, usa FTP para mover os arquivos para o local ftp.
Observação
O local da pasta temporária é c:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>
Ao usar a opção FTP, você receberá uma caixa de diálogo Escolher Local. Insira as informações de conexão FTP necessárias nessa caixa de diálogo, conforme mostrado abaixo.
Figura 5: a caixa de diálogo Escolher Local para FTP
Laboratório: Configurar o site ftp e criar um projeto
As etapas a seguir configuram o site ftp para que um usuário tenha um local para o qual somente ele possa carregar via FTP.
Instalar o serviço FTP
- Abra Adicionar Remover Programas, selecione Adicionar/Remover Componentes do Windows
- Selecione Serviços de Informações da Internet (Servidor de Aplicativos no Windows 2003) e clique em Detalhes.
- Verifique o Serviço ftp (protocolo FTP) e clique em OK.
- Clique em Avançar para instalar o serviço FTP.
Criar uma nova pasta para conteúdo
- No Windows Explorer, crie uma nova pasta chamada User1 dentro de c:/inetpub/wwwroot.
Configure pastas e permissões em pastas.
- Abra o snap-in Serviços de Informações da Internet em Ferramentas Administrativas. Agora você terá uma pasta sites FTP no nó nome do computador.
- Expanda Sites ftp.
- Clique com o botão direito do mouse no Site FTP Padrão, selecione Novo e Diretório Virtual e clique em Avançar.
- Insira User1 para o nome do diretório virtual e clique em Avançar.
- Insira c:/inetpub/wwwroot/User1 para o caminho e clique em Avançar.
- Clique em Avançar e em Concluir para concluir o assistente.
- Clique com o botão direito do mouse no diretório virtual User1 em Site FTP Padrão e selecione Propriedades.
- Marque a caixa de seleção Gravar e clique em OK para fechar a caixa de diálogo.
- Clique com o botão direito do mouse em Site FTP Padrão e selecione Propriedades.
- Na guia Contas de Segurança, desmarquePermitir Conexões Anônimas.
- Clique em Sim na caixa de diálogo perguntando se você deseja continuar.
- Clique em OK para fechar o diálogo.
- Expanda o Site Padrão no nó Sites .
- Clique com o botão direito do mouse no diretório User1 e selecione Propriedades
- Na seção Configurações do Aplicativo , clique em Criar para marcar a pasta como um aplicativo.
- Clique em OK para fechar o diálogo.
- Feche o snap-in serviços de informações da Internet.
Criar projeto Web
- Abra o Visual Studio 2005.
- No menu Arquivo , selecione Novo Site.
- Na lista suspensa Local , selecione FTP.
- Clique em Procurar.
- Insira localhost na caixa de texto Servidor .
- Insira User1 na caixa de texto Diretório.
- Clique em Abrir. O local do FTP será inserido na caixa de diálogo Novo Site.
- Clique em OK.
- Desmarque Logon anônimo na caixa de diálogo Logon do FTP, insira suas credenciais e clique em OK.
- Qual é a URL do projeto? (A URL do projeto será exibida em Gerenciador de Soluções.)
- No menu Compilar , selecione Criar Site ou Compilar Solução.
- Clique com o botão direito do mouse em Default.aspx no Gerenciador de Soluções e selecione Exibir no Navegador.
- Na caixa de diálogo URL do Site Necessária, insira
http://localhost/user1para a URL e clique em OK.
Observação
Se você receber um erro indicando uma incapacidade de carregar o tipo /_Default, verifique se está executando ASP.NET 2.0 em seu site e não em uma versão anterior. Você pode fazer isso na guia ASP.NET nos Serviços de Informações da Internet.
Abrindo projetos Web
Abrir projetos Web é semelhante à criação de projetos. As seções a seguir chamam áreas para ficar atento ao trabalho dentro do IDE. Ele também aborda o trabalho com projetos Web usando HTTP e FTP.
Para abrir um projeto Web, selecione Abrir Site no menu Arquivo. Você será solicitado com a mesma caixa de diálogo Escolher Local abordada anteriormente e terá as mesmas quatro opções disponíveis para você: Sistema de Arquivos, IIS Local, FTP e Site Remoto.
Sistema de Arquivos
Conforme indicado anteriormente neste módulo, o Visual Studio não usa mais um arquivo de projeto. Portanto, se você optar por abrir um site do sistema de arquivos, terá a opção de escolher qualquer pasta desejada, mesmo que a pasta escolhida não tenha sido criada como um projeto Web inicialmente no Visual Studio. Por exemplo, você pode optar por abrir a pasta Meus Documentos como um site e o Visual Studio a abrirá com prazer e exibirá seus arquivos, conforme mostrado abaixo.
Figura 6: Meus documentos abertos como um site
Como o Visual Studio só cria arquivos e pastas adicionais quando necessário, nenhum arquivo ou pasta adicional é adicionado ao local aberto. Um efeito colateral dessa arquitetura é que ela impede o aninhamento de sites no sistema de arquivos. Por exemplo, considere a estrutura de diretório a seguir.
Projeto Web em C:/MyWebSite
Outro projeto Web em C:/MyWebSite/Nested
Quando você abrir o site em c:/MyWebSite, a pasta Aninhada aparecerá como uma subpasta desse aplicativo.
HTTP
Ao abrir sites via HTTP, as configurações são lidas na metabase do IIS (IIS local) ou usando extensões de servidor frontpage (site remoto).) Se houver aplicativos Web aninhados, eles também serão exibidos com um ícone identificando-os como um aplicativo. Se você estiver familiarizado com o trabalho com aplicativos Web no FrontPage, o comportamento no Visual Studio 2005 será semelhante.
Embora o Visual Studio exiba um ícone para aplicativos aninhados abaixo do aplicativo que está aberto atualmente no IDE, ele não permitirá que você os expanda para ver seu conteúdo. No entanto, você pode clicar duas vezes neles para abri-los. Ao fazer isso, você receberá uma caixa de diálogo solicitando que você abra o aplicativo Web (e substitua a solução aberta no momento) ou adicione o aplicativo Web à sua solução atual.
Figura 7: Clicar duas vezes em um ícone de aplicativo aninhado apresenta essa caixa de diálogo
Site FTP
Quando você abre um site via FTP, todos os arquivos são copiados localmente para sua pasta temporária. O caminho completo para o local de armazenamento local é exibido no painel Propriedades do projeto e é criado usando o formato a seguir.
C:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>
Ao usar o FTP, o Visual Studio precisará especificar a URL base do projeto para que você possa navegar por ele, conforme mostrado abaixo. Se você não especificar uma URL base, o Visual Studio o solicitará na primeira vez que você tentar navegar por uma página no site.
Figura 8: Especificando uma URL base para sites FTP
Melhorias na compilação
Trabalhar com aplicativos Web no Visual Studio 2005 é visivelmente mais rápido do que as versões anteriores. Isso se deve, em grande parte, às alterações na arquitetura de compilação.
No Visual Studio 2002 e 2003, os aplicativos Web foram compilados em um assembly primário que reside na pasta /bin. No Visual Studio 2005, uma pasta App/_Code foi adicionada. Classes e outros códigos que não são da interface do usuário são adicionados à pasta App/_Code. Quando o Visual Studio compila o projeto, todos os arquivos na pasta App/_Code são compilados em um único arquivo app/_Code.dll. O resultado dessa alteração é que os builds subsequentes são muito mais rápidos do que nas versões anteriores.
Observação
O utilitário de linha de comando do MSBuild também pode ser usado para criar ASP.NET aplicativos Web. Essa ferramenta será abordada no módulo 9.
Outro aprimoramento de compilação é a nova opção Página de Build no menu Compilar. Esse recurso permite que um desenvolvedor recompile apenas a página atual (juntamente com, é claro, e dependências) para que as alterações possam ser compiladas mais rapidamente. Como o C# não oferece compilação em segundo plano para fins de atualização do IntelliSense etc., eles se beneficiarão imensamente desse recurso, pois permitirão que o IntelliSense seja atualizado rapidamente simplesmente recriando uma única página.
As propriedades Build de um projeto permitem que você configure o tipo de build que ocorre antes da página de inicialização ser executada. Os desenvolvedores podem optar por criar apenas a página atual para que o Visual Studio possa iniciar a depuração de aplicativos mais rapidamente após as alterações de código.
Figura 9: a ação de início da página de build
Outro ótimo aprimoramento para o Visual Studio e a arquitetura de ASP.NET está na área de edição e continuação. No Visual Studio 2005, os desenvolvedores podem começar a depurar um projeto e fazer alterações de código no projeto sem desanexar o depurador. Na verdade, você pode literalmente começar a depurar um projeto, adicionar uma nova classe, adicionar código a essa classe, adicionar código à sua página que cria uma nova instância dessa classe e executar um método da classe , tudo sem desanexar o depurador. Executar o novo código é literalmente tão fácil quanto atualizar o navegador!
Clique aqui para ver um passo a passo em vídeo do recurso editar e continuar no Visual Studio 2005.
A funcionalidade robusta de edição e continuação no ASP.NET 2.0 e no Visual Studio 2005 ocorre devido a uma alteração arquitetônica para aplicativos ASP.NET. No ASP.NET 1.x, os aplicativos criados no Visual Studio 2002/2003 foram compilados em um assembly primário armazenado na pasta /bin. Todas as classes, páginas etc. para o aplicativo foram compilados nessa DLL. Em seguida, em runtime, ASP.NET compilaria todos os controles, marcação e ASP.NET código em páginas e copiaria essas DLLs para a pasta temporária ASP.NET.
No Visual Studio 2005 usando ASP.NET 2.0, os dois modelos de compilação descritos acima (um para Visual Studio e outro para ASP.NET em runtime) foram mesclados em um modelo de compilação comum. Isso significa que todos os problemas de compilação agora são capturados durante o estágio de desenvolvimento em vez de em runtime. Ele também permite suporte ao designer e ao IntelliSense para recursos como controles de usuário e páginas de master.
Clique aqui para ver um passo a passo em vídeo do suporte do designer para controles de usuário.
Observação
Quando um controle de usuário é removido de uma página, a @Register diretiva permanece na marcação e deve ser removida manualmente para evitar erros de analisador se o controle do usuário for excluído do site.
Outra melhoria no modelo de compilação do Visual Studio é o recurso Publicar Site. Como o recurso Publicar pré-compila o site, os desenvolvedores podem aproveitar o desempenho adicional de não precisar compilar nada sob demanda. Ele também pré-compila todo o código-fonte na pasta App/_Code em uma DLL para que nenhum código-fonte precise ser implantado.
Figura 10: a caixa de diálogo Publicar Site
Observação
O utilitário aspnet/_compile.exe também pode ser usado para pré-compilar um aplicativo Web ASP.NET. Essa ferramenta será abordada no módulo 9.
Quando você publica um site, os arquivos pré-compilados são armazenados na pasta Arquivos de ASP.NET Temporários, conforme mostrado abaixo. Arquivos com uma extensão de arquivo .compiled são arquivos XML que definem dependências para DLLs específicas. Todos os controles webform ou de usuário são compilados em DLLs aleatórias que começam com o Aplicativo/Web/.
Se você deixar a caixa de seleção Permitir que este site pré-compilado seja atualizado, a marcação dentro de seus webforms e controles de usuário não será pré-compilada em uma DLL, permitindo que você faça alterações após a implantação. Se você preferir bloquear a marcação para que as alterações no conteúdo implantado não sejam permitidas, desmarque essa caixa.
A caixa de seleção Usar assemblies de nomenclatura fixa e de página única permite desabilitar a compilação em lote para que cada página seja compilada em um assembly de nome fixo. Sair dessa caixa desmarcada permite que você aproveite a compilação em lote.
A caixa de seleção Habilitar nomenclatura forte em assemblies pré-compilados permite que você nomeie fortemente seus assemblies pré-compilados.
Observação
No ASP.NET 1.x, assemblies de nome forte precisaram ser instalados no GAC (Cache de Assembly Global). No ASP.NET 2.0, você não precisa instalar assemblies de nome forte no GAC.
Figura 11: um ASP.NET arquivos pré-compilados de aplicativos
Observação
No aplicativo acima, não havia nenhum arquivo web.config. Se houvesse, ele teria sido chamado PrecompiledApp.config após o processo publicar site da Web.
Melhorias na implantação
Assim como acontece com o Visual Studio 2002 e 2003, o Visual Studio 2005 oferece um recurso de Projeto de Cópia. No entanto, o recurso foi reforçado no Visual Studio 2005 e agora é chamado de Copiar Site.
A caixa de diálogo Copiar Site é dividida em um quadro esquerdo e um quadro à direita. O quadro à esquerda é chamado de Site de Origem e o quadro à direita é chamado de Site Remoto. Uma coisa que pode confundir alguns desenvolvedores é que o site exibido no quadro certo não é necessariamente um site remoto. Pode ser um site no sistema de arquivos local ou na instância local do IIS. Além disso, o site exibido no quadro esquerdo não é necessariamente o site de origem porque a caixa de diálogo permite que você publique do site remoto para o site de origem.
Se você estiver copiando um projeto para um site remoto, esse site deverá ter as Extensões do FrontPage Server instaladas nele. Se isso não acontecer, você precisará se conectar usando FTP. Por outro lado, se você estiver copiando um projeto para a instância do IIS local, as Extensões do Servidor FrontPage não serão necessárias.
Observação
Se você tentar criar um novo site na instância do IIS local e as Extensões de Servidor do FrontPage 2002 estiverem instaladas, receberá uma mensagem de erro informando que a criação de sites não tem suporte em um servidor do SharePoint. Nesse caso, você tem a opção de instalar as Extensões de Servidor do FrontPage 2000 ou remover as Extensões do FrontPage Server.
Clique aqui para obter um passo a passo de vídeo do recurso Copiar Site.
Melhorias na depuração
Há quatro melhorias importantes na depuração no Visual Studio 2005.
- A depuração localmente como um não administrador é possível pronta para uso.
- O atributo Debug para o elemento Compilation agora é false por padrão.
- A configuração e a configuração de depuração remota são mais fáceis do que antes.
- Agora você pode depurar um site aberto por meio de um local ftp.
Depuração como um não administrador
A adição do servidor de desenvolvimento ASP.NET permite que os não administradores depurem facilmente ASP.NET aplicativos imediatamente da caixa. Quando um aplicativo ASP.NET em execução no sistema de arquivos local é depurado, o Visual Studio inicia o ASP.NET Development Server no contexto do usuário conectado. Esse usuário pode depurar esse aplicativo sem nenhuma configuração adicional.
Depurar é False por Padrão
No ASP.NET 1.x, o atributo de depuração no elemento de compilação do arquivo web.config foi definido como true por padrão. Sempre foi recomendável que os desenvolvedores definissem esse atributo como false antes de implantar um aplicativo em produção, mas como a maioria dos desenvolvedores não entende completamente as consequências de deixar o atributo de depuração definido como true, eles simplesmente o deixaram no estado em que se encontram.
O problema mais grave em ter o atributo de depuração definido como true é que ele desabilita o ASP. Modelo de compilação em lote do NETs. Portanto, cada página é compilada em uma DLL separada. Se um aplicativo Web consistir em milhares de páginas (não inédito por qualquer meio), isso significa que milhares de DLLs pequenas serão criadas por esse aplicativo. Embora essas DLLs sejam pequenas em tamanho, elas não são carregadas em nenhum local específico na memória. Portanto, eles causam fragmentação na memória do sistema e podem contribuir para ocorrências de OutOfMemoryException.
No ASP.NET 2.0, o atributo de depuração é definido como false por padrão. Como você já viu, quando um desenvolvedor depura um aplicativo ASP.NET no Visual Studio 2005, ele é solicitado a adicionar um arquivo web.config com a depuração habilitada. Isso incorre nas mesmas desvantagens que estavam presentes no ASP.NET 1.x, mas agora o desenvolvedor é claramente avisado de que o atributo deve ser redefinido para false antes de mover o aplicativo para produção.
Configuração e configuração de depuração remota
No Visual Studio 2002/2003, a depuração remota dependia do Gerenciador de Depuração do Computador (mdm.exe) e do processo de vs7jit.exe. Por isso, a solução de problemas de depuração remota geralmente era uma caixa preta para os clientes e muitas vezes não era muito melhor para o PSS.
O Visual Studio 2005 remove a dependência dos processos de mdm.exe e vs7jit.exe. Em vez disso, agora ele usa o serviço Monitor de Depuração Remota (msvsmon.exe.)
O requisito de depuração no Visual Studio 2005 remotamente é bastante simples. Você precisa executar msvsmon.exe no servidor remoto antes da depuração. Você pode instalar o Monitor de Depuração Remota do CD do Visual Studio ou simplesmente executar msvsmon.exe de um compartilhamento sem instalar nada no servidor Web.
Quando você executa msvsmon.exe, é provável que ele reclame de portas sendo bloqueadas para depuração remota. Felizmente, você pode desbloquear facilmente as portas diretamente na caixa de diálogo de aviso, conforme mostrado abaixo.
Figura 12: Notificação de que o Firewall do Windows está bloqueando a depuração remota
Depois de desbloquear as portas necessárias para depuração, você verá o Monitor de Depuração Remota, conforme mostrado abaixo. Nessa interface, você pode monitorar conexões e alterar facilmente as permissões de depuração.
Figura 13: o monitor de depuração remota
Também é possível depurar remotamente um aplicativo Web aberto via FTP. As etapas são as mesmas que as abordadas anteriormente. No entanto, você precisará especificar uma URL base para navegar no projeto FTP, conforme descrito anteriormente neste módulo.
Laboratório 2
Depuração remota com o Visual Studio 2005
Este laboratório orientará você na depuração remota com o Visual Studio 2005.
Clique aqui para obter um passo a passo de vídeo deste laboratório.
Este laboratório exige que você tenha dois computadores, um executando o Visual Studio 2005 e outro executando o IIS 5 ou superior.
- Abra o Visual Studio 2005 e crie um novo site no servidor remoto.
Observação
Você pode criar o site em uma instância remota do IIS ou por meio de FTP.
- No servidor Web remoto, localize msvsmon.exe no computador de desenvolvimento usando um caminho UNC e execute-o.
O local padrão para msvsmon.exe é //server/c$/Program Files/Microsoft Visual Studio 8/Common7/IDE/Remote Debugger/x86. - Se solicitado a desbloquear portas para depuração remota, faça isso.
- No computador de desenvolvimento, abra o code-behind para Default.aspx e defina um ponto de interrupção no método Page/_Load.
- Inicie a depuração do computador de desenvolvimento.
Você deve atingir o ponto de interrupção conforme o esperado.
Iniciando o ASP.NET Development Server
Como já discutimos, o Visual Studio 2005 é fornecido com um servidor Web chamado ASP.NET Development Server. (O servidor de desenvolvimento ASP.NET às vezes é chamado de Cassini.) Esse servidor Web é um meio conveniente para procurar e depurar aplicativos Web em execução no sistema de arquivos.
O ASP.NET Development Server é um servidor Web restrito. Ele não permite conexões remotas, não permite nenhuma solicitação de nenhum usuário que não seja o usuário que iniciou o servidor Web. Ele também não tem a capacidade de servir páginas ASP. Somente ASP.NET recursos e recursos HTML (incluindo imagens, arquivos CSS etc.) são atendidos.
O servidor de desenvolvimento ASP.NET pode ser iniciado por meio da linha de comando executando o arquivo WebDev.WebServer.exe localizado em c:/Windows/Microsoft.NET/Framework/v2.0./////*. A caixa de diálogo a seguir exibe os parâmetros disponíveis.
Figura 14
Observação
Não há suporte para o servidor de desenvolvimento ASP.NET quando iniciado explicitamente por meio da linha de comando.