• Artigo

Por dentro da Microsoft.comGerenciamento e delegação de ASP.NET

Jeff Toews

A infra-estrutura Web do microsoft.com é executada quase que totalmente no .NET Framework 2.0. Um dos principais desafios da administração da Web da equipe de operações do microsoft.com é a própria configuração do ASP.NET. Aprendemos muito tentando ajustar nossas configurações à perfeição. Para obter

as configurações certas é necessário um bom conhecimento do trabalho das várias seções de configuração nos arquivos web.config e machine.config e uma compreensão do significado das configurações. Um bom modo de entender as configurações e sua importância é examinar exemplos. Nesta coluna apresentarei algumas dicas de configuração derivadas da configuração dos servidores que executam o microsoft.com para que você possa aprender a partir de nossa experiência.

1. Definir adequadamente a opção de compilação

Ao implantar aplicativos baseados em ASP.NET em um ambiente de produção, é crucial garantir que ninguém acidental ou deliberadamente deixe o atributo de depuração de compilação definido como verdadeiro em quaisquer arquivos de um aplicativo web.config, como a seguir:

<compilation debug="true" />

Em ambiente ocupados, com muitos aplicativos Web para serem gerenciados, é aconselhável usar os mecanismos de controle de configuração do ASP.NET para impedir que isso ocorra. (Logo fornecerei mais detalhes a respeito disso.)

Também é importante garantir que o atributo de depuração específico da página não esteja definido para verdadeiro em .aspx individuais como mostrado aqui:

<%@ Page debug="true" %>

Mais uma vez, em ambientes ocupados com grandes volumes de publicação, muitas vezes não é realista esperar que você consiga garantir que esta configuração seja removida de todas as páginas .aspx antes de elas serem publicadas. Você precisará de um meio global para impedir que isto ocorra.

Compilar seu aplicativo Web com essa configuração resultará em binários em depuração em vez de binários em varejo. Além disso, seu código não será otimizado, resultando em desempenho mais lento. E suas solicitações ASP.NET não esgotarão o tempo limite porque as configurações de depuração impedem tempos limites. Usar uma versão de depuração em um ambiente de produção é como abrir uma porta e convidar hackers!

Felizmente, o Microsoft® .NET Framework 2.0 tem uma nova configuração de implantação para o machine.config que diz ao ASP.NET para desabilitar o seguinte: recursos de depuração, saída de rastreamento e exibição de mensagens de erro do ASP.NET (tanto no host local quanto remotamente), independente das instruções em seu arquivo web.config ou dos atributos de página específicos. É semelhante ao seguinte:

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

Observe que esse dois últimos benefícios (desabilitar a saída de rastreamento e desabilitar as mensagens de erro detalhadas do ASP.NET remotamente) são as melhores práticas de segurança que você realmente deve adotar. Se não o fizer, estará expondo o funcionamento interno de seu aplicativo para que seja explorado por todo o mundo.

Por falar nisso, há aqui outro fato importante: o bloqueio do atributo de depuração <system.web><compilation> no arquivo raiz web.config dentro de <location allowOverride="false"> ou o uso do atributo lockItems impedirá que arquivos web.config inferiores na hierarquia de configuração do aplicativo ativem as configurações de depuração. Mas isso não irá impedir que páginas .aspx individuais ativem o modo de depuração em seus atributos de página. A opção comercial de implantação é a única maneira de desabilitar totalmente os recursos de depuração do ASP.NET em todos os níveis.

Configurar a opção comercial de implantação como verdadeira é, provavelmente, a melhor prática que qualquer empresa com servidores de produção formais deve seguir para garantir que um aplicativo sempre seja executado com o melhor desempenho possível e sem vazamentos de informações de segurança. Como eu disse, essa opção é nova em folha no ASP.NET 2.0. Ela foi o resultado direto do feedback recebido pela equipe do ASP.NET.

