Algumas aplicações poderão ser migradas facilmente para o .NET Core (especialmente as baseadas em ASP.NET MVC), mas outras devem enfrentar problemas, devido a mudanças e remoções de classes e APIs na nova plataforma. Além das dificuldades esperadas ao migrar de WinForms/WPF para Universal Windows Applications, existem questões mais sutis no .NET Framework que precisam ser levadas em consideração.
Reflexão
A API de reflexão mudou muito no .NET Core. Assim como o WinRT, foi "bifurcada" em uma versão leve e outra mais pesada. Sobre isso, Immo Landwerth da Microsoft escreve:
Com a criação do .NET Native, temos a tecnologia que permite fazer a vinculação estática da uma aplicação com frameworks e dependências de terceiros. Para isso, é importante que seja possível identificar as partes do framework que não estão sendo utilizadas. Em outras tecnologias, como C++, isso é relativamente simples, já que esses sistemas não possuem aspectos dinâmicos como reflexão.
O .NET Native ainda suporta reflexão, mas queríamos otimizar a plataforma, para que não se pague por funcionalidades não usadas. Isso é especialmente válido em reflexão, pois a reflexão impõe restrições sobre o que o ambiente de execução e os compiladores podem fazer com base em informações estáticas.
Idealmente, reflexão deveria ser um componente opcional no .NET Core, podend0-se tomar a decisão de não utilizá-lo. A parte complicada é que System.Object depende de reflexão devido ao método Object.GetType(). Para quebrar essa dependência, decidimos que System.Type deixa de representar a informação completa do tipo obtido via reflexão - mas somente o nome do tipo. Assim, System.Type no .NET Core não possui mais APIs como GetMembers(), mas continua expondo APIs como Name.
Um método de extensão chamado GetTypeInfo expõe o resto da informação que normalmente seria obtida do objeto Type. A classe TypeInfo não é mais tão rica quanto a original, mas a Microsoft decidiu recentemente trazer de volta algumas APIs de reflexão que não planejavam incluir no .NET Core.
Para tornar o código mais compatível, o .NET 4.5 (ou superior) suporta a versão de TypeInfo similar à do .NET Core.
App Domains
Os App Domains (domínios de aplicações) são implementados pelo CoreCLR, mas não pelo .NET Native. Devido às exigências sobre o runtime para suportar essa funcionalidade, não há planos para incluí-la. A equipe da MS indica que "para isolar o código, recomendamos processos e/ou containers. Para o carregamento dinâmico de assemblies, sugerimos a nova classe AssemblyLoadContext."
Execução remota
Hoje poucos são os desenvolvedores que lembram da existência da biblioteca de execução remota (Remoting) do .NET; menos ainda se lembram como utilizá-la; e os que a conheciam frequentemente reclamavam de seu desempenho, complexidade e fragilidade.
Para aumentar o desempenho, a comunicação entre aplicações .NET em uma mesma máquina foi substituída pelo WCF, ou por pipes e arquivos mapeados em memória. Entre máquinas, a Microsoft recomenda "um protocolo textual com baixo overhead, como o HTTP". Ou seja, a empresa não planeja incluir execução remota no .NET Core.
Serialização
A maioria dos serializadores como o serializador de contrato de dados (DataContract), o serializador de XML (XmlSerializer), o JSON.NET (Newtonsoft.Json), e o protobuf-net (Protocol Buffers) são suportadas no .NET Core. A principal exceção é a serialização binária.
Após uma década criando e mantendo serviços, aprendemos que serialização é extremamente complexa e que gera um peso imenso em compatibilidade para os tipos que suportam a funcionalidade. Tomamos a decisão que serialização deve ser um protocolo implementado em cima das APIs públicas disponíveis. Contudo, a serialização binária requer conhecimento profundo dos tipos, pois permite serializar grafos de objetos, incluindo o estado privado dos objetos.
Execução em sandbox
Em teoria, o sandboxing é uma ótima ideia; permite a execução de código parcialmente confiável de maneira segura. Na prática, é muito difícil implementar sandboxing de maneira correta e qualquer pequeno erro leva a vulnerabilidades de segurança. Immo Landwerth, da MS, diz que isso "torna a implementação mais complicada e muitas vezes afeta a performance de forma negativa das aplicações, mesmo das aplicações que não usam sandboxing".
A alternativa recomendada é iniciar processos separados que executam sob uma conta de usuário permissões restritas. Dessa maneira, o ambiente de execução não precisa duplicar a verificação custosa de permissões já realizada pelo sistema operacional.
Outros componentes
Os componentes na lista abaixo estão sendo considerados (no momento de escrita) para serem tornados open source e migrados para o .NET Core.
[Desde a publicação da notícia original, houve muito progresso na criação das funcionalidades abaixo no .NET core; confira o que já está disponível aqui.]
- System.Data. Embora sua camada base já seja parte do .NET Core, como o modelo de provedores (Data Providers) e o cliente SQL (SqlClient), algumas funcionalidades não estão disponíveis, como o suporte a esquemas de banco de dado e DataTable/DataSet.
- System.DirectoryServices. Nesse momento não há suporte para comunicação com LDAP ou Active Directory no .NET Core.
- System.Drawing. Embora seja essencialmente uma API cliente, muitos desenvolvedores usam System.Drawing no servidor para gerar miniaturas ou marcas d'água. No momento não há suporte a essas APIs no .NET Core.
- System.Transactions. O ADO.NET suporta transações, mas não há suporte a transações distribuídas, o que inclui a noção de ambiente de transação.
- System.Xml.Xsl e System.Xml.Schema. O .NET Core suporta o XmlDocument e o XDocument do Linq, incluindo XPath. Porém, não há suporte no momento para XSD (XmlSchema) ou XSLT (XslTransform).
- System.Net.Mail. Não há suporte ainda no .NET Core para envio de e-mails utilizando essas APIs.
- System.IO.Ports. Atualmente o .NET Core não é capaz de se comunicar utilizando portas seriais.
- System.Workflow. O Windows Workflow Foundation (WF) não está disponível no .NET Core.
- System.Xaml. Ao criar aplicações UWP, desenvolvedores utilizam APIs XAML do WinRT. Sendo assim, o .NET Core não traz o framework de XAML gerenciado, o que inclui a capacidade de interpretar documentos XAML e instanciar o grafo de objetos descrito.
A Microsoft convida os desenvolvedores a se envolver no trabalho de migração. Parte do código fonte das implementações do framework .NET está aberta sob licença MIT, como parte do Reference Source. "Estamos procurando maneiras de apoiar a comunidade em apoiar o esforço de migração", diz Immo Landwerth. Se está disposto a participar, envie um email (em inglês) para "immol(arroba)microsoft.com".
[Veja atualizações recentes na migração de APIs para o .NET core neste repositório do Github.]