Por que os formulários da Web do ASP.NET precisam do atributo Runat = "Server"?

Por que preciso especificar runat="server"em todos os meus controles do ASP.NET quando é um atributo obrigatório e serveré a única opção disponível no meu conhecimento limitado do ASP.NET e recebo um erro se não o uso?

Entendo que, opcionalmente, posso usá-lo em minhas tags HTML e entendo o paradigma cliente / servidor e o que ele realmente está especificando.

É uma marca redundante que poderia ser implícita pelo controle sendo um controle ASP.NET ou há um motivo subjacente?

Eu sempre acreditei que havia mais para entender que você pode misturar tags ASP.NET e HTML, e as tags HTML têm a opção de serem runat="server" ou não. Não custa nada deixar a tag e causa um erro do compilador. Quanto mais coisas você sugere sobre a linguagem da Web, menos fácil é para um programador iniciante entrar e aprender. Essa é uma razão tão boa quanto qualquer outra para ser detalhado sobre os atributos das tags.

Essa conversa foi realizada no Blog de Mike Schinkel entre ele e Talbot Crowell, da Microsoft National Services. As informações relevantes estão abaixo (primeiro parágrafo parafraseado devido a erros gramaticais na fonte):

[...] mas a importância de <runat="server">é mais para consistência e extensibilidade.

Se o desenvolvedor precisar marcar algumas tags (viz. <asp: />) Para o ASP.NET Engine ignorar, também há o possível problema de colisões de namespace entre tags e aprimoramentos futuros. Ao exigir o <runat="server">atributo, isso é negado.

Continua:

Se <runat=client>fosse necessário para todas as tags do lado do cliente, o analisador precisaria analisar todas as tags e remover a <runat=client>peça.

Ele continua:

Atualmente, se meu palpite estiver correto, o analisador simplesmente ignora todo o texto (tags ou sem tags), a menos que seja uma tag com o runat=serveratributo ou um <%prefixo “ ” ou ssi “ <!– #include… (...) Além disso, como o ASP.NET foi projetado para permitir a separação dos designers da Web (foo.aspx) dos desenvolvedores da Web (foo.aspx.vb), os designers da Web podem usar suas próprias ferramentas de designer da Web para colocar HTML e JavaScript do lado do cliente sem precisar conhecer o ASP.NET tags ou atributos específicos.

Normalmente, eu não gosto de adivinhar, mas eu vou nessa ...

Se você se lembra do hype de marketing do .NET da Microsoft naquela época (2001?), Era difícil dizer o que o .NET era. Foi um servidor? uma plataforma de programação? uma linguagem? algo totalmente novo? Dados os anúncios, era ambíguo o que você queria que fosse - apenas resolvia qualquer problema que você pudesse ter.

Portanto, meu palpite é que havia uma grande visão oculta de que o código ASP.NET poderia ser executado em qualquer lugar - do lado do servidor OU do cliente, em uma cópia do Internet Explorer vinculada ao tempo de execução do .NET. runat = "server" é apenas um remanescente vestigial, deixado para trás porque seu equivalente no lado do cliente nunca chegou à produção.

Lembra daqueles anúncios estranhos?

Relacionado: Artigo do The Register com alguma história do .NET.

Nem todos os controles que podem ser incluídos em uma página devem ser executados no servidor. Por exemplo:

<INPUT type="submit" runat=server />

É essencialmente o mesmo que:

<asp:Button runat=server />

Remova a tag runat = server da primeira e você tem um botão HTML padrão que é executado no navegador. Há razões a favor e contra a execução de um controle específico no servidor e não há como o ASP.NET "assumir" o que deseja com base na marcação HTML incluída. Pode ser possível "inferir" o servidor runat = para a <asp:XXX />família de controles, mas meu palpite é que a Microsoft consideraria isso um hack para a sintaxe da marcação e para o mecanismo ASP.NET.

Artigo Microsoft Msdn The Forgotten Controls: HTML Server Controls explica o uso de runat = "server" com um exemplo na caixa de texto <input type="text">, convertendo-o em<input type="text" id="Textbox1" runat="server">

