Se você codificar locais ASP.NET para que eles possam viver em um VDIR?

votos
0

Voltar nos dias antes Visual Studio Web Server nós hospedar o nosso local dev dentro do IIS. Se você tiver uma versão estação de trabalho do IIS que significa apenas 1 website. E se você está trabalhando em vários sites. Fácil: criá-los em VDIRs, por exemplo, http: // localhost / ProjectA , http: // localhost / ProjectB .

Vivendo em um VDIR não soa tão difícil. Certifique-se de todas as suas imagens / CSS / links são caminhos relativos, use o ~ muito. Soa como uma boa prática. Hardcoding imagens etc para que eles só funcionam quando o aplicativo é servido a partir das / soa como uma má prática.

Há algumas nuances em qualquer lugar você tem que construir um link (cenários em sua maioria não são comuns):

Então .. Você está fazendo isso? Vantagens desvantagens? Quaisquer outras dicas que eu perdi?

Publicado 26/08/2009 em 23:51
fonte usuário
Em outras línguas...                            


2 respostas

votos
1

Em suma, sim . As desvantagens de não fazê-lo superam os benefícios. Eu realmente acho que os seus dois primeiros pontos também podem ser mitigados principalmente de usar caminhos de aplicativo-relativo ( "~"), mas, no entanto, alguns cenários, tais como os "nível de integração" (como o PayPal) pode de fato ser complicado.

Mas no final do dia, se você precisa para hospedar seu aplicativo em um diretório virtual que você está praticamente garantido problemas se você não tiver codificado seu aplicativo para ser vdir-friendly de o ir buscar. Eu sei que tenho.

Alguns fundo / contexto: Meu atual produção ambiente no trabalho é quase sempre um diretório virtual de qualquer maneira, então eu fazer isso por necessidade. E eu nunca tive um problema quando um aplicativo foi criado como um site no nível raiz. Isto certamente não seria o caso se fosse o contrário.

Respondeu 27/08/2009 em 00:11
fonte usuário

votos
1

Eu sempre evitar caminhos codificado, URLs, etc a menos que haja uma razão específica para fazer o contrário. Coisas inevitavelmente mudar, e há sempre o salto de seu site dev à produção.

A parte que é geralmente o maior incômodo seria em comportamentos cliente reutilizáveis ​​que precisam fazer referência a outros caminhos, e eles mesmos podem ser reutilizados em páginas na estrutura de diretório do aplicativo.

Eu gosto do manipulador ideia de que responde a "globalvars.ashx" (ou algo assim, há muitas maneiras de lidar com isso) que emite dinamicamente (e permite caching) propriedades sobre as propriedades do aplicativo globais.

Diga o manipulador responsável por globalvars.ashx escreve o resultado de algo como isto:

String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);

Seus comportamentos JS teoricamente poderia referenciar esse objeto imóvel em qualquer ponto via ApplicationProperties.RootPath.

Respondeu 27/08/2009 em 00:03
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more