Melhores práticas para C# portátil [fechado]

Question

Estou procurando escrever algum código C# para Linux/Windows/Mac/qualquer outra plataforma e estou procurando práticas recomendadas para código portátil.

Projeto mono tem alguns ótimos portabilidade recursos.

Quais são as melhores práticas para C# portátil?

Answer 1

Na verdade, usei winforms e estava tudo bem.Foi BUTT UGLY, mas funcionou.

Obviamente, não use P/Invoke ou qualquer coisa do win32 como o registro.Esteja ciente também de quaisquer DLLs de terceiros.Por exemplo, usamos uma dll SQLite de terceiros que na verdade contém código nativo que precisamos trocar se quisermos rodar em OSX/linux.

Answer 2

Odeio o termo "Melhores práticas" porque parece que algumas práticas podem ser as melhores em qualquer contexto, o que é algo arriscado, mas vou contar o que considero uma "Boas práticas" para código multiplataforma (e para a maioria outro tipo de desenvolvimento):

Use um mecanismo de integração contínua e construir para todas as plataformas alvo o tempo todo.

Parece muito complexo?Bem, se você realmente precisa oferecer suporte a múltiplas plataformas, é melhor fazê-lo.Não importa o quão cuidadoso você seja com seu código e uso da biblioteca, se você testar tarde demais, acabará gastando muuuuitas horas retrabalhando grandes partes do aplicativo.

Answer 3

Cuidado com qualquer coisa relacionada à manipulação de nome de arquivo e caminho e use os métodos .NET portáteis em Sistema.IO.Path ou seja.

em vez de:

string myfile = somepath + "\\file.txt";

fazer:

string myfile = Path.Combine(somepath, "file.txt");

Se você precisar especificar um separador de caminho, você usaria Caminho.Separador etc.

Answer 4

Não use " " para uma nova linha.Usar Ambiente.NewLine

Lembrar :

• *NIX usa apenas o caractere de nova linha (" ")
• Windows usa " "
• MacIntosh usa " " (não tenho certeza sobre isso - sinta-se à vontade para me corrigir).

LE:Parece que alguns MacOS mais recentes não usam mais o separador de linha "\ r".

Answer 5

Não use Windows.Forms para GUIs, mas Mono provavelmente já mencionou isso.Gtk# é muito mais consistente e confiável para GUIs de plataforma cruzada.

Answer 6

Há alguns anos, eu teria aconselhado você a comprar uma cópia do meu livro em plataforma cruzada .NET, mas como o livro está um tanto desatualizado agora você realmente precisa se ater às informações do site Mono.

O Analisador de Migração Mono (MoMA) A ferramenta é muito boa para analisar um aplicativo .NET existente e avisar sobre problemas de portabilidade, mas a melhor aposta para um novo código é usar a versão estável mais recente do Mono para seu trabalho de desenvolvimento.

Como Orion disse, você precisa ter cuidado ao usar DLLs de terceiros, embora meu coautor tenha escrito um NativeProbe ferramenta para analisar DLLs para dependências P/Invoke se você quiser verificar rapidamente software de terceiros.

Se você está determinado a desenvolver no MS .NET, então você deve tentar garantir também a compilação e o teste de unidade no Mono, e também deve estar atento a vários namespaces específicos do Windows, como os namespaces Microsoft.Win32 e System.Management.

Answer 7

Se quiser que o código seja portátil, você precisa revisar atentamente a lista de recursos concluídos no site Mono.Eles detalham cada classe da estrutura e o nível de integridade.Você terá que levar essas coisas em consideração durante o processo de design para não ir muito longe e descobrir que um recurso crítico ainda não foi implementado.

Answer 8

Existem algumas outras coisas simples.Como não assumir caracteres de caminho.Ou novas linhas.

Sou uma das pessoas que compila regularmente o NUnit no Mono no Linux ou OSX.

Além disso, não presuma que os compiladores funcionam exatamente da mesma forma.Encontramos recentemente um problema em que o compilador MS C# parece incluir coisas que o Mono não inclui, exigindo referências extras em nosso script de construção.

Fora isso, foi bastante simples.Lembro-me da primeira vez que tivemos a GUI rodando em Mono/Linux - foi muito emocionante (mesmo que era bonito feio)

Answer 9

Um item faltando:Certifique-se de que os nomes dos arquivos diferenciam maiúsculas de minúsculas.Arquivo.Open ("MeuArquivo.txt");não funcionará no Unix se o seu arquivo for denominado myfile.txt.