Isso fornecerá acesso programático ao elemento HTML no servidor antes que a página da Web seja criada e enviada ao cliente. O elemento HTML deve conter um atributo de identificação. Este atributo serve como uma identidade para o elemento e permite que você programe para elementos por seus IDs específicos. Além deste atributo, o elemento HTML deve conter runat = "server". Isso informa ao servidor de processamento que a tag é processada no servidor e não deve ser considerada um elemento HTML tradicional.

Em resumo, para habilitar o acesso programático ao elemento HTML, adicione runat="server"-o.

Minha suspeita é que isso tenha a ver com a maneira como os controles do lado do servidor são identificados durante o processamento. Em vez de ter que verificar todos os controles no tempo de execução pelo nome para determinar se o processamento no servidor precisa ser feito, ele faz uma seleção na representação do nó interno por marca. O compilador verifica se todos os controles que exigem tags de servidor os possuem durante a etapa de validação.

Os elementos HTML nos arquivos ASP.NET são, por padrão, tratados como texto. Para tornar esses elementos programáveis, adicione um runat="server"atributo ao elemento HTML. Este atributo indica que o elemento deve ser tratado como um controle de servidor.

Está lá porque todos os controles no ASP .NET herdam do System.Web.UI.Control que possui o atributo "runat".

na classe System.Web.UI.HTMLControl, o atributo não é necessário; no entanto, na classe System.Web.UI.WebControl, o atributo é necessário.

edit: deixe-me ser mais específico. como o asp.net é praticamente um resumo do HTML, o compilador precisa de algum tipo de diretiva para saber que uma tag específica precisa ser executada no lado do servidor. se esse atributo não estivesse lá, não saberia processá-lo no servidor primeiro. se não estiver lá, assume que é uma marcação regular e a passa para o cliente.

Eu acho que a Microsoft pode corrigir essa ambiguidade fazendo com que o compilador adicione o atributo runat antes que a página seja compilada, algo como o apagamento de tipo que o java tem com os genéricos, em vez de apagar, ele pode estar escrevendo runat = server onde quer que veja asp: prefixo para tags, para que o desenvolvedor não precise se preocupar com isso.

Se você usá-lo em tags html normais, significa que você pode manipulá-las programaticamente em manipuladores de eventos, etc., por exemplo, alterar o href ou a classe de uma tag âncora no carregamento da página ... faça isso apenas se for necessário, porque as tags html vanilla vá mais rápido.

Quanto aos controles de usuário e de servidor, não, eles simplesmente não funcionam sem eles, sem ter mergulhado nas entranhas do pré-processador aspx, não sabiam dizer exatamente o porquê, mas supuseram que, provavelmente por boas razões, acabaram de escrever o analisador dessa maneira, procurando coisas explicitamente marcadas como "faça alguma coisa".

Se o @JonSkeet estiver em qualquer lugar, ele provavelmente será capaz de fornecer uma resposta muito melhor.

Ao enviar os dados para o servidor Web do ASP.NET, os controles mencionados como Runat = "servidor" serão representados como objetos Dot Net no Aplicativo de Servidor. Você pode digitar manualmente o código nos controles HTML ou usar a opção Executar como servidor clicando com o botão direito do mouse no modo de design. Os controles do ASP.NET obterão esse atributo automaticamente quando você o arrastar da caixa de ferramentas, onde normalmente os controles HTML não.

Atributo bastante redundante, considerando a tag "asp" é obviamente um elemento ASP e deve ser suficiente para identificá-lo como um elemento acessível no servidor.

Em outros lugares, no entanto, costumava elevar as tags normais a serem usadas no code-behind.

Acabei de chegar a essa conclusão por tentativa e erro: runat = "server" é necessário para acessar os elementos em tempo de execução no servidor. Remova-os, recompile e observe o que acontece.

runat="Server" indica que uma postagem no servidor ocorrerá para o "controle" do HTML.

Os Formulários da Web são usados postbackconstantemente para sinalizar ao servidor para processar um evento de controle de página.

.NET MVCpáginas NÃO use postback(exceto um formulário "submit"). MVCconta JQUERYcom o gerenciamento da página no lado do cliente (ignorando a necessidade de muitas postbackmensagens para o servidor).

Então: .NETFormulários da Web ... usam "runat"muito o atributo na marcação da página.

.NET MVCquase nunca usa o "runat"atributo na marcação da página.

Espero que isso ajude a esclarecer por que runaté necessário ...