Debug adapter process has terminated unexpectedly VS Code

CENÁRIO:

Na vida usando, e usando muito, o Visual Studio Code com projeto .NET Core, fui debugar meu projeto… mas deu erro 😥

Deu erro pra DEBUGAR?! WFT?!

Pra quem quiser começar a experimentar o Visual Studio Code: https://code.visualstudio.com/

Estou bem satisfeito usando no Mac OS. É muito rápido! Sublime virou só bloco de notas mesmo. Rs

ERRO:

Debug adapter process has terminated unexpectedly

SOLUÇÃO:

Fechei e abri o VS Code e reiniciei o Mac (depois de várias semanas, mas é preciso) e nada resolveu.

Pesquisando um pouco, descobri que tem um console do Visual Studio Code que não é o habitual da “IDE”, onde estava procurando por erros:

Mas nada de mensagem de erro nesses console.

Então, descobri este outro console “F12” do Visual Studio Code:

Help > Toggle Developer Tools

Neste console havia um erro informando que não conseguia achar o “c# extension asset”. Então, pra resolver, desinstalei e instalei novamente o C# Extension do Visual Studio Code.

Com isso, ele reinstalou o debugger e tudo voltou a funcionar! J

Abraço!

Fechando WINWORD.EXE ao utilizar o PIA

CENÁRIO:

Cenário bem comum em automação de processos é precisar criar/editar arquivos Office de forma automática e sem iteração do usuário final.

Para isso, podemos usar o Open XML SDK 2.5 para Microsoft Office: https://www.microsoft.com/en-us/download/details.aspx?id=30425.

Mas o Open XML SDK é apenas para os arquivos atuais do Office (pós 2007) que usam o OpenXML em sua concepção (.docx, .xlsx, etc).

Em tempos primórdios, tínhamos que usar o Primary Interop Assemblies (PIA) para trabalhar com arquivos Office via código: https://www.microsoft.com/en-us/download/details.aspx?id=3508.

E o trabalho é BEM MAIS árduo do que usar o Open XML SDK.

ANÁLISE:

E um cenário deveras comum, é encontrar uma aplicação que usa o Interop para manipular arquivos Office consumindo memória e nunca mais devolvendo, criando diversos processos, sem fecha-los após uso.

Cada processo WINWORD.EXE, neste exemplo, consumindo 25Mb de memória. E cada utilização, mais processos, até estourar memória do servidor (ou fechar os processos manualmente).

SOLUÇÃO:

A primeira dica é evitar o uso de “2 pontos” no mesmo “comando”.

Exemplo – Ruim

WordDOC.Document doc = app.Documents.Open(@"c:\teste.doc");

 

Exemplo – Bom

WordDOC.Documents d = app.Documents;

WordDOC.Document doc = d.Open(@"c:\teste.doc");

 

Bom, essa dica vai evitar que sejam criados wrappers em objetos COM que segurem o processo em memória.

A outra dica é sinalizar que os objetos já podem ser finalizados. Após o uso, vá finalizando o uso do objetos regressivamente.

 

using WordDOC = Microsoft.Office.Interop.Word;

…

Application app = new Application();

WordDOC.Documents d = app.Documents;

object nullobject = Type.Missing;

object doNotSaveChanges = WordDOC.WdSaveOptions.wdDoNotSaveChanges;

try

{

WordDOC.Document doc = d.Open(@"c:\teste.doc");

doc.Activate();

doc.SaveAs(finfo.FullName.Replace(".doc", "_tmp.docx"), WordDOC.WdSaveFormat.wdFormatDocumentDefault);

((Microsoft.Office.Interop.Word._Document)doc).Close(ref doNotSaveChanges, ref nullobject, ref nullobject);

Marshal.FinalReleaseComObject(doc);

Marshal.FinalReleaseComObject(d);

((Microsoft.Office.Interop.Word._Application)app).Quit(ref nullobject, ref nullobject, ref nullobject);

Marshal.FinalReleaseComObject(app);

}

catch (Exception ex)

{

HandleException(ex);

}

 

Dessa forma os objetos serão finalizados quando o GC ocorrer.

Abraço!

Enviando e-mails programaticamente usando o Office 365 (Exchange Online)

CENÁRIO:

Cenário bem comum em automação de processos é ter algum serviço que fique monitorando algum processo e depois envie e-mails de notificação aos interessados.

ANÁLISE:

Com o EWS Managed API 2.0 isso ficou muito simples. Principalmente utilizando o Office 365 ao invés de um Exchange Server on-premises.

Para facilitar BASTANTE as coisas, utilizaremos o Microsoft.Exchange.WebServices desenvolvido pela própria Microsoft.

https://msdn.microsoft.com/en-us/library/dd877012(v=exchg.150).aspx

Para instalar esse NugetPackage no projeto, é requisito que ele seja .NET 4.0.

HOW TO:

Instale o pacote no projeto. E o resto é bem simples.

static void Main(string[] args)

{

ExchangeService service = new ExchangeService();

service.Credentials = new WebCredentials(meuemail@dominioOffice365.com.br, "SENHA");

service.TraceEnabled = true;

service.TraceFlags = TraceFlags.All;

service.AutodiscoverUrl(meuemail@dominioOffice365.com.br, RedirectionUrlValidationCallback);

EmailMessage email = new EmailMessage(service);

email.ToRecipients.Add(meuemail@dominioOffice365.com.br);

email.Subject = "HelloWorld";

email.Body = new MessageBody("Este é o primeiro e-mail que envio usando o EWS Managed API.");

email.Send();

Console.ReadLine();

}

 

E o método de apoio para validar o esquema do AutoDiscover:

private static bool RedirectionUrlValidationCallback(string redirectionUrl)

{

// The default for the validation callback is to reject the URL.

bool result = false;

Uri redirectionUri = new Uri(redirectionUrl);

// Validate the contents of the redirection URL. In this simple validation

// callback, the redirection URL is considered valid if it is using HTTPS

// to encrypt the authentication credentials.

if (redirectionUri.Scheme == "https")

{

result = true;

}

return result;

}

Atualizado (resultado):

 

Abraço!