Fix namespace / folder mismatches

[drieseng]

We currently have classes in the following namespaces where the namespace of the class does not correspond with its file location (folder):

• Renci.SshNet.Security
• Renci.SshNet.Sftp.Requests
• Renci.SshNet.Sftp.Responses
• Renci.SshNet.Messages.Connection

These inconsistencies result in IDE0130 being reported.

To resolve this, we have two options:

1. Change the namespace of the class to correspond with its file location. When the class is public, this is a breaking changes.
2. Move the file to the folder that corresponds with its namespace. This is a non-breaking change.

Even though the first option is a breaking change in case of public class, I'd still at least consider this option for some classes.

Here's a breakdown by namespace:

Renci.SshNet.Security:

Class	Accessibility	Folder	Proposal
DsaKey	public	Security/Cryptography/	Change namespace
Key	public	Security/Cryptography/	Change namespace
EcdsaKey	public	Security/Cryptography/	Change namespace
ED25519Key	public	Security/Cryptography/	Change namespace
RsaKey	public	Security/Cryptography/	Change namespace

Renci.SshNet.Sftp.Requests:

Class	Accessibility	Folder	Proposal
FStatVfsRequest	internal	Sftp\Requests\ExtendedRequests	Move file
HardLinkRequest	internal	Sftp\Requests\ExtendedRequests	Move file
PosixRenameRequest	internal	Sftp\Requests\ExtendedRequests	Move file
StatVfsRequest	internal	Sftp\Requests\ExtendedRequests	Move file

Renci.SshNet.Sftp.Responses:

Class	Accessibility	Folder	Proposal
ExtendedReplyInfo	internal	Sftp\Responses\ExtendedReplies\ExtendedReplyInfo	Move file
StatVfsReplyInfo	internal	Sftp\Responses\ExtendedReplies\ExtendedReplyInfo	Move file

Class	Accessibility	Folder	Proposal
ExtendedReplyInfo	internal	Sftp\Requests\ExtendedRequests	Move file
HardLinkRequest	internal	Sftp\Requests\ExtendedRequests	Move file
PosixRenameRequest	internal	Sftp\Requests\ExtendedRequests	Move file
StatVfsRequest	internal	Sftp\Requests\ExtendedRequests	Move file

Renci.SshNet.Messages.Connection:

Class	Accessibility	Folder	Proposal
BreakRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
ChannelRequestMessage	public	Messages/Connection/ChannelRequest	Move file
EndOfWriteRequestInfo	public	Messages/Connection/ChannelRequest	Move file
EnvironmentVariableRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
ExecRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
ExitSignalRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
ExitStatusRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
KeepAliveRequestInfo	public	Messages/Connection/ChannelRequest	Move file
PseudoTerminalRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
RequestInfo	public	Messages/Connection/ChannelRequest	Move file
ShellRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
SignalRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
SubsystemRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
WindowChangeRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
X11ForwardingRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
XonXoffRequestInfo	internal	Messages/Connection/ChannelRequest	Move file
ChannelOpenInfo	public	Messages/Connection/ChannelOpen	Move file
ChannelOpenMessage	public	Messages/Connection/ChannelOpen	Move file
DirectTcpipChannelInfo	internal	Messages/Connection/ChannelOpen	Move file
ForwardedTcpipChannelInfo	internal	Messages/Connection/ChannelOpen	Move file
SessionChannelOpenInfo	internal	Messages/Connection/ChannelOpen	Move file
X11ChannelOpenInfo	internal	Messages/Connection/ChannelOpen	Move file

[drieseng]

@WojciechNagorski, what's you opinion on this? If we decide to change the namespace of a public class, we should of course document this in the release notes.

[drieseng]

When this is fixed, we should change the severity of IDE0130 back to error.

[WojciechNagorski]

The most important should be the client, which does not mean that I am against breaking changes. The client should see the classes in the appropriate namespaces. If some classes are in the wrong namespace then we should definitely move them.

What is worth remembering, many libraries use the technique of flattening the namespaces hierarchy. This can be useful if the library contains many small namespaces. Thanks to flattening, clients do not have to add so many namespaces.

But when I looked at the tables you prepared, I found that you can move files or change namespaces as you like.