Ответ 1
Это конвенция, а не требование. Если вы задумаетесь над CLR и посмотрите код там, вы часто увидите код P/Invoke внутри класса NativeMethods. Я считаю, что FxCop рекомендует поместить ваш код P/Invoke в такой класс, если он встретит его.
https://msdn.microsoft.com/en-us/library/ms182161.aspx
Являются ли три класса, описанные в этом paged, обработанными специально в .NET Framework? (NativeMethods, SafeNativeMethods и UnsafeNativeMethods)
Причина, по которой я спрашиваю, - мне интересно, можно ли создавать категории классов NativeMethods. Например:
ComNativeMethods
User32NativeMethods
OleStorageNativeMethods
Это конвенция, а не требование. Если вы задумаетесь над CLR и посмотрите код там, вы часто увидите код P/Invoke внутри класса NativeMethods. Я считаю, что FxCop рекомендует поместить ваш код P/Invoke в такой класс, если он встретит его.
Это просто соглашение, в котором говорится, что вы должны размещать методы p/invoke в классах с именем * NativeMethods, но нет никаких технических ограничений, чтобы помешать вам сделать это по-своему...
Вы можете назвать свои классы таким образом, но вы продолжите получать предупреждение CA1060 о анализе кода. Это предупреждение указывает, что вы не соблюдаете соглашение. Поэтому, чтобы предотвратить это предупреждение, вам нужно следовать соглашению, когда классы именования имеют методы P/Invoke. Если вы хотите классифицировать свои методы P/Invoke, вы можете использовать пространства имен. Например:
Они не обрабатываются специально CLR. Он просто рекомендовал, чтобы ваши P/Invokes внутри класса с именем NativeMethods, SafeNativeMethods или UnsafeNativeMethods.
Вы увидите, что эта рекомендация вступает в игру, если вы запускаете FxCop на своих сборках.