Por outro lado, para ambientes pré-produção de face interna em que os desenvolvedores precisam depurar seus aplicativos Web, não use a configuração comercial de implantação. Simplesmente defina <compilation debug="false"> no arquivo web.config da raiz de pré-produção e permita que esse valor seja substituído por arquivos web.config de aplicativos individuais ou por atributos de página .aspx.

2. Usar confiança média no ASP.NET 2.0

Se, como aconteceu com muitos sites em microsoft.com, você estiver usando um nível de confiança alto ou total mesmo depois de migrar seu site ou aplicativos para o ASP.NET 2.0, examine de novo o que é possível agora com a confiança média. Por exemplo, WebPermission restrita limita as comunicações de um aplicativo a um único endereço ou a um intervalo de endereços que você define no elemento <trust>. Isso permite que você controle e mantenha uma lista de sites e intervalo de endereços externos aprovados que podem ser chamados remotamente. Esse é um grande recurso de segurança.

FileIOPermission também é restrito. Isso significa que o código de um aplicativo só pode acessar arquivos em sua hierarquia de diretório virtual. Por padrão, com a confiança média, cada aplicativo tem permissões Read, Write, Append e PathDiscovery apenas para sua hierarquia de diretório virtual. Isso acaba com o acesso aleatório de E/S de arquivos - algo muito importante em um ambiente Web compartilhado em que muitos aplicativos estão hospedados.

Outra vantagem é que privilégios de código não gerenciados são removidos. Isso significa que você pode impedir o uso de componentes herdados, o modo mais fácil que já encontramos para desabilitar o uso do atributo de página Aspcompat. (Definir Aspcompat como verdadeiro pode fazer com que o desempenho de uma página piore.)

O nível de confiança médio do ASP.NET 2.0 é bastante flexível em termos da capacidade que oferece ao administrador para criar exceções personalizadas para cada uma das restrições padrão anteriores. Essa flexibilidade não existia no ASP.NET 1.1. Outro motivo pelo qual a execução em confiança média com ASP.NET 2.0 é mais fácil do que com o ASP.NET 1.1 é que você tem acesso aos bancos de dados do Microsoft SQL Server™.

Assim, se hospedar diversos aplicativos no mesmo servidor, você poderá usar a segurança de acesso ao código e o nível médio de confiança para fornecer isolamento de aplicativo. Ao definir e bloquear o nível de confiança (usando marcas <location allowOverride="false">) no arquivo web.config da raiz, é possível estabelecer diretivas de segurança para todos os aplicativos Web no servidor. Ao definir allowOverride="false", conforme é visto na Figura 1, um desenvolvedor individual será incapaz de substituir a configuração da diretiva de confiança média no arquivo web.config de seu aplicativo.

Figure 1 Configurações de confiança

<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>

Mais informações relativas ao uso do nível de confiança médio no ASP.NET 2.0 podem ser encontradas no seguinte artigo: "Como: usar confiança média no ASP.NET 2.0".

3. Restringir download de tipos de arquivo especificados

Existem tipos de arquivo em seu servidor que você, sem dúvida, não deseja que caiam em mãos erradas. Felizmente, por padrão, o ASP.NET está configurado para interceptar e impedir solicitações para diversos tipos de arquivos que são usados nos aplicativos do ASP.NET. Isso inclui arquivos .config e .cs que armazenam o código-fonte do aplicativo. O ASP.NET garante a privacidade desses arquivos ao associar os dois tipos de arquivos com System.Web.HttpForbiddenHandler. Esse manipulador, quando chamado, retorna um erro ao usuário que solicitou o arquivo. Na verdade, você pode usar esse método para restringir qualquer tipo de arquivo.

Por exemplo, no site microsoft.com, o tipo de arquivo .asmx não recebe permissão ao se acrescentar a seguinte entrada à seção <system.web><httpHandlers> do arquivo raiz web.config:

<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />

