Alterar caminho do arquivo de log

Carlos,   Por que ao invés de setar o caminho de log dentro do app.config, por que não o faz num classe dentro de sua própria aplicação? Assim sendo, é so usar o Server.MapPath(~/PastaLog/Erro.txt)   Abraços Att Luiz Maia

Então, a minha dúvida é justamente essa, de forma dinâmica, poder alterar esse elemento do Enterprise Library que você seta o arquivo de log no app.config. Como poderia obter essa informação (o elemento do app.config) e alterar o mesmo?

Carlos,   Como vc configurou o recurso do Log, foi via Wizard, ou manualmente?    

Eu utilizei o Wizard, aquele que após que você instala, você consegue acessar pelo menu Iniciar >> Programas >> Enterprise Library, sabe?

Oi Carlos,   Pelo que achei, vc pode tentar fazer o seguinte para modificar o aap.config em runtime:   var path = System.IO.Path.Combine(Environment.CurrentDirectory, "EntLib.config"); 
var xd = XDocument.Load(path); 
 
var x = (from z in xd.Root.Elements("loggingConfiguration").Elements("logFilters").Elements() where (z.Attribute("name").Value == "Priority Filter") select z).SingleOrDefault(); 
x.Attribute("minimumPriority").Value = 1; // Change this value... 
x.Attribute("maximumPriority").Value = 5; // ... and this one to specify the range you want to log. 
 
xd.Save(path); 
  No exemplo acima, são alterados alguns atributos, mas não o da pasta do arquivo, alterei este e tente em sua aplicação. Os atributos alterados acima são os seguintes: <configuration> 
  ... 
  <loggingConfiguration name="Logging Application Block" tracingEnabled="true" 
    defaultCategory="General" logWarningsWhenNoCategoriesMatch="true"> 
    ... 
    <logFilters> 
      <add minimumPriority="1" maximumPriority="10" type="Microsoft.Practices.EnterpriseLibrary.Logging.Filters.PriorityFilter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
        name="Priority Filter" /> 
    ... 
  </loggingConfiguration> 
</configuration> 
    Para isto vc deve colocar as configurações do EL num arquivo separado, por exemplo:   <configuration> 
  <configSections> 
    <section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> 
  </configSections> 
  <enterpriseLibrary.ConfigurationSource selectedSource="EntLib Config"> 
    <sources> 
      <add name="EntLig Config" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
          filePath="EntLib.config" /> 
    </sources> 
  </enterpriseLibrary.ConfigurationSource> 
</configuration> 
    Para maiores explicações, de uma olhada no site da Microsoft: http://msdn.microsoft.com/en-us/library/dd203211.aspx   Abraços e aguardo seu retorno dizendo que funcionou, ok?   Att Luiz Maia

Ok,
Eu vou fazer os testes e lhe informo se funcionou.
Obrigado!

Ok Carlos, fico aguardando então...   Abraços Att Luiz Maia

E ai Carlos, funcionou?

Olha, nas tentativas iniciais que fiz, não consegui obter o nome do caminho. Bem, posso tentar mais algumas coisas, se depois precisar reabrir o post, pode fazer sem nenhum problema?

Sim Carlos, pode reabrir o post quando quiser, ok? Fico no aguardo   Abraços Att Luiz Maia

Oi Luiz! Tudo bem?   Então, decidi reabrir esse post. Sobre a minha dúvida, consegui solucionar com a lógica que você havia enviado, porém, fiz da maneira que segue abaixo:   xd.Root.Elements("loggingConfiguration").Elements("listeners").Elements().ElementAt(0).FirstAttribute.Value   Com isso, ele já me traz automaticamente o caminho do arquivo de log, e pela mesma propriedade Value, consigo setar esse caminho em tempo de execução. Então ao usar uma instância da classe System.XML.Linq.XDocument com método Save(), atende ao que preciso.   O que ocorre é que, eu uso o Enterprise Library para criptografar o app.config, e decidi criptografar ele por completo, todas as seções. Desta maneira, quando ele tentou enxergar o elemento "listeners" do elemento "loggingConfiguration", não conseguiu, já que com o arquivo criptografado, mudou o xml do app.config.   Com exceção da idéia de retirar a criptografia da seção loggingConfiguration, existe mais alguma alternativa que eu possa utilizar para solucionar esse problema?   Fico no aguardo e obrigado pela atenção!

