Respostas:
constimplica static(você não precisa de uma instância para fazer referência ao constvalor).
Também quero adicionar este ponto importante: Quando você vincula (faz referência) a uma montagem com um public const, esse valor é copiado para a sua montagem. Portanto, se o constvalor no assembly referenciado for alterado, seu assembly ainda terá o valor originalmente compilado.
Se esse comportamento não for aceitável, você deve considerar transformar o campo em um public static readonlycampo.
Lib.dll, fornecido como binário:
public class Foo {
public const int HATS = 42;
public static readonly int GLOVES = 33;
}
App.exe, faz referência a Lib.dll:
Foo.HATS // This will always be 42 even if the value in Lib.dll changes,
// unless App.exe is recompiled.
Foo.GLOVES // This will always be the same as Foo.GLOVES in Lib.dll
Do MSDN :
Não crie uma constante para representar informações que você espera que sejam alteradas a qualquer momento. Por exemplo, não use um campo constante para armazenar o preço de um serviço, o número da versão de um produto ou o nome da marca de uma empresa. Esses valores podem mudar com o tempo e, como os compiladores propagam constantes , outro código compilado com suas bibliotecas terá que ser recompilado para ver as mudanças.
De DotNetPerls :
DLLs. Quando você usa um
constcampo ou declaração, o compilador C # realmente incorpora oconstvalor da variável diretamente no código IL. Portanto, ele essencialmente apaga oconstcomo uma entidade separada.Cuidado: Se os programas que dependem de um
constnão forem recompilados após aconstalteração do valor, eles podem falhar [ porque continuarão a usar o valor anterior ].
Uma constante é estática por definição.
Constantes não podem ser substituídas no código durante a compilação, não em tempo de execução, portanto, não há requisitos para definições de instância estáticas.
Todas as declarações de constantes são implicitamente estáticas, e a especificação C # afirma que a inclusão (redundante) do modificador estático é proibida. Acredito que isso seja para evitar a confusão que poderia ocorrer se um leitor visse duas constantes, uma declarada estática e outra não - eles poderiam facilmente assumir que a diferença na especificação implicava uma diferença na semântica. Dito isto, não há proibição de especificar de forma redundante um modificador de acesso que também é o padrão, onde existe uma escolha. Por exemplo, um método (concreto) pode ser explicitamente marcado como privado, apesar de ser o padrão. A regra parece ser aquela onde não há escolha (por exemplo, uma declaração de método em uma interface), o modificador redundante é proibido. Onde há escolha, é permitido.