Private, non-virtual methods which don't access any instance members were made `static`

[Lehonti]

As an extra:

• Unused namespace references were removed from Build.cs
• Private fields which are never modified were made readonly. But there were only two instances of it (see second commit), so I don't think a separate pull request is justified.

[batzen]

Hi there.

The code related to the build was kept without static to make it easier to read. There is no benefit in making it static.

The code that was otherwise not static was kept that way to make it easier to extend if it needs to access instance members in the future.

The change in RibbonGroupBoxWrapPanel leads to a compile error. Having a look at the code reveals that I made a mistake regarding the orientation anyway, as the DP does only return the field but does not use the DP itself, which is wrong (my mistake).

The only desired change I see is the readonly one in InRibbonGallery.

[Lehonti]

No problem, I removed static qualifiers from all except InRibbonGallery.

It's important to note that making a method static provides stronger guarantees, which you can use to safely refactor your code later on. In my company's codebase they've often helped me to extract code into neat extension methods.

[batzen]

In which regard do static methods provide stronger guarantees?

In regard of extension methods, if you mean class extension methods, the opposite is the case. If you have an extension method Do for class A and then after some point, for whatever reason, someone decides to add a method named Do to class A every calling code, which previously called the extension method will now call the class method instead. If Do would have been static that wouldn't be the case, as you can't add static extension methods to a class, as far as I know.