Ola Carlos,   Seguinte, eu atualmente trabalho numa instituição Bancária, aqui adotamos o Enterprise Library também nos projetos .net. Só que temos uma área para segurança, outra para arquitetura e etc...   Mas o que fazemos aqui é o seguinte: Temos 3 ambientes: Desenvolvimento, homologação e Produção O web.config de desenvolvimento não pe criptografado. Assim que é gerado a versão de homologação ou de produção, apenas mudamos um parametro no web. config apontando para um arquivo xml. Este arquivo XML é criptografado quanto à string de conexão. Você pode usar este recurso tb.   Segue um exemplo:   Veja aqui um trecho do arquivo de configuração, no caso abaixo, apontando para testes:   <mbApplicationConfigurationManagement defaultSection="Testes"> <configSection name="Producao"> <configCache enabled="true" refresh="* * * * *"/> <configProvider assembly="MB.ConfigurationManagement,Version=2.2.0.0,Culture=neutral,PublicKeyToken=805a4b43124d7ae0" type="MB.ConfigurationManagement.Storage.XmlFileStorage" path="D:\Intranet_WS\MB.Web.Services.WSG.Proposta.Captacao\bin\ApplicationConfigProducao.xml" signed="true" encrypted="true"/> <protectionProvider assembly="MB.ConfigurationManagement,Version=2.2.0.0,Culture=neutral,PublicKeyToken=805a4b43124d7ae0" type="MB.ConfigurationManagement.DataProtection.BCLDataProtection" hashKey="MyXuEd6f+go=" initializationVector="ou95G2/WziI=" symmetricKey="VToaqZjp8C27V90oSmT/CF+afvRGClc9"/> </configSection> <configSection name="Homologacao"> <configCache enabled="true" refresh="* * * * *"/> <configProvider assembly="MB.ConfigurationManagement,Version=2.2.0.0,Culture=neutral,PublicKeyToken=805a4b43124d7ae0" type="MB.ConfigurationManagement.Storage.XmlFileStorage" path="D:\Intranet_WS\MB.Web.Services.WSG.Proposta.Captacao\bin\ApplicationConfigHomologacao.xml" signed="true" encrypted="true"/> <protectionProvider assembly="MB.ConfigurationManagement,Version=2.2.0.0,Culture=neutral,PublicKeyToken=805a4b43124d7ae0" type="MB.ConfigurationManagement.DataProtection.BCLDataProtection" hashKey="MyXuEd6f+go=" initializationVector="ou95G2/WziI=" symmetricKey="VToaqZjp8C27V90oSmT/CF+afvRGClc9"/> </configSection> <configSection name="Testes"> <configCache enabled="true" refresh="* * * * *"/> <configProvider assembly="MB.ConfigurationManagement,Version=2.2.0.0,Culture=neutral,PublicKeyToken=805a4b43124d7ae0" type="MB.ConfigurationManagement.Storage.XmlFileStorage" path="E:\MERCANTIL\WSG\WEBSERVICES\MB.Web.Services.WSG.Proposta.Captacao\bin\ApplicationConfigTestes.xml" signed="false" encrypted="false"/> </configSection> </mbApplicationConfigurationManagement> <appSettings>   Agora segue os arquivos XML:   - <configuration> - <Homologacao>   <signature>ZT1CCSpAXNDL3li6WYFcuUtJw0M=</signature>   <encryptedData>C6sxAEZaeW6jW9H6fYB3TxfQxq4jbCJL3a/FEC0I0JmxGZtmgwrLzxwQYGCoYGomJIYFjSc8wPjDq14GaN/S1FECp+Vx7zRtEDTgcBuBkyZLOCvF/HPaTjJ0nSYy+Wis/FTgzYXiUSLMCC7yO4eP5JDj8t5SqjWiFOz/4MLT/kFG/53/yzoLWieA0czMBGy36uS0ec/YiskafCCTbtEA9zoAzovrEddaZ2TO2KwEdmEmPUY1bhmz4u/Y++pjcT4HboDqrlcSewXopRc0BZdoS1a1Fgh0ovXXpOU5CBLCTnJh1rVUjwyrFAWl8ThZldJwdIo9VHC05LCPWeRuXpAxc723Hgpjkv8nJY6mGvy5m/bSUhKQM+du4bRDCduVdtLwii14duS6jGzmnCR9ORfOYZUhHg0QMr4MDYCdKVmENanTEkv14S1LAu0SHB9G7odDAp4wuiOKAStLXAx7MNAzIAKlhHIxyQ8gi3syUrcyA7m8RQVVyPZLOGdR6YW5u/QdUv5EbsBveYmK3BxsYzZb1n1+FOx+ILnQj66skOHGGYH5GsYh+d2obiboNvXYHcBTDn+gaUqNVoaFYXmtaipPXrb+QrbhgrPz6FC2g0vkV9SDp1z2nJiqynmQufzrWu8R5XOsfgv2K3A=</encryptedData>   </Homologacao>   </configuration>    Espero que entenda, pois o processo é bem complicado de implementar. Mas basicamente o que vai fazer é criar 3 arquivos xml com as conexões e criptografas apenas os dos ambientes de Homologação e Produção, sacou?   Assim, seu arquivo de configuração não tem necessidade de criptografia. É seguro? É, pois é utilizado num ambiente bancário onde segurança é primordial.   Qualquer coisa te mando uma aplicação pequena de teste, ok?   Aguardo retorno Att Luiz Maia  

