Eu escrevi um serviço Windows multithread em C #. Por alguma razão, o csc.exe está sendo iniciado sempre que um encadeamento é gerado. Duvido que esteja relacionado ao encadeamento por si só, mas o fato de estar ocorrendo por thread e de curta duração torna o problema muito visível: muitos processos do csc.exe iniciam e param constantement

@Performance ainda é muito bom, mas espero que melhore se eu pudesse eliminar isso. No entanto, o que me preocupa ainda mais é que a McAfee está tentando verificar as instâncias do csc.exe e, eventualmente, mata o serviço, aparentemente quando uma delas sai no meio da verificação. Preciso implantar esse serviço comercialmente, portanto, alterar as configurações da McAfee não é uma soluçã

Presumo que algo no meu código esteja acionando a compilação dinâmica, mas não sei ao certo o que. Mais alguém encontrou esse problema? Alguma idéia para resolvê-lo?

Update 1:

Após pesquisas posteriores com base na sugestão e nos links das variáveis @sletterletter, o problema parece resultar da implementação da serialização XML, conforme indicado em Documentação da Microsoft no XmlSerializer:

Para aumentar o desempenho, a infraestrutura de serialização XML gera dinamicamente assemblies para serializar e desserializar os tipos especificado

Microsoft observa uma otimização mais adiante no mesmo documento:

A infraestrutura localiza e reutiliza esses assemblies. Esse comportamento ocorre apenas ao usar os seguintes construtores:

XmlSerializer.XmlSerializer (Type)

XmlSerializer.XmlSerializer (Tipo, String)

, o que parece indicar que o codegen e a compilação ocorreriam apenas uma vez, no primeiro uso, desde que um dos dois construtores especificados seja usado. No entanto, não me beneficio dessa otimização porque estou usando outra forma do construtor, especificamente:

public XmlSerializer (Tipo de tipo, Tipo [] extraTypes)

Lendo um pouco mais, acontece que isso também é uma provável explicação para um vazamento de memória que eu tenho observado quando meu código é executado. Novamente, do mesmo documento:

Se você usar qualquer um dos outros construtores, várias versões do mesmo assembly serão geradas e nunca descarregadas, o que resultará em um vazamento de memória e um desempenho ruim. A solução mais fácil é usar um dos dois construtores mencionados anteriormente. Caso contrário, você deve armazenar em cache os assemblies em um Hashtabl

As duas soluções alternativas sugeridas pela Microsoft acima são o último recurso para mim. Não é preferível ir para outra forma do construtor (estou usando o formulário "extratipos" para serialização de classes derivadas, que é um uso suportado pelos documentos da Microsoft) e não tenho certeza se gosto da idéia de gerenciar um cache de montagens para uso em várias threads.

Então eu tenho sgen e veja o conjunto resultante de serializadores para meus tipos produzidos conforme o esperado, mas quando meu código é executado, o conjunto produzido pela sgen não é carregado (por observação no visualizador de log de fusão e no monitor de processo). Atualmente, estou explorando por que esse é o caso.

Update 2:

O assembly sgen'd carrega bem quando eu uso um dos dois construtores XmlSerializer "mais amigáveis" (consulte a Atualização 1, acima). Quando eu usoXmlSerializer(Type), por exemplo, o assembly sgen'd é carregado e nenhum codegen / compilação em tempo de execução é executado. No entanto, quando eu usoXmlSerializer(Type, Type[]), a montagem não carrega. Não foi possível encontrar nenhuma explicação razoável para isso.

Então, estou voltando a usar um dos construtores e geradores suportados. Essa combinação elimina meu problema original (o lançamento do csc.exe) e mais um outro problema relacionado (o vazamento de memória induzido pelo XmlSerializer mencionado na Atualização 1 acima). Isso significa, no entanto, que eu tenho que reverter para uma forma menos otimizada de serialização para tipos derivados (o uso deXmlInclude no tipo base) até que algo mude na estrutura para resolver essa situaçã