string is an alias in C# for System.String.
So technically, there is no difference. It's like int vs. System.Int32.
As far as guidelines, it's generally recommended to use string any time you're referring to an object.
e.g.
string place = "world";
Likewise, I think it's generally recommended to use String if you need to refer specifically to the class.
e.g.
string greet = String.Format("Hello {0}!", place);
This is the style that Microsoft tends to use in their examples.
It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.
New answer, powershell
TCP
Get-Process -Id (Get-NetTCPConnection -LocalPort YourPortNumberHere).OwningProcess
UDP
Get-Process -Id (Get-NetUDPEndpoint -LocalPort YourPortNumberHere).OwningProcess
Old answer, cmd
C:\> netstat -a -b
(Add -n to stop it trying to resolve hostnames, which will make it a lot faster.)
Note Dane's recommendation for TCPView. It looks very useful!
-a Displays all connections and listening ports.
-b Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
Best Answer
System.Environment.OSVersionhas the information you need for distinguishing most Windows OS major releases, but not all. It consists of three components which map to the following Windows versions:For a library that allows you to get a more complete view of the exact release of Windows that the current execution environment is running in, check out this library.
Important note: if your executable assembly manifest doesn't explicitly state that your exe assembly is compatible with Windows 8.1 and Windows 10.0,
System.Environment.OSVersionwill return Windows 8 version, which is 6.2, instead of 6.3 and 10.0! Source: here.Update: In .NET 5.0 and later,
System.Environment.OSVersionalways returns the actual OS version. For more information, see Environment.OSVersion returns the correct operating system version.