Oi Luiz, Eu entendi a lógica dos ambientes para criptografia das informações do banco de dados, é interessante! Caso você possa enviar um projeto de teste como mencionou no post anterior para eu analisar melhor, fico agradecido. Então, aqui onde eu trabalho, não sei se segue a mesma linha do local que você trabalha, mas eu tenho que cuidar da segurança, da arquitetura, da manutenção, novos projetos, e assim vai... rs... Na verdade aqui não tem nada disso de criptografia de arquivo de configuração, houve um turn over alto onde saiu todos da equipe, eu entrei, me deparei com a situação aqui (nada fácil) e decidi tentar implementar algumas práticas que vejo para desenvolvimento de projetos em .net. No meu caso, inicialmente, posso deixar o arquivo de configuração sem a criptografia daquela seção, que não tem crise, protegendo o AppSettings e o ConnectionString, já é uma grande ajuda. Aqui como estou trabalhando com um windows application, faço uso de um app.config, e na minha máquina roda as mil maravilhas. Porém, quando fui distribuir no ambiente de homologação, não consegui executar a aplicação de jeito nenhum. Para testes, decidi mandar o arquivo descriptografado no qual a aplicação voltou a funcionar. Desta forma, para testes, no ambiente de homologação, decidi instalar o Enterprise Library, e após selecionar o arquivo de configuração, para a seção "Data Access Application Block", no atributo "ProtectionProvider" eu mudei para opção "RsaProtectedConfigurationProvider". Ao tentar salvar, o Enterprise Library enviou uma mensagem de erro, que segue abaixo: "
Falha ao criptografar a seção "connectionStrings" usando o provedor RsaProtectedConfigurationProvider. Mensagem de erro do provedor. O objeto já existe.
" Mas se eu escolher a opção "DataProtectionConfigurationProvider", o Enterprise Library consegue salvar a alteração normalmente e minha aplicação executa normalmente no ambiente de homologação. Você sabe de alguma explicação para isso, e que eu possa distribuir o arquivo de configuração fazendo uso da criptografia Rsa?

Oi Luiz,   Sobre o último post que escrevi da opção do "DataProvider" que havia funcionado, esquece, rs... No momento que tentei efetuar acesso a aplicação, gerou mesmo problema para descriptografar a chave.   Acho que o segredo para solucionar o problema está em gerar a tal chave e disponibilizar junto com a aplicação. Pelo que li, para tal situação (em que vai ser disponibilizado uma aplicação desktop para vários lugares) o mais indicado é utilizar a criptografia RSA, que posso fazer uma vez na minha máquina e disponbilizar para todo mundo. Só acho que por dentro da aplicação terei que executar um comando para registrar essa chave nas máquinas clientes, estou certo?   E você sabe como gerar essa chave para arquivo app.config? Só consigo achar exemplo para arquivo web.config.   Fico no aguardo, e obrigado pela atenção!

Esta chave que vc esta falando deve ser o SSL (security socket layer) do proprio browser, correto? Se for, ele se existe mesmo para aplicações web, onde dentro do ambiente do HTTPS todos os dados trafegam criptografados.   Vou analisar outra solução e posto aqui, ok? Abraços Att Luiz Maia

Sim, acredito que sim. Então, em aplicações para web que precisei fazer esse tipo de procedimento, beleza, conseguia me virar com o aspnet_regiis, porém como essa é uma aplicação Windows Forms, então não sei como proceder para o arquivo app.config e não consegui encontrar nada até então nas minhas pesquisas.   Bem, fico no aguardo e obrigado pela ajuda!