Como você pode ver, é possível usar subtags <add> no elemento <httpHandlers> para especificar tipos de arquivos adicionais que você deseja bloquear. Defina o atributo verb igual a "*". Ao fazer isso, você especifica que todos os tipos de solicitações HTTP estão bloqueados para aquele tipo de arquivo. Defina o atributo path como um caractere curinga que corresponda aos tipos de arquivos que você deseja bloquear. Por exemplo, você pode especificar "*.mdb". Por fim, defina o atributo type para "System.Web.HttpForbiddenHandler".

4. Ser cuidadoso ao acrescentar referências ao assembly

Cada servidor Web que executa o .NET Framework tem um cache de código amplo da máquina chamado de GAC (Global Assembly Cache). O GAC armazena assemblies especificamente planejados para serem compartilhados por diversos aplicativos no computador. Faz sentido acrescentar assemblies ao GAC se vários aplicativos diferentes precisarem referenciá-los, mesmo se a maioria dos sites no servidor Web não os acessarem. Isso não resulta em uma penalidade significativa de desempenho/recurso, mas traz o benefício de manter o controle da versão centralizado em vez de ter os assemblies compartilhados espalhados por todo o servidor em pastas de compartimento/aplicativos individuais.

Os critérios para quando uma referência ao assembly deve ser acrescentada ao web.config da raiz, contudo, precisam ser muito mais restritos do que os critérios que definem quando um assembly é colocado no GAC. Fazer com que os aplicativos individuais acrescentem referências ao assembly no arquivo web.config dos seus aplicativos para componentes que não sejam realmente globais proporcionam um desempenho muito melhor do que declarar essas referências ao assembly no arquivo web.config da raiz. Isso reduz significativamente o tempo para carregar a página de todos os aplicativos em um servidor Web que não usam esses assemblies como compilador e não precisam gastar tempo carregando assemblies desnecessários. O compilador ASP.NET não carregará um assembly para um aplicativo simplesmente porque o assembly reside no GAC; ele só o carregará se existir uma referência ao assembly em appdomain ou em um escopo de aplicativo mais elevado. Como resultado, no microsoft.com permitimos que os desenvolvedores de aplicativos substituam o elemento <configuration><system.web><compilation><assemblies> nos arquivos web.config de seus aplicativos para todos os ambientes da Microsoft.com.

Especificamente, nos arquivos web.config da raiz dos ambientes de produção e de preparação da microsoft.com, todos os atributos do nó <system.web><compilation> estão bloqueados (inclusive debug, explicit, defaultLanguage) bem como todos os seus elementos (buildProviders, expressionBuilders etc.), com exceção do elemento <assemblies>:

<compilation debug="false" 
    explicit="true" defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >

No ambiente de pré-produção de face interna, a seção <system.web><compilation> está bloqueada no arquivo web.config da raiz, mas permitimos que os editores de aplicativos substituam especificamente o elemento <assemblies> e também substituam debug="false" (para habilitar solução de problemas/depuração):

<compilation debug="false" explicit="true"
    defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAllAttributesExcept="debug" 
    lockAllElementsExcept="assemblies" >

Observe o uso de atributos lock, que são novos no ASP.NET 2.0. Mais uma vez, informações detalhadas sobre esses atributos e exemplos de seu uso podem ser encontradas em "Atributos gerais herdados por elementos de seção".

5. Remover manualmente valores MaxConnection definidos

Quase todos os sites Web microsoft.com têm aplicativos ASP.NET que fazem chamadas para serviços Web de clusters remotos. O número máximo de chamadas de serviços Web remotos simultâneos que podem ser feitos a partir de um único servidor Web é determinado pelo atributo maxConnection do elemento <connectionManagement> no arquivo machine.config. No ASP.NET 1.1, por padrão, o valor de maxConnection foi definido como 2. Esse valor antigo maxConnection padrão era baixo demais para sites como microsoft.com que têm centenas de aplicativos diferentes que fazem chamadas de serviços Web remotos. O resultado era que as solicitações ASP.NET se enfileiravam enquanto esperavam que as chamadas de serviços Web remotos fossem completadas. (Pode-se visualizar o número de solicitações ASP.NET na fila por meio do contador perfmon ASP.NET\Requests Queued.) Para possibilitar que mais chamadas fossem executadas simultaneamente para um serviço Web remoto (e, portanto, melhorar o desempenho dos aplicativos no site), aumentamos o valor maxConnection para 40 para nossos servidores Web de processador quad. (O valor geral recomendado para maxConnection é 12 vezes o número de CPUs, mas refine isso de acordo com sua situação específica.)

