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:

https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/ise/introducing-the-windows-powershell-ise?f=255&MSPPError=-2147217396

https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/ise/how-to-debug-scripts-in-windows-powershell-ise

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.