![SharePoint Troubleshooting Series [Part 6]](http://tarcisiogambin.net/wp-content/uploads/sites/2/2013/04/xtrouble.jpg.pagespeed.ic.jEgGvCilk4.jpg)
SharePoint Troubleshooting Series [Part 6]
Olá Pessoal!
Falamos nos últimos posts sobre a utilização do Visual Studio Remote Debugging para troubleshooting, mas esta nem sempre é uma solução viável em todos os casos, ainda mais em ambientes com sérias considerações sobre mudanças e hardening.
Mas supondo que identificamos um problema em determinado método em uma WebPart, TimerJob ou qualquer outro artefato a nível de Farm Solution, mas não temos como “debugá-lo” no ambiente. Existe alguma opção adicional?
Sim!! Desde que tenhamos acesso aos seguintes itens:
- Código fonte
- Métodos que queremos validar/ testar
- Path da dll no Server
- Acesso ao PowerShell/ PowerShel ISE
#codigoFonte
Se você não possui o código fonte, não se assuste! É possível obtê-lo na maior parte dos casos através do seguinte procedimento:
- Exporte as soluções desejadas via powershell
- Com a solução desejada em mãos, renomeie o pacote “.wsp” para “.cab”
- Acesse o “.cab” via Windows Explorer. Será exibida uma estrutura de arquivos referente ao pacote
- Nesta estrutura, encontre as dlls desejadas referente ao projeto
- Faça o download do ILSpy
- Abra o ILSpy e abra as dlls citadas anteriormente
Segue abaixo um exemplo da análise do SharePoint 2013 FBA Pack da Visigo no ILSpy:
Atenção! Estamos fazendo um processo de reflector e não há uma garantia fidedigna em relação ao código original (é comum termos diferenças em relação a declaração de variáveis, conversão ou comparação de dados, etc), porém a estrutura está aí, o que já é mais de meio caminho andado 😉
#métodosQueQueremosValidarTestar
Se voce já conhece a estrutura do código, ou já identificou nos logs de erro do ULS alguma chamada para um método que está no stack trace, já andamos um pouco mais 🙂
Nesse caso é importante que você conheça o método, possível dependencia com outros métodos e parametros utilizados.
#pathDaDllNoServer
Precisamos agora identificar o Path da nossa dll no server que geralmente segue o seguinte padrão (no .Net Framework v4+):
“C:\Windows\Microsoft.NET\assembly\GAC_MSIL\”
Voce deverá ver uma serie de pastas, entre elas algumas que compreendem o nome dos pacotes WSP.
Dentro dessas estruturas de pastas, iremos encontrar as mesmas dlls que porventura foram identificadas no reflector acima, ou mesmo já são conhecidas pelas equipes de desenvolvimento, e que fazem parte do pacote final.
Estamos prontos para começar 😀
#acessoAoPowershell
De um modo geral precisamos de acesso ao Powershell com uma conta Farm Administrator em um dos servidores da Farm.
Após este acesso, certifique-se que o Snapin do SharePoint já esteja carregado. Na dúvida:
Add-PSSnapin Microsoft.SharePoint.PowerShell
O próximo passo agora é instanciar a Dll desejada, onde mencionamos o path previamente. Utilize o comando abaixo:
$meuAssembly = [System.Reflection.Assembly]::LoadFile("C:\Windows\Microsoft.NET\assembly\GAC_MSIL\<PathDaMinhaDll>.dll") $meusMethods = $meuAssembly.GetExportedTypes()
Podemos agora já listar todos as classes e métodos, conforme código abaixo:
$meusMethods | Get-Member -Static
Se preferir, podemos já salvar todos os classes e métodos em um arquivo de texto.
Bem, considerando o exemplo onde gostaríamos de validar determinado método que receba 3 parametros do tipo String, podemos executar o código abaixo:
$param1 = "Valor1" $param2 = "Valor2" $param3 = "Valor3" [MinhaSolution.Item.Classe]::Metodo($param1, $param2, $param3)
Pronto! Já temos condições de realizar troubleshootings a nível de código via Powershell!
Recomendação: utilize o PowerShell ISE, que irá lhe permitir maiores recursos de debugging:
Além de termos alguns helpers, o PowerShell ISE permite um debugging de verdade no código em tempo de execução 🙂
Maiores detalhes:
Espero que tenham gostado e happy sharepointing 🙂
Este post reflete apenas a opinião do autor sobre o assunto, e não fornece garantias ou responsabilidade sobre qualquer problema decorrente de sua utilização.