No ASP.NET 2.0, contudo, você não precisa mais configurar manualmente maxConnection, pois ele agora é dimensionado e definido automaticamente. Isso resulta da nova seção de configuração para a marca processModel no machine.config (para obter mais informações sobre o elemento processModel, consulte "Elemento processModel (esquema de configurações do ASP.NET))".

<system.web>
    <processModel autoConfig="true" />
</system.web>

Com o autoConfig habilitado no machine.config (essa é a configuração padrão), o ASP.NET determina o valor do parâmetro maxConnection para 12n (em que n é o número de CPUs). Habilitar o autoConfig também causa o seguinte: o parâmetro maxWorkerThreads e o parâmetro maxIoThreads são definidos como 100, o parâmetro minFreeThreads é definido como 88n, o parâmetro minLocalRequestFreeThreads é definido como 76n e o minWorkerThreads é definido como 50.

Antes de usar o autoConfig no ASP.NET 2.0 para dimensionar e definir valores automaticamente para o maxConnection e os outros atributos na lista, assegure-se de remover quaisquer valores definidos manualmente para esses parâmetros, pois tais valores seriam usados em vez dos valores do autoConfig. Isso é algo que se deve ter em mente ao migrar do ASP.NET 1.1 (em que o maxConnection precisava ser definido explicitamente) para o ASP.NET 2.0, em que existem padrões.

De novo, os valores autoConfig para o maxConnection e para os outros atributos listados anteriormente são um tanto arbitrários e podem não funcionar para todas as instâncias sem exceção, mas tenho visto que esses limites funcionam bem para quase todos os aplicativos microsoft.com.

Se você decidir que precisa refinar manualmente o valor maxConnection, seja prudente ao aumentar este valor, pois isso poderá provocar um aumento no uso da CPU. Esse aumento é causado pelo fato de mais solicitações de entrada poderem ser processadas pelo ASP.NET em vez de terem de esperar sua vez para chamar o serviço Web. É claro que você deve lembrar que o atributo maxConnection não afeta chamadas de serviços Web locais, apenas chamadas remotas.

6. Cuidado com exceções não tratadas

Ao exportar sites ou aplicativos Web do ASP.NET 1.1 Web para o ASP.NET 2.0, é extremamente útil estar ciente de uma importante alteração na diretiva padrão para exceções não tratadas. Nos .NET Framework 1.1 e 1.0, as exceções não tratadas em threads gerenciados eram ignoradas e, como os aplicativos continuavam a ser executados, essas exceções muitas vezes permaneciam ocultas. A menos que você associasse um depurador para capturar a exceção, poderia nem perceber que havia algo errado. Com o ASP.NET 2.0, porém, quando uma exceção não tratada é lançada, o aplicativo baseado em ASP.NET será fechado inesperadamente. Isso pode ter impactos importantes na disponibilidade de seu site ou aplicativo se houver muitas exceções não tratadas que anteriormente eram abordadas pela antiga diretiva padrão de exceções não tratadas.

O melhor modo de abordar isso é fazer um teste minucioso e eliminar as exceções não tratadas (que, na verdade, não deveriam estar presentes em seu aplicativo). Contudo, existem algumas opções para migrações de aplicativos muito grandes em que pode ser difícil determinar onde a exceção está acontecendo, ou caso você precise migrar muitos aplicativos herdados para os quais não seja viável realizar testes detalhados individuais. Ao migrar o site microsoft.com para o ASP.NET 2.0, alteramos a diretiva de exceções não tratadas de volta ao comportamento padrão que ocorre nos ASP.NET 1.1 e ASP.NET 1.0.

Para habilitar esse comportamento para tratamento de exceções herdado padrão, acrescente o código a seguir ao arquivo aspnet.config:

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy 
            enabled="true" />
    </runtime>
</configuration>

O código está localizado nessas duas pastas:

%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (em sistemas x86 ou SYSWOW64) e %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (em sistemas x64).

Essencialmente, essa alteração reverterá o .NET Framework ao comportamento antigo dos 1.1 e 1.0. Considere isso como um ajuste a curto prazo, porque, no final das contas, ele está mascarando problemas com seu aplicativo que, na verdade, são bugs. Todavia, esse é um modo muito útil de evitar problemas de disponibilidade devido ao fechamento inesperado de processos em funcionamento. Para obter mais informações sobre essa alteração de comportamento, consulte "Exceções não tratadas fazem com que aplicativos baseados em ASP.NET sejam inesperadamente fechados no .NET Framework 2.0".

7. Garantir configuração adequada no servidor proxy

Um administrador de um servidor Web pode especificar o servidor proxy a ser usado para solicitações HTTP para a Internet ao configurar o elemento <configuration><system.net><defaultProxy> no arquivo machine.config.

No ambiente de produção microsoft.com, configuramos o valor <defaultProxy> para usar o proxy padrão do sistema (pois o cliente de firewall não está instalado) e usamos marcas <location allowOverride="false"> para impedir que o elemento <defaultProxy> seja substituído por desenvolvedores de aplicativos (que poderiam editar acidentalmente um arquivo web.config com um servidor proxy interno):

<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>

Nos ambientes de pré-produção e preparação internos microsoft.com, definimos o atributo usesystemdefault como falso, o bypassonlocal como verdadeiro e acrescentamos um bypasslist do proxy (consulte a Figura 2). As listas bypasslist relacionam expressões comuns que descrevem endereços que não usam proxy especificado. Novamente, essa seção se encontra nas marcas <location allowOverride="false"> para impedir que os desenvolvedores especifiquem seu próprio servidor proxy em seus arquivos web.config. (Esses servidores proxy normalmente são internos e as chamadas para eles são interrompidas quando as páginas são editadas para produção.) Qualquer tentativa para especificar um servidor proxy na pré-produção ou preparação resultará em um erro de tempo de execução no ASP.NET, o que obrigará os desenvolvedores a removerem essa configuração antes de editar para produção.

Figure 2 Configuração de bypasslist

<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. Não exibir erros personalizados para todos

Como já mencionei, é importante não permitir que mensagens detalhadas de erros do ASP.NET sejam retornadas remotamente pelos servidores Web no ambiente de produção.

Nos arquivos web.config da raiz dos ambientes de produção e preparação microsoft.com, o atributo mode <configuration><system.web><customErrors> está definido para RemoteOnly, de modo que os erros personalizados sejam exibidos para os clientes remotos e os erros do ASP.NET sejam exibidos para o host local (para permitir solução de problemas pelos administradores do servidor Web). Observe que o elemento <customErrors> se encontra em uma marca <location> com allowOverride="false" (consulte a Figura 3). Isso é feito para impedir que proprietários de aplicativos individuais acidental ou deliberadamente definam mode="Off" e vazem mensagens detalhadas de erros do ASP.NET para a Internet.

Figure 3 Como impedir a exibição de mensagens de erros

&lt;configuration&gt;
    &lt;location allowOverride='false'&gt;
        &lt;system.web&gt;
            &lt;customErrors mode='RemoteOnly' defaultRedirect=
                   '/errorpages/generic_customerror.aspx'&gt;
                &lt;error statusCode='404' redirect='/errorpages/filenotfound_customerror.aspx' /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;

Lembrem-se também, como já mencionei, de que o uso da opção <deployment retail="true"/> no arquivo machine.config desliga a capacidade de exibir mensagens detalhadas de erros do ASP.NET tanto para os clientes remotos quanto localmente. Essa opção comercial de implantação deve ainda ser seu método principal para desligar essas mensagens de erro se você estiver executando o ASP.NET 2.0. (Para obter informações detalhadas relativas às exceções do ASP.NET, use o log de eventos do aplicativo.)

No arquivo web.config da raiz do ambiente de pré-produção de face interna do microsoft.com, o atributo mode <customErrors> é definido como desligado, de modo que os erros do ASP.NET sejam sempre exibidos tanto para o host local quanto para os clientes remotos. Isso é feito para habilitar depuração e solução de problemas. Além disso, nenhuma página de erro personalizada está configurada:

<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. Saiba quando habilitar rastreamento

Os rastreamentos do ASP.NET são gerados durante a execução de uma página do ASP.NET e capturam detalhes interessantes sobre a solicitação da Web, a árvore de controle de página e a execução de diversos estágios do ciclo de vida e dos controles da página. Além disso, podem ser exibidas mensagens personalizadas que foram escritas no rastreamento pelo desenvolvedor da página. O rastreamento pode ser anexado à saída de resposta da página que está sendo rastreada ou examinada como parte da lista de solicitações rastreadas no visualizador de rastreamento do aplicativo. Esse recurso foi criado primariamente para cenários de depuração de tempo de desenvolvimento em ambientes internos de pré-produção e não deve ser usado para implantações da produção.

Nos arquivos web.config da raiz dos ambientes de produção e preparação do microsoft.com, o atributo enabled <configuration><system.web><trace> é definido como "false", de modo que a capacidade de saída de rastreamento de informações em uma página Web seja desabilitada. Observe que o elemento <trace> se encontra em uma marca <location> com allowOverride="false". Isso é feito para impedir que proprietários de aplicativos individuais acidental ou deliberadamente definam enabled="true" e enviem informações detalhadas de rastreamento do ASP.NET para a Internet:

<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>

Como mencionei anteriormente, o uso da opção <deployment retail="true"/> no arquivo machine.config também desliga a capacidade de enviar a saída de rastreamento do ASP.NET para uma página Web. Essa opção deve ser seu método básico para desligar a saída de rastreamento se estiver executando o .NET Framework 2.0.

Para ter certeza de que o rastreamento não pode ser habilitado acidentalmente em ambientes de produção de face externa, no microsoft.com removemos o manipulador real trace.axd do arquivo web.config da raiz ou o comentamos, da seguinte forma:

<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. Desabilitar Session State Web Farms

Como todos os sites no microsoft.com estão atualmente agrupados e usam o NLB (Network Load Balancing) sem afinidade (para permitir a distribuição igualitária de solicitações em todos os servidores do cluster), não há garantia de que o mesmo servidor manipulará todas as solicitações para um determinado aplicativo. Como resultado, o módulo ASP.NET Session State está desabilitado para impedir o uso da propriedade Session pelos desenvolvedores de aplicativo. A diretriz que oferecemos aos desenvolvedores de aplicativos que precisam manter estado é usar View State (que mantém o estado em uma estrutura dentro do código de página e, como resultado, não usa recursos do servidor).

Para desabilitar Session State em um servidor Web, você deve simplesmente remover o seguinte nó filho do nó <httpModules>:

<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>

Estou supondo que você já viu e até já usou os arquivos de configuração do ASP.NET (machine.config, web.config da raiz e arquivos web.config de aplicativos individuais), caso contrário, o seguinte Tutorial ASP.NET Quickstart irá ajudá-lo: asp.net/QuickStart/aspnet/doc/management/fileformat.aspx.

O artigo menciona que o sistema de configuração do ASP.NET 2.0 agora também inclui diversos recursos muito úteis que permitem que os administradores bloqueiem elementos e atributos individuais de configuração, usando os atributos lockItems e lockCollections. Esses atributos e seu uso estão documentados no artigo "Atributos gerais herdados por elementos de seção".

Jeff Toews é gerente de engenharia de sistemas, integrante da equipe de operações do Microsoft.com, localizada em Redmond, WA, há seis anos. Você pode contatá-lo se tiver quaisquer perguntas técnicas ou comentários em mscomblg@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..