Somente pelo IIS é possível converter uma pasta em aplicação? Mais ou menos. Na versão 7 do IIS já dispõe de módulos que simplificam o processo de criação de site, diretório virtual, pools de aplicação e as aplicações em si. Nesse artigo mostrarei bem rápido como converter uma pasta em uma aplicação.
Crie sua aplicação e adicione, como referência, o binário Microsoft.Web.Administration.dll que fica na pasta C:\Windows\System32\inetsrv . Agora adicione o seguinte código:
using Microsoft.Web.Administration;
private void CriaEntradaIIS(string diretorio)
{
try
{
// Cria a pasta do site
if (!Directory.Exists(diretorio))
Directory.CreateDirectory(diretorio);
// Servidor de Aplicação
ServerManager sm = new ServerManager();
// Captura o site raiz onde irá adicionar a aplicação
Site st = sm.Sites["Default Web Site"];
// Cria a aplicação no diretório criado apontando o caminho, ex: aplicacao
Application app = st.Applications.Add("/aplicacao", diretorio);
app.ApplicationPoolName = "ASP.NET v4.0";
sm.CommitChanges();
// Libera
sm.Dispose();
}
catch (Exception erro)
{
return;
}
}
Se tentar executar dará erro... Antes dê permissão total ao grupo Serviço de Rede (Network Service) à pasta C:\Windows\System32\inetsrv\config . Agora sim irá criar. Para mais exemplos veja nesse post aqui.
Mostrando postagens com marcador iis. Mostrar todas as postagens
Mostrando postagens com marcador iis. Mostrar todas as postagens
Convertendo uma pasta em aplicação no IIS via código (C#)
Postado por
Thiago Marçal
on segunda-feira, 28 de novembro de 2011
/
Marcadores:
application,
diretório virtual,
dll,
iis,
site,
windows
/
Comments: (3)
Recuperando a senha da conta identidade do Pool de Aplicativos do Plesk no IIS
Mais um título longo... um tanto confuso, mas em resposta a uma dúvida de um amigo:
Então façamos as seguintes etapas:
"Exclui um Application Pool no IIS e nela estava configurada uma conta interna do Plesk: IWAM_plesk. Não sei a senha utilizada. Tem como recuperar a senha para recriar um novo application?"Sim! O Plesk sempre nos pregando aquela peça... Os dois pools que o Plesk utiliza estão vinculados à conta IWAM_plesk (conta interna) para que possam manipular corretamente os arquivos e seus aplicativos (bem como as permissões necessárias) no sistema operacional:
- plesk(default)(2.0)(pool)
- plesk(default)(4.0)(pool)
Então façamos as seguintes etapas:
- Abra o Prompt de Comando em Modo Administrador;
- Navegue para a pasta C:\Windows\system32\inetsrv;
- Execute o comando appcmd.exe list apppool “plesk(default)(2.0)(pool)” /text:*
Aparecerá a descrição completa desse pool. Procure a entrada referente ao usuário e senha do Plesk conforme a figura abaixo:
Agora você tem a senha do usuário! No site de Dhiraj tem mais detalhes acerca desse tipo de recuperação.
Testando um Web-Site na própria máquina como se fosse externamente
Tentei elaborar um título de forma que ficasse entendível o que eu queria dizer. Não sei se ajuda, mas significa que:
Pronto! Já temos nosso site, mas se formos testar: http://thiagomarcal.com.br/ não encontra!
Por que isso? Quando queremos procurar um site, o sistema operacional analisa o hostname para saber onde encontrar esse endereço: se for interno e mapeado usa-se a rede interna, senão procura a rede externa dentre outros. Como não existe o mapeamento e tampouco o domínio externo, não acha nada. Então vamos alterar o arquivo de host.
Siga para o caminho: C:\Windows\System32\drivers\etc e abra o arquivo hosts, em modo texto, para adicionarmos algumas entradas.
Coloque, na última linha, o IP, tabulação e nome do domínio nessa ordem para o site desejado. Salve e teste novamente o acesso. E pronto!
Mais fácil do que isso: impossível!
"Testaremos o acesso a um web-site que está publicado no IIS mas que no navegador não iremos usar localhost para buscá-lo e sim o próprio endereço."Ficou bom agora? Então vamos lá. No IIS crie um web-site. O processo é bem simples:
Pronto! Já temos nosso site, mas se formos testar: http://thiagomarcal.com.br/ não encontra!
Por que isso? Quando queremos procurar um site, o sistema operacional analisa o hostname para saber onde encontrar esse endereço: se for interno e mapeado usa-se a rede interna, senão procura a rede externa dentre outros. Como não existe o mapeamento e tampouco o domínio externo, não acha nada. Então vamos alterar o arquivo de host.
Siga para o caminho: C:\Windows\System32\drivers\etc e abra o arquivo hosts, em modo texto, para adicionarmos algumas entradas.
# copyright (c) 1993-2009 microsoft corp. # # this is a sample hosts file used by microsoft tcp/ip for windows. # # this file contains the mappings of ip addresses to host names. each # entry should be kept on an individual line. the ip address should # be placed in the first column followed by the corresponding host name. # the ip address and the host name should be separated by at least one # space. # # additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # for example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within dns itself. # 127.0.0.1 localhost # ::1 localhost 127.0.0.1 thiagomarcal.com.br
Coloque, na última linha, o IP, tabulação e nome do domínio nessa ordem para o site desejado. Salve e teste novamente o acesso. E pronto!
Mais fácil do que isso: impossível!
Error 500 Internal Server Error - Como descobrir o problema
Quando dá esse erro muitas pessoas tremem só de ver! Abaixo darei uma dica para quem é marinheiro de primeira viagem e se depara com isso.
Essa tela é gerada pelo IIS para camuflar o erro para o usuário. Se a aplicação não for bem tratada quanto a erros, esse é o último recurso que o IIS faz para não exibir o erro na tela. Seria bem incômodo para o usuário ver na tela o erro de seu site, por exemplo. Para quem está gerenciando a aplicação é incômodo até certa parte, pois muitas vezes o desenvolvedor resolve o problema mais olhando o erro do que analisando log, events, etc. Pois bem, vamos lá!
Abra o IIS e procure pela função Error Pages (Páginas de Erro) no módulo IIS. Entre e procure pelo link Edit Resource Settings (Editar Configurações de Recurso). Ao abrir, a tela de Edit Error Pages Settings (Editar Configurações de Página de Erro) escolha a opção Detailed errors (Erros detalhados) e OK.
Ou, mais especificamente para o ASP.NET, procure a função .NET Error Pages (Páginas de Erro do .NET) no módulo ASP.NET. Entre e procure pelo link Edit Resource Settings (Editar Configurações de Recurso). Ao abrir, a tela de Edit Error Pages Settings (Editar Configurações de Página de Erro) escolha a opção Desactive (Desativar) e OK.
Com isso, a depender do erro, já estarão sendo enviados para a tela. Lembram do post sobre segurança? No web.config, deixe o customErrors com o atributo mode="Off" caso necessário para que os erros sejam exibidos.
Caso ainda não tenha descoberto o problema, acesse a configuração do ASP no módulo IIS. Expanda a propriedade Debugging Properties (Propriedades de Depuração) e coloque como True a função Send Errors to Browser (Enviar Erros ao Navegador).
Isso deve ser mais do que o suficiente para exibir o erro e identificar qual o problema está na aplicação. Lembrando que, se preferível, não deixar o erro ser exibido para o cliente. Deve-se fazer o possível para tratar e localizar adequadamente o problema. Segurança em primeiro lugar!
Essa tela é gerada pelo IIS para camuflar o erro para o usuário. Se a aplicação não for bem tratada quanto a erros, esse é o último recurso que o IIS faz para não exibir o erro na tela. Seria bem incômodo para o usuário ver na tela o erro de seu site, por exemplo. Para quem está gerenciando a aplicação é incômodo até certa parte, pois muitas vezes o desenvolvedor resolve o problema mais olhando o erro do que analisando log, events, etc. Pois bem, vamos lá!
Abra o IIS e procure pela função Error Pages (Páginas de Erro) no módulo IIS. Entre e procure pelo link Edit Resource Settings (Editar Configurações de Recurso). Ao abrir, a tela de Edit Error Pages Settings (Editar Configurações de Página de Erro) escolha a opção Detailed errors (Erros detalhados) e OK.
Ou, mais especificamente para o ASP.NET, procure a função .NET Error Pages (Páginas de Erro do .NET) no módulo ASP.NET. Entre e procure pelo link Edit Resource Settings (Editar Configurações de Recurso). Ao abrir, a tela de Edit Error Pages Settings (Editar Configurações de Página de Erro) escolha a opção Desactive (Desativar) e OK.
Com isso, a depender do erro, já estarão sendo enviados para a tela. Lembram do post sobre segurança? No web.config, deixe o customErrors com o atributo mode="Off" caso necessário para que os erros sejam exibidos.
Caso ainda não tenha descoberto o problema, acesse a configuração do ASP no módulo IIS. Expanda a propriedade Debugging Properties (Propriedades de Depuração) e coloque como True a função Send Errors to Browser (Enviar Erros ao Navegador).
Isso deve ser mais do que o suficiente para exibir o erro e identificar qual o problema está na aplicação. Lembrando que, se preferível, não deixar o erro ser exibido para o cliente. Deve-se fazer o possível para tratar e localizar adequadamente o problema. Segurança em primeiro lugar!
Mega Post de Erros
Postado por
Thiago Marçal
on sábado, 9 de abril de 2011
/
Marcadores:
banco de dados,
cloud server,
crystal reports,
dll,
erros,
iis,
locaweb,
plesk,
sql server,
windows
/
Comments: (0)
Lidar com erros é algo realmente muito chato... Chato demais! Esses dias fui convocado para fazer um certo trabalho de migração entre servidores. Um desses servidores era um Cloud Server Pro da Locaweb. Em muitos posts que aqui escrevi tem um pouco retratando sobre a Locaweb. Trabalho e já trabalhei muito com ela e sei de todos os seus passos e "artimanhas" de atendimento... O antigo Cloud Server foi até tranquilo de trabalhar, mas esse novo... Vamos aos problemas!
Uma dica que dou sempre quando alguém quer contratar um servidor: leiam muito sobre os prós e contras. Os prós vejam no próprio site do prestador, os contras vejam nos relatos de usuários. No post a seguir não estou jogando a Locaweb contra a parede, apenas estou expondo erros que podem ser sanados de forma fácil mas que burocraticamente é jogado para o cliente se virar (nos 30!).
Nesse Cloud Server vem embutido o Plesk. Em poucas palavras serve para gerenciar a hospedagem através de uma interface web. É uma boa ferramenta de gerência, tem tudo para gerenciar sua hospedagem. Só que esse demais gera ocupação demais (redundância) de espaço em disco. Dos 50 Gb que você contrata, 40Gb é para o sistema operacional e 10Gb para seus arquivos. Sendo que dos 10Gb é para todos os seus arquivos, e-mails, banco de dados, etc. Ou seja, apenas usufrui dos 10Gb um pouco menos que 9Gb e olhe lá.
Bem, dizem que vem tudo preparado e instalado para usar... Verdade até certa parte! Quem está usando e é iniciante vai ver que é mil maravilhas. Dá para fazer o básico de tudo. O problema vem a seguir...
Um cliente contratou o Cloud Server gerenciado pelo cliente (ou seja, sobrou para o usuário final) e me passou para configurar e deixar no ponto de uso fazendo toda a migração e instalação. Em um passe de mágica surgem os problemas...
Os bancos de dados que vem são o MS SQL Server 2008 e o MySQL. Não há interface para dump e recovery das bases forçando a usar o Plesk para isso, mas não queria. Onde está o Management Studio 2008? Onde está o MySQL Workbench? Como vou fazer para migrar as bases? Gerar script de bancos gigantes? Nem pensar! Preciso instalar!
Mas como instalar esses aplicativos? Se fazer download, gera tráfego. Se pedir para a Locaweb tem que pagar e se pedir, de graça, não instala! Lembrando que esses aplicativos, no mínimo, são gratuitos e deveriam estar em uma zona em que os usuários pudessem obtê-los de forma fácil e sem cobrança. Pois bem, feito o download, hora de instalar. Abrindo o executável (lembrando que tem que ser a da versão 64bits) dá aviso de incompatibilidade. É preciso instalar o Service Pack 1 do SQL Server 2008 (mais tráfego). Baixado o SP1 é preciso instalá-lo. Tranquilo e instalado sem problemas. Hora de instalar o Management Studio...
Ao tentar abrir, outro problema?!?! É preciso do Framework 3.5! Incrivel... No Cloud Server vem instalado a versão 2.0 e 4.0 do Framework ASP.NET mas não tem a 3.5 ativado. Menos mal, porque no Windows Server 2008 é nativo, basta ativar. Realize os seguintes passos (retirado do Wiki):
Agora sim, tudo pronto! Vamos instalar o Management Studio. Clica no instalador e... Erro! Caramba... de novo!
TITLE: SQL Server Setup failure.
-------------------------------
SQL Server Setup has encountered the following error:
Invoke or BeginInvoke cannot be called on a control until the window handle has been created.
A dica é: feche o Windows Explorer! Por algum motivo, a instalação do Management Studio não inicia quando o Windows Explorer estiver em aberto. Copie para a Área de Trabalho e abra o instalador... Agora sim! Depois de tanta malemolência pelo menos iniciemos a instalação. Para quem tem dúvidas e um passo-a-passo bem explicativo de como instalar o Management Studio, acesse aqui o post de Marcos dell Antonio. Há uma dica bem interessante que pode confundir o usuário na hora da instalação. Terminado a instalação, menos um item da lista de afazeres.
Consegui conectar ao SQL Server local, criei as bases, usuários, fiz restores, configurei o backup, providenciei tudo o que tinha que fazer onde o Plesk jamais pensaria em um dia ser. Agora o principal, testar um website. Publiquei o site no IIS e abri o navegador para visualizar. Erro!
Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Sabe o porquê disso? Eu instalei o ASP.NET 3.5 depois que eu já tinha a versão 4.0 instalada por causa do Management Studio então gerou conflito nas DLL's. Para resolver, faça o seguinte:
Agora vamos testar! Abri o navegador e digitei o endereço e... Mais erro!
There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined
Mais conflitos! Se você tiver outra versão do System.Web.Extensions instalado, devido ao ASP.NET AJAX por exemplo, a versão que está no GAC do sistema difere da que você quer chamar ocorrendo ambiguidade. O correto seria alterar os assemblys mas como isso é muito trabalhoso e pode acontecer algum imprevisto para aqueles que não sabem manuseá-las, então aconselho o seguinte: remova toda a sectionGroup do seu web.config ou comente-as:
<!--
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere" />
<section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
<section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
-->
No caso comentei o sectionGroup do System.Web.Extension que pode estar na versão 1.0, 2.0 ou 3.5 que for.
Agora vamos lá! De pés juntos e mãos dadas: Abre o navegador e... e... e... Funcionou! Depois de um árduo trabalho aparentemente tudo estava normal. Vamos testar outros sites e... e... e... Mais erros!
Quem ainda não está acostumado a trabalhar com Windows Server 2008 e IIS 7 terá que aprender muito sobre permissões e tratamento de erros. Incontestavelmente a tela do erro 500 irá aparecer e muito se sua aplicação não estiver configurada adequadamente para o IIS 7. Nem sempre a mesma aplicação que está no IIS 6 irá funcionar no IIS 7. Então eis que surge a tela do Erro 500 Erro Interno do Servidor ou Error 500 Internal Server Error:
Ou então:
Dá para descobrir o que é? Vou dar a dica: revise seu web.config. "Ah, mas está tudo certo, não sei porque não funciona...". Engano, está errado. Já disse que o IIS 7 é chato, muito chato. O parser dele é muito minucioso e se não estiver nos padrões vai dar problema.
Se você não sabe utilizar bem o IIS e tem medo de alterar uma coisinha ali e outra acolá vou dar a maior dica: saia abrindo cada opção do painel da aplicação até que uma delas acuse um erro de configuração.
Por exemplo, abra o item Documento Padrão. Se ele estiver configurado corretamente então abrirá a próxima tela normalmente. Se tiver algum erro, aparecerá um alerta. Então no web.config você deve corrigir a sessão correspondente. Ficou claro? Saia clicando um a um até que um deles se denuncie podendo então fazer a correção.
O que ocorreu comigo foi que um site que estava no IIS 6 podia colocar a mesma página (index.aspx) como padrão, duas vezes, e não tinha problema. Quando foi para o IIS 7, na qual estava herdando a configuração pai, e foi adicionar a página index.aspx como padrão novamente, ele dava erro e não sabia porquê. Então removi a entrada do web.config e funcionou. Desabilitar a mensagem de erro amigável no navegador vai funcionar (encontrar o erro)? Não. Desabilitar as páginas de erros personalizáveis do IIS vai funcionar (encontrar o erro)? Talvez ou não. Depende muito do ambiente que está configurado e quem está manipulando.
Pronto! Mais um problema solucionado... Vamos testar outro site e... e... e... Erro! Agora aconteceu um erro 404. Mas como? Erro 404 de página não encontrada mas se o caminho está lá? Incrivelmente no IIS do Cloud Server possuem dois Applications Pools do Plesk (e mais outros nativos): Plesk(default)(2.0) e Plesk(default)(4.0). O pool do 2.0 quase nem sempre funciona. E um comportamento anormal é que se você tem um site pai em 2.0 e um filho em 2.0 às vezes pára de funcionar. O "correto" é ter um pai 2.0 ou 4.0 com filho sempre 4.0. Estranho? Pode crer! E onde está o pool do 3.5? Tem que criar na mão mesmo.
Nota: Se você reiniciar o IIS o Plesk pára de vez e não volta:
Você terá que iniciá-lo manualmente. Mas antes terá que iniciar seu pool também (que é muito suspeito):
Ajeitado uma coisinha ali, outra aqui, vamos testar mais algumas coisas e... e... e... Quase tudo certo. Em questão de funcionalidade (que deveria ser) está quase tudo certo a não ser o funcionamento do bom e velho Crystal Reports. Quem já leu o post de erros do Crystal aqui e aqui nos deparamos com o erro:
O inicializador de tipo de 'CrystalDecisions.CrystalReports.Engine.ReportDocument' acionou uma exceção
ou
The type initializer for 'CrystalDecisions.CrystalReports.Engine.ReportDocument' threw an exception
Cuidado! Esse não é o descritivo do erro. Só com isso não dá para saber o motivo. Faça o debug, log, exibição da pilha ou na própria tela exiba o erro (sem ter AJAX) que teremos o erro completo. No link dos dois posts anteriores que fiz explica o problema do Crystal na plataforma 64bits e como pode resolver. Só que o problema no meu caso era permissão.
Server Error in '/virtual_directory_name' Application.
Error in File UNKNOWN.RPT:
The request could not be submitted for background processing.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Runtime.InteropServices.COMException: Error in File UNKNOWN.RPT: The request could not be submitted for background processing.
Os usuários listados abaixo, não tinham permissão na execução de scripts DCOM e gravação em algumas pastas (principalmente as que estão na unidade C):
Esses são os usuários que devem ter privilégio (descritos abaixo) nas pastas listadas abaixo:
Obs: Para alguns servidores é preciso aplicar o Replace permission entries on all child objects nessas pastas.
Lembrando de reiniciar o IIS e/ou o servidor para recarregar as configurações.
Se estiver trabalhando com Windows Service ou Windows Form e ocorra o erro:
System.IO.FileNotFoundException: Retrieving the COM class factory for component with CLSID {5FF57840-5172-4482-9CA3-541C7878AE0F} failed due to the following error: 8007007e
Basta compilar sua aplicação em x86.
E agora, tudo certo? Até o momento sim. Porque não dizer que está tudo OK? Depois de ter ocorrido todos esses problemas, fica-se receoso com o futuro. Pode ser que ocorra outro problema posteriormente? Sim e irá.
Conforme disse anteriormente, o post não é para dizer mal sobre a Locaweb e/ou Plesk. Acho que eles prestam um serviço adequado para o nível nacional (até uso) contudo são coisas que acontecem que simplesmente poderiam ser sanadas antes de jogar o pepino para o cliente. Se você tiver algum problema desses e sua gerência for pelo cliente, nem adianta pedir que eles vão lhe informar: "o gerenciamento é por conta do cliente e não nos responsabilizamos" ou "a ferramenta (Plesk) é terceirizada e não prestamos suporte.". Enfim, espero que o post ajude a você, cliente e usuário, a corrigir seus problemas/pepinos que ocorrerem. Isso me lembra quando lançou o plug-and-play... a velha piadinha do plug-and-pray (ligar e rezar) não some da cabeça quando ocorre esse tipo de problema. Porque será?
Uma dica que dou sempre quando alguém quer contratar um servidor: leiam muito sobre os prós e contras. Os prós vejam no próprio site do prestador, os contras vejam nos relatos de usuários. No post a seguir não estou jogando a Locaweb contra a parede, apenas estou expondo erros que podem ser sanados de forma fácil mas que burocraticamente é jogado para o cliente se virar (nos 30!).
Nesse Cloud Server vem embutido o Plesk. Em poucas palavras serve para gerenciar a hospedagem através de uma interface web. É uma boa ferramenta de gerência, tem tudo para gerenciar sua hospedagem. Só que esse demais gera ocupação demais (redundância) de espaço em disco. Dos 50 Gb que você contrata, 40Gb é para o sistema operacional e 10Gb para seus arquivos. Sendo que dos 10Gb é para todos os seus arquivos, e-mails, banco de dados, etc. Ou seja, apenas usufrui dos 10Gb um pouco menos que 9Gb e olhe lá.
Bem, dizem que vem tudo preparado e instalado para usar... Verdade até certa parte! Quem está usando e é iniciante vai ver que é mil maravilhas. Dá para fazer o básico de tudo. O problema vem a seguir...
Um cliente contratou o Cloud Server gerenciado pelo cliente (ou seja, sobrou para o usuário final) e me passou para configurar e deixar no ponto de uso fazendo toda a migração e instalação. Em um passe de mágica surgem os problemas...
Os bancos de dados que vem são o MS SQL Server 2008 e o MySQL. Não há interface para dump e recovery das bases forçando a usar o Plesk para isso, mas não queria. Onde está o Management Studio 2008? Onde está o MySQL Workbench? Como vou fazer para migrar as bases? Gerar script de bancos gigantes? Nem pensar! Preciso instalar!
Mas como instalar esses aplicativos? Se fazer download, gera tráfego. Se pedir para a Locaweb tem que pagar e se pedir, de graça, não instala! Lembrando que esses aplicativos, no mínimo, são gratuitos e deveriam estar em uma zona em que os usuários pudessem obtê-los de forma fácil e sem cobrança. Pois bem, feito o download, hora de instalar. Abrindo o executável (lembrando que tem que ser a da versão 64bits) dá aviso de incompatibilidade. É preciso instalar o Service Pack 1 do SQL Server 2008 (mais tráfego). Baixado o SP1 é preciso instalá-lo. Tranquilo e instalado sem problemas. Hora de instalar o Management Studio...
Ao tentar abrir, outro problema?!?! É preciso do Framework 3.5! Incrivel... No Cloud Server vem instalado a versão 2.0 e 4.0 do Framework ASP.NET mas não tem a 3.5 ativado. Menos mal, porque no Windows Server 2008 é nativo, basta ativar. Realize os seguintes passos (retirado do Wiki):
- Clique em Start, Administrative Tools e selecione Server Manager;
- Na interface, clique em Features e clique em Add Features;
- Selecione a primeira opção .NET Framework 3.5.1 Features e adicione todos seus dependentes;
- Conclua a instalação do Framework.
Agora sim, tudo pronto! Vamos instalar o Management Studio. Clica no instalador e... Erro! Caramba... de novo!
TITLE: SQL Server Setup failure.
-------------------------------
SQL Server Setup has encountered the following error:
Invoke or BeginInvoke cannot be called on a control until the window handle has been created.
A dica é: feche o Windows Explorer! Por algum motivo, a instalação do Management Studio não inicia quando o Windows Explorer estiver em aberto. Copie para a Área de Trabalho e abra o instalador... Agora sim! Depois de tanta malemolência pelo menos iniciemos a instalação. Para quem tem dúvidas e um passo-a-passo bem explicativo de como instalar o Management Studio, acesse aqui o post de Marcos dell Antonio. Há uma dica bem interessante que pode confundir o usuário na hora da instalação. Terminado a instalação, menos um item da lista de afazeres.
Consegui conectar ao SQL Server local, criei as bases, usuários, fiz restores, configurei o backup, providenciei tudo o que tinha que fazer onde o Plesk jamais pensaria em um dia ser. Agora o principal, testar um website. Publiquei o site no IIS e abri o navegador para visualizar. Erro!
Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Sabe o porquê disso? Eu instalei o ASP.NET 3.5 depois que eu já tinha a versão 4.0 instalada por causa do Management Studio então gerou conflito nas DLL's. Para resolver, faça o seguinte:
- Vá para a pasta C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
- Execute o comando aspnet_regiis.exe -iru
Agora vamos testar! Abri o navegador e digitei o endereço e... Mais erro!
There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined
Mais conflitos! Se você tiver outra versão do System.Web.Extensions instalado, devido ao ASP.NET AJAX por exemplo, a versão que está no GAC do sistema difere da que você quer chamar ocorrendo ambiguidade. O correto seria alterar os assemblys mas como isso é muito trabalhoso e pode acontecer algum imprevisto para aqueles que não sabem manuseá-las, então aconselho o seguinte: remova toda a sectionGroup do seu web.config ou comente-as:
<!--
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere" />
<section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
<section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
-->
No caso comentei o sectionGroup do System.Web.Extension que pode estar na versão 1.0, 2.0 ou 3.5 que for.
Agora vamos lá! De pés juntos e mãos dadas: Abre o navegador e... e... e... Funcionou! Depois de um árduo trabalho aparentemente tudo estava normal. Vamos testar outros sites e... e... e... Mais erros!
Quem ainda não está acostumado a trabalhar com Windows Server 2008 e IIS 7 terá que aprender muito sobre permissões e tratamento de erros. Incontestavelmente a tela do erro 500 irá aparecer e muito se sua aplicação não estiver configurada adequadamente para o IIS 7. Nem sempre a mesma aplicação que está no IIS 6 irá funcionar no IIS 7. Então eis que surge a tela do Erro 500 Erro Interno do Servidor ou Error 500 Internal Server Error:
Ou então:
Dá para descobrir o que é? Vou dar a dica: revise seu web.config. "Ah, mas está tudo certo, não sei porque não funciona...". Engano, está errado. Já disse que o IIS 7 é chato, muito chato. O parser dele é muito minucioso e se não estiver nos padrões vai dar problema.
Se você não sabe utilizar bem o IIS e tem medo de alterar uma coisinha ali e outra acolá vou dar a maior dica: saia abrindo cada opção do painel da aplicação até que uma delas acuse um erro de configuração.
Por exemplo, abra o item Documento Padrão. Se ele estiver configurado corretamente então abrirá a próxima tela normalmente. Se tiver algum erro, aparecerá um alerta. Então no web.config você deve corrigir a sessão correspondente. Ficou claro? Saia clicando um a um até que um deles se denuncie podendo então fazer a correção.
O que ocorreu comigo foi que um site que estava no IIS 6 podia colocar a mesma página (index.aspx) como padrão, duas vezes, e não tinha problema. Quando foi para o IIS 7, na qual estava herdando a configuração pai, e foi adicionar a página index.aspx como padrão novamente, ele dava erro e não sabia porquê. Então removi a entrada do web.config e funcionou. Desabilitar a mensagem de erro amigável no navegador vai funcionar (encontrar o erro)? Não. Desabilitar as páginas de erros personalizáveis do IIS vai funcionar (encontrar o erro)? Talvez ou não. Depende muito do ambiente que está configurado e quem está manipulando.
Pronto! Mais um problema solucionado... Vamos testar outro site e... e... e... Erro! Agora aconteceu um erro 404. Mas como? Erro 404 de página não encontrada mas se o caminho está lá? Incrivelmente no IIS do Cloud Server possuem dois Applications Pools do Plesk (e mais outros nativos): Plesk(default)(2.0) e Plesk(default)(4.0). O pool do 2.0 quase nem sempre funciona. E um comportamento anormal é que se você tem um site pai em 2.0 e um filho em 2.0 às vezes pára de funcionar. O "correto" é ter um pai 2.0 ou 4.0 com filho sempre 4.0. Estranho? Pode crer! E onde está o pool do 3.5? Tem que criar na mão mesmo.
Nota: Se você reiniciar o IIS o Plesk pára de vez e não volta:
Você terá que iniciá-lo manualmente. Mas antes terá que iniciar seu pool também (que é muito suspeito):
Ajeitado uma coisinha ali, outra aqui, vamos testar mais algumas coisas e... e... e... Quase tudo certo. Em questão de funcionalidade (que deveria ser) está quase tudo certo a não ser o funcionamento do bom e velho Crystal Reports. Quem já leu o post de erros do Crystal aqui e aqui nos deparamos com o erro:
O inicializador de tipo de 'CrystalDecisions.CrystalReports.Engine.ReportDocument' acionou uma exceção
ou
The type initializer for 'CrystalDecisions.CrystalReports.Engine.ReportDocument' threw an exception
Cuidado! Esse não é o descritivo do erro. Só com isso não dá para saber o motivo. Faça o debug, log, exibição da pilha ou na própria tela exiba o erro (sem ter AJAX) que teremos o erro completo. No link dos dois posts anteriores que fiz explica o problema do Crystal na plataforma 64bits e como pode resolver. Só que o problema no meu caso era permissão.
Server Error in '/virtual_directory_name' Application.
Error in File UNKNOWN.RPT:
The request could not be submitted for background processing.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Runtime.InteropServices.COMException: Error in File UNKNOWN.RPT: The request could not be submitted for background processing.
Os usuários listados abaixo, não tinham permissão na execução de scripts DCOM e gravação em algumas pastas (principalmente as que estão na unidade C):
- IWAN_plesk(default)
- IUSR
- IIS_IUSR
- NETWORK SERVICE
- INTERACTIVE
Esses são os usuários que devem ter privilégio (descritos abaixo) nas pastas listadas abaixo:
- C:\Windows\Temp\ : leitura \ escrita
- C:\Program Files (x86)\Business Objects\Common\2.8\bin\ : leitura
- C:\ : leitura
Obs: Para alguns servidores é preciso aplicar o Replace permission entries on all child objects nessas pastas.
Lembrando de reiniciar o IIS e/ou o servidor para recarregar as configurações.
Se estiver trabalhando com Windows Service ou Windows Form e ocorra o erro:
System.IO.FileNotFoundException: Retrieving the COM class factory for component with CLSID {5FF57840-5172-4482-9CA3-541C7878AE0F} failed due to the following error: 8007007e
Basta compilar sua aplicação em x86.
E agora, tudo certo? Até o momento sim. Porque não dizer que está tudo OK? Depois de ter ocorrido todos esses problemas, fica-se receoso com o futuro. Pode ser que ocorra outro problema posteriormente? Sim e irá.
Conforme disse anteriormente, o post não é para dizer mal sobre a Locaweb e/ou Plesk. Acho que eles prestam um serviço adequado para o nível nacional (até uso) contudo são coisas que acontecem que simplesmente poderiam ser sanadas antes de jogar o pepino para o cliente. Se você tiver algum problema desses e sua gerência for pelo cliente, nem adianta pedir que eles vão lhe informar: "o gerenciamento é por conta do cliente e não nos responsabilizamos" ou "a ferramenta (Plesk) é terceirizada e não prestamos suporte.". Enfim, espero que o post ajude a você, cliente e usuário, a corrigir seus problemas/pepinos que ocorrerem. Isso me lembra quando lançou o plug-and-play... a velha piadinha do plug-and-pray (ligar e rezar) não some da cabeça quando ocorre esse tipo de problema. Porque será?
Diferenças entre Aplicações Compiladas e Não-Compiladas
Postado por
Thiago Marçal
on sábado, 12 de março de 2011
/
Marcadores:
desempenho,
dicas,
dll,
iis
/
Comments: (0)
Quando programávamos (ou programamos) com aquelas linguagens do tipo PHP ou ASP Clássico apenas pegávamos o que foi implementado e jogávamos no servidor web para uso. Com a inovação das tecnologias e tipos de linguagens (compiladas, interpretadas, híbridas) algumas dúvidas nos cercam quando estamos publicando um certo projeto. Nesse caso, falemos do ASP.NET para as versões acima da 2.0.
Antes de mais nada, o ASP.NET é compilado. Mesmo que você jogue os fontes no IIS ele é compilado na primeira vez que é acessado (e/ou alterado). Você não vê, mas por trás é feito isso. Para quem nunca compilou uma aplicação web, há diversas formas para uma dada finalidade. Geralmente é usada a função Publish Web Site (compila e publica).
Mas o que muitos perguntam é: existe diferença de desempenho? Não! Muitos dizem que há um pouco, mas já trabalhei com várias aplicações e não notei qualquer diferença. Li vários artigos por aí na net e não achei qualquer um que demonstrasse e/ou notasse diferença brusca de desempenho. Então, elaborei a seguinte tabelinha abaixo com um pequeno resumo. Se tiver mais, favor avisar-me que atualizo:
Óbvio que toda regra tem sua exceção, então a depender dos casos supra-citados pode haver pequenos detalhes que mudam uma coisinha ou outra mas nada de tão drástico (de acordo com a tabela - exemplo, na compilação FULL você não altera sequer o HTML). Se quiserem conhecer mais sobre os tipos de compilação (Full, Pré ou Sob-Demanda) visite os links da MSDN e de Dennes Torres.
Antes de mais nada, o ASP.NET é compilado. Mesmo que você jogue os fontes no IIS ele é compilado na primeira vez que é acessado (e/ou alterado). Você não vê, mas por trás é feito isso. Para quem nunca compilou uma aplicação web, há diversas formas para uma dada finalidade. Geralmente é usada a função Publish Web Site (compila e publica).
Mas o que muitos perguntam é: existe diferença de desempenho? Não! Muitos dizem que há um pouco, mas já trabalhei com várias aplicações e não notei qualquer diferença. Li vários artigos por aí na net e não achei qualquer um que demonstrasse e/ou notasse diferença brusca de desempenho. Então, elaborei a seguinte tabelinha abaixo com um pequeno resumo. Se tiver mais, favor avisar-me que atualizo:
Compilada | Não-Compilada | |
Óbvio que toda regra tem sua exceção, então a depender dos casos supra-citados pode haver pequenos detalhes que mudam uma coisinha ou outra mas nada de tão drástico (de acordo com a tabela - exemplo, na compilação FULL você não altera sequer o HTML). Se quiserem conhecer mais sobre os tipos de compilação (Full, Pré ou Sob-Demanda) visite os links da MSDN e de Dennes Torres.
Wordpress em ASP.NET
O Wordpress é um dos melhores gerenciadores de blogs que eu já vi. Muito completo e de código aberto, sua flexibilidade de utilizar add-ons (plugins) é o que permite dar-lhe grande escalabilidade. Visite o link para conhecer... Já tinha utilizado a ferramenta algumas vezes e achei bem intuitiva e fácil de usar (além de manipulá-la). Então dei uma olhada na net e, infelizmente, não há versões dele em ASP.NET. Então pensei: porque não fazer?
Comecei a dar uma olhada no código analisando a reutilização das páginas. Vendo por alto dá para sentir como o negócio foi bem feito! Surpreendente o que foi feito em PHP... Voltando... Primeiro gerei uma cópia do HTML de algumas páginas. Como fiz isso? Exibindo a página no navegador, mostrando o código-fonte (em HTML) e salvando. Só assim que dá pois o código PHP está misturando com código HTML. É chato, trabalhoso e principalmente nunca fica do jeito que queremos. Mas ficou quase parecido.
Depois fiquei vendo que não vai ser tão fácil assim. Parei e desisti! Muito cansativo... Pelo menos já tenho o HTML de algumas páginas (estático). Fiquei enrolando por um tempo e precisava ter um CMS para sites. O Wordpress já é um CMS então pensei em agregar um módulo para fazer cadastros pegando uma tabela no banco de dados e transformando em formulário. Pelo menos isso! Feito...
Hoje, ao menos, já tenho um cadastro! Isso poderia ser feito por Linq? Claro! Isso é Linq... Apenas coloquei na casca do Wordpress. Ou seja, o que fiz, qualquer um poderia ter feito. Agora o mais difícil é fazer os demais módulos. Ou seja, fazer o Wordpress... Complicado! Não sei se conseguirei fazer. Talvez desista no meio do caminho ou não. Futuro indeciso. Se um dia terminar coloco no Google Code ou em qualquer repositório para download.
Fazendo umas pesquisas no Google, encontrei o site de David Pirek. Ele fez um gerenciador de conteúdo para blogs em ASP.NET (em MVC ainda) de forma bem mais reduzida que o Wordpress mas que tem o mesmo objetivo (menos a casca). Bem interessante! Para conhecer veja o projeto ASP.NET CMS 3.0. Acho que quebra um galho... Também, para ver o demo e a versão 4.0 clique aqui. A minha idéia de copiar o Wordpress e transformar em ASP.NET veio daí e no grande poder que a ferramenta disponibiliza.
Resumo
Projeto: Wordpress em ASP.NET
Linguagem: C# 3.5
Banco de Dados: SQL Server
Plugins: JQuery, Mootools, ASP.NET AJAX, NicEdit WYSIWYG
Andamento: 1%
Obs: Depois estava lendo que há um "armengue" de colocar o Wordpress em PHP e o blog em ASP.NET para funcionar. Parece que se colocar o Wordpress em um diretório e o blog em outro e configurar como aplicações separadas no IIS (lembrando que pode ter o PHP no IIS com FastCGI) dá pra fazer funcionar. Só que terá que programar o blog para puxar as informações. Não testei, mas fica a dica para quem quiser tentar...
Comecei a dar uma olhada no código analisando a reutilização das páginas. Vendo por alto dá para sentir como o negócio foi bem feito! Surpreendente o que foi feito em PHP... Voltando... Primeiro gerei uma cópia do HTML de algumas páginas. Como fiz isso? Exibindo a página no navegador, mostrando o código-fonte (em HTML) e salvando. Só assim que dá pois o código PHP está misturando com código HTML. É chato, trabalhoso e principalmente nunca fica do jeito que queremos. Mas ficou quase parecido.
Depois fiquei vendo que não vai ser tão fácil assim. Parei e desisti! Muito cansativo... Pelo menos já tenho o HTML de algumas páginas (estático). Fiquei enrolando por um tempo e precisava ter um CMS para sites. O Wordpress já é um CMS então pensei em agregar um módulo para fazer cadastros pegando uma tabela no banco de dados e transformando em formulário. Pelo menos isso! Feito...
Hoje, ao menos, já tenho um cadastro! Isso poderia ser feito por Linq? Claro! Isso é Linq... Apenas coloquei na casca do Wordpress. Ou seja, o que fiz, qualquer um poderia ter feito. Agora o mais difícil é fazer os demais módulos. Ou seja, fazer o Wordpress... Complicado! Não sei se conseguirei fazer. Talvez desista no meio do caminho ou não. Futuro indeciso. Se um dia terminar coloco no Google Code ou em qualquer repositório para download.
Fazendo umas pesquisas no Google, encontrei o site de David Pirek. Ele fez um gerenciador de conteúdo para blogs em ASP.NET (em MVC ainda) de forma bem mais reduzida que o Wordpress mas que tem o mesmo objetivo (menos a casca). Bem interessante! Para conhecer veja o projeto ASP.NET CMS 3.0. Acho que quebra um galho... Também, para ver o demo e a versão 4.0 clique aqui. A minha idéia de copiar o Wordpress e transformar em ASP.NET veio daí e no grande poder que a ferramenta disponibiliza.
Resumo
Projeto: Wordpress em ASP.NET
Linguagem: C# 3.5
Banco de Dados: SQL Server
Plugins: JQuery, Mootools, ASP.NET AJAX, NicEdit WYSIWYG
Andamento: 1%
Obs: Depois estava lendo que há um "armengue" de colocar o Wordpress em PHP e o blog em ASP.NET para funcionar. Parece que se colocar o Wordpress em um diretório e o blog em outro e configurar como aplicações separadas no IIS (lembrando que pode ter o PHP no IIS com FastCGI) dá pra fazer funcionar. Só que terá que programar o blog para puxar as informações. Não testei, mas fica a dica para quem quiser tentar...
URL Rewriter - Escreva URL Amigáveis em ASP.NET
Postado por
Thiago Marçal
on sexta-feira, 24 de setembro de 2010
/
Marcadores:
componentes,
dll,
iis
/
Comments: (0)
A URL Rewriter permite mascarar o endereço original por um novo endereço mais seguro e amigável. Se temos o endereço:
Podemos re-escrevê-la da seguinte forma:
Ou de outras formas conforme o mascaramento desejado. Para fazer o mascaramento é preciso do componente URL Rewriter instalado no IIS. Ele é gratuito e é instalado facilmente. Para cada web-site é configurado um mascaramento de endereços que automaticamente ele faz a conversão logo que requisitado.
Não vou entrar em detalhes do processo de instalação e configuração aqui pois no site oficial tem um vídeo (logo na Home), bastando seguir o passo-a-passo, que irá conseguir deixar conforme deseja. Também há disponível vários tutoriais que auxiliam no processo bem como funções avançadas. Clique aqui para visitar o site da Micrososft URL Rewriter.
http://thiagomarcal.blogspot.com/noticas.aspx?id_noticia=123
Podemos re-escrevê-la da seguinte forma:
http://thiagomarcal.blogspot.com/noticias/123
Ou de outras formas conforme o mascaramento desejado. Para fazer o mascaramento é preciso do componente URL Rewriter instalado no IIS. Ele é gratuito e é instalado facilmente. Para cada web-site é configurado um mascaramento de endereços que automaticamente ele faz a conversão logo que requisitado.
Não vou entrar em detalhes do processo de instalação e configuração aqui pois no site oficial tem um vídeo (logo na Home), bastando seguir o passo-a-passo, que irá conseguir deixar conforme deseja. Também há disponível vários tutoriais que auxiliam no processo bem como funções avançadas. Clique aqui para visitar o site da Micrososft URL Rewriter.
Corrigindo dois erros em uma tacada só: O provedor “Microsoft.Jet.OLEDB.4.0” não está registrado na máquina local e O inicializador de tipo de 'CrystalDecisions.CrystalReports.Engine.ReportDocument' acionou uma exceção.
Problema: Porque o sistema operacional é 64bits.
Solução: Modo de compatibilidade em 32bits.
Bom se todo post fosse assim tão rápido para solucionar nossos problemas. Agora vamos alongar mais as respostas e enriquecer nosso conteúdo:
1) O provedor “Microsoft.Jet.OLEDB.4.0” não está registrado na máquina local
Se por ventura você recebeu esse erro ao executar uma query em um banco de dados usando OleDb mesmo que tenha o Microsoft Office instalado corretamente é porque provavelmente a versão do driver instalado é para 32bits. Para corrigir isso, sua aplicação deve rodar em 32bits (x86). Nesse post aqui é mostrado como compilar sua aplicação desktop em x86 exclusivamente solucionando o problema. Mas para quem usa aplicações desktop terá que mudar a configuração do pool de aplicação no IIS. Para isso vá no IIS, Pools de Aplicativos e selecione o Pool usado pelas suas aplicações. Clique em Configurações Avançadas e no item Habilitar Aplicativos 32bits configure para True.
2) O inicializador de tipo de 'CrystalDecisions.CrystalReports.Engine.ReportDocument' acionou uma exceção
Caso bem semelhante ao anterior ocorre se sua máquina é 64bits e instalar o Crystal Reports 32bits (x86). O modo de compatibilidade que o Windows coloca para aplicações instaladas não funciona no caso. Para resolver isso basta instalar a versão 64bits do Crystal Reports (x64). Mas se você realizou o passo acima e está habilitado o modo de compatibilidade de 32bits no IIS então terá que usar a versão 32bits do Crystal de qualquer jeito.
Solução: Modo de compatibilidade em 32bits.
Bom se todo post fosse assim tão rápido para solucionar nossos problemas. Agora vamos alongar mais as respostas e enriquecer nosso conteúdo:
1) O provedor “Microsoft.Jet.OLEDB.4.0” não está registrado na máquina local
Se por ventura você recebeu esse erro ao executar uma query em um banco de dados usando OleDb mesmo que tenha o Microsoft Office instalado corretamente é porque provavelmente a versão do driver instalado é para 32bits. Para corrigir isso, sua aplicação deve rodar em 32bits (x86). Nesse post aqui é mostrado como compilar sua aplicação desktop em x86 exclusivamente solucionando o problema. Mas para quem usa aplicações desktop terá que mudar a configuração do pool de aplicação no IIS. Para isso vá no IIS, Pools de Aplicativos e selecione o Pool usado pelas suas aplicações. Clique em Configurações Avançadas e no item Habilitar Aplicativos 32bits configure para True.
2) O inicializador de tipo de 'CrystalDecisions.CrystalReports.Engine.ReportDocument' acionou uma exceção
Caso bem semelhante ao anterior ocorre se sua máquina é 64bits e instalar o Crystal Reports 32bits (x86). O modo de compatibilidade que o Windows coloca para aplicações instaladas não funciona no caso. Para resolver isso basta instalar a versão 64bits do Crystal Reports (x64). Mas se você realizou o passo acima e está habilitado o modo de compatibilidade de 32bits no IIS então terá que usar a versão 32bits do Crystal de qualquer jeito.
Corrigindo o problema do "Server Application Unavailable"
Esses dias me deparei com esse problema. Bem, há diversas causas que podem levar a isso e algumas soluções podem ser facilmente encontradas pela net mostrando problemas:
E inúmeros artigos/helps contendo outras soluções/causas... Mas também há um caso devido ao Application Pool. Resumo: o Application Pool gerencia a memória que é utilizada pelas aplicações no IIS. Não vou entrar em detalhes e serei bem direto na solução.
E inúmeros artigos/helps contendo outras soluções/causas... Mas também há um caso devido ao Application Pool. Resumo: o Application Pool gerencia a memória que é utilizada pelas aplicações no IIS. Não vou entrar em detalhes e serei bem direto na solução.
Bem, se você deu de cara com o problema do Server Application Unavailable e já não sabe mais o que fazer (já criou e recriou inúmeras vezes o site e deu na mesma), verifique todas as configurações (novamente), veja se o Application Pool trabalhado está ativo e funcionando sobre a mesma versão do Framework .NET da aplicação. Revise também a sua configuração ou crie um novo e altere na configuração do Web Site para o que foi criado. Isso deve resolver o problema...



