Carlos,   Veja este artigo: http://www.pnpguidance.net/Post/EnterpriseLibrary3VisualStudioIntegratedConfigurationEditor.aspx     Vc consegue encriptar as sessões do seu arquivo de configuração. Quanto ao caminho do log, tente usar o Server.mapPath, assim fica um caminho relativo e pode ser setado dentro de sua aplicação, que ao compilar ficara inacessivel ao usuario.   Não sei se é extamente isto que deseja, caso contrario, me informe, ok?   Aguardo seu contato Abraços Att Luiz Maia

Oi Luiz,   Quanto ao caminho do arquivo de log já consegui resolver conforme mencionei anteriormente, vou deixar descriptografado mesmo, só vou criptografar a seção do connectionStrings. Sobre o artigo que você enviou, eu já executo o procedimento citado por ele, isto é, eu abro o Enterprise Library Configuration (versão 4.1) na minha máquina e por lá para cada seção eu configuro a propriedade ProtectionProvider.   Na minha máquina executa normalmente, o meu problema está sendo justamente na distribuição para as máquinas clientes, por se tratar de uma aplicação do tipo Windows Forms. Quando é instalado o sistema na máquina do usuário, ocorre o problema ao carregar o sistema justamente porque o mesmo não consegue descriptografar o algoritmo pois ele não encontra a tal da chave RSA.   Se fosse uma aplicação web, lá no servidor eu até saberia como agir, fazendo uso do aspnet_regiis (gera chave RSA, importa para o arquivo web.config, coloca os arquivos no servidor, e assim por diante). Porém, como tem que fazer isso com o app.config, é que não encontro procedimento para gerar essa chave RSA ou qualquer coisa semelhante para resolver o problema.   Ainda efetuando as pesquisas (em paralelo com este suporte) encontrei o link abaixo:   http://www.c-sharpcorner.com/blogs/BlogDetail.aspx?BlogId=229   Nele, em um determinado trecho, chamado "How to encrypt app.config file of windows\console application?" ele diz para executar o procedimento de criptografia da seção em um web.config, copiar e colar para o app.config, mas testei e depois de distribuir, ocorreu o mesmo erro.   Outros mencionam de você gerar um arquivo web.config, fazer a criptografia e inclusive a questão da chave RSA, depois renomear o nome para app.config (esse ainda não testei). Para você ter uma idéia do problema que estou falando (caso ainda não tenha feito esse teste), se você puder, instale o Enterprise Library Configuration em uma máquina diferente da desenvolvimento, pega um arquivo app.config criptografado e tente abrir nele. No meu caso, na minha de homologação, ocorre o erro.   Você tem mais alguma idéia do que eu possa fazer?

Luiz,   Hoje estava pensando em outras formas de criptografar os dados da connectionString e até voltei a pensar na solução que você havia proposto. Como você comentou, você tem nos ambientes de homologação e produção, os arquivos dos dados da conexão criptografado (em um arquivo xml).   O que eu gostaria de saber é, que tipo de algoritmo você utiliza para criptografar esse arquivo XML?   O que eu estava pensando aqui é, no arquivo de configuração, criptografar os dados do atributo connectionString, fazendo uso do algoritmo simétrico. Pelo algoritmo de hash, acho que não seria possível, porque não gostaria de fixar os dados da conexão no código para gerar o hash e comparar com o que estiver no app.config (para evitar possíveis engenharias reversas), mas fico com receio de usar esse algoritmo simétrico e alguém com um pouco mais de habilidade conseguir descriptografar.   Bem, resumindo, se realmente fosse seguro fazer uso do algoritmo simétrico, ai eu usaria mais um bloco do Enterprise Library (o de criptografia) para fazer isso, e acredito que seria mais uma boa prática aqui para os projetos, equipe. O que você acha? Tem fundamento isso que estou falando?   E ai até poderia pensar em adotar esse padrão independente do tipo de arquivo de configuração (app.config ou web.config) para distribuir para os clientes.   Bem, fico no aguardo, além dos demais posts que inseri anteriormente. Valeu!!

O Banco aqui usa mecanismos proprios para criptografia dos arquivos de configuração, mas somente as conections string são criptografadas. Voce mesmo pode criar um mecanismo de criptografia e adota-lo em seus projetos.

Ok, vou implementar então o que mencionei no post anterior 

Blz Carlos, qualquer coisa me avise. Abraços Att Luiz Maia