Conjunto de regras recomendadas gerenciado para código gerenciado
Você pode usar o Microsoft gerenciado recomendados a regra de regras definida para enfatizar os problemas mais importantes em seu código gerenciado, incluindo buracos na segurança em potencial, falhas de aplicativo, e outros erros importantes de lógica e de design.Você deve incluir esta regra definida em qualquer regra personalizada definida que você cria para seus projetos.
Regra |
Descrição |
---|---|
Tipos que possui campos descartáveis deve ser descartável |
|
Declare manipuladores de eventos corretamente |
|
Marcar os assemblies com AssemblyVersionAttribute |
|
Os métodos da interface devem estar acessíveis por tipos de filho |
|
Tipos que possui recursos nativos deve ser descartável |
|
Mover P/Invokes à classe de NativeMethods |
|
Não ocultar métodos da classe base |
|
Implemente corretamente IDisposable |
|
Não digite as exceções em locais inesperados |
|
Evite aceleradores duplicados |
|
Os pontos de entrada de P/Invoke devem existir |
|
P/Invokes não deve ser visível |
|
Os tipos de layout automático não deve ser visível COM |
|
Chame GetLastError imediatamente depois de P/Invoke |
|
Os tipos de base visíveis de tipo COM o devem ser visível COM |
|
Os métodos de registro COM o devem ser correspondidos |
|
Declare P/Invokes corretamente |
|
Remova os finalizers vazias |
|
Os campos do tipo de valor devem ser portáteis |
|
As declarações de P/Invoke devem ser portáteis |
|
Não bloqueie em objetos de identidade fraco |
|
Revise consultas SQL para vulnerabilidades de segurança |
|
Especifique que o marshaling para argumentos de cadeia de caracteres de P/Invoke |
|
Segurança declarativa revisão em tipos de valor |
|
Os ponteiros não devem ser visíveis |
|
Os tipos não seguros deve expor campos |
|
A segurança do método deve ser um superconjunto do tipo |
|
Os métodos de APTCA só devem chamar métodos de APTCA |
|
Os tipos de APTCA só devem estender tipos de base de APTCA |
|
Não expõe métodos indiretamente com as demandas de link |
|
As demandas do link de substituição devem ser idênticas com base |
|
Cláusulas vulneráveis de quebra automática finalmente tente externa |
|
As demandas do link do tipo exigem demandas de herança |
|
Os tipos críticos de segurança não podem participar da equivalência do tipo |
|
Os construtores padrão devem ser pelo menos críticos quanto construtores padrão do tipo de base |
|
O delega devem associar a transparência consistente com métodos |
|
Os métodos devem manter a transparência consistente ao substituir métodos de base |
|
Os métodos transparentes devem conter apenas o IL verificável |
|
Os métodos transparentes não devem chamar métodos com o atributo de SuppressUnmanagedCodeSecurity |
|
O código transparente não deve referenciar itens críticos de segurança |
|
Os métodos transparentes não devem satisfazer LinkDemands |
|
Os tipos devem ser pelo menos críticos quanto os tipos de base e interfaces |
|
Os métodos transparentes não podem usar segurança afirmam |
|
Os métodos transparentes não devem chamar em código nativo |
|
Lançar novamente para preservar detalhes da pilha |
|
Não remove objetos várias vezes |
|
Inicializar os campos estáticos de tipo de valor de tabela embutida |
|
Não marque componentes atendidos com WebMethod |
|
Os campos descartáveis devem ser removidos |
|
Não chame métodos overridable nos construtores |
|
Os tipos descartáveis devem declarar o finalizador |
|
Finalizers deve chamar o finalizador da classe base |
|
Construtores de serialização de ferramentas |
|
Operador de igual de sobrecarga em substituir ValueType.Equals |
|
Pontos de entrada do Windows Forms de marca a STAThread |
|
Marcar todos os campos não serializáveis |
|
Chamar métodos da classe base em tipos de ISerializable |
|
Marcar tipos de ISerializable com SerializableAttribute |
|
Implementar os métodos de serialização corretamente |
|
Implementar ISerializable corretamente |
|
Forneça argumentos corretos para formatação métodos |
|
Teste para NaN corretamente |