Melz

Marshal.ReleaseComObject() нужно вызывать явно — в том же самом потоке (thread), где мы получили этот COM-объект.
GC работает в другом потоке. Там вызывать нельзя. Поэтому деструктор придется убрать.

Я использую конструкцию using — код остается читабельным.

using (var conn = new Object1C(connectorInstance.Connect(ConnectionArgs.ToString())))
{
    // Делаем необходимую работу
}

P.S. Не забывайте также освобождать любые 1С-объекты, полученные вами через это COM-соединение. Методика та же.

<Label
  Content="{Binding ElementName=slider1, Path=Value}"
  ContentStringFormat="{}Выбрано {0} единиц"
  DockPanel.Dock="Top"
/>

Это как раз та проблема, ради решения которой придумали Dependency Injection. Если вы жестко завязываетесь на статический класс Console, приходится мириться с его ограничениями, в частности - однопоточностью.

Самое грамотное решение, за которое будет не стыдно - действительно, использовать DI и интерфейс. Придется реализовать два класса на его основе - "боевой" ConsoleWrapper и тестовый ConsoleWrapperMock.

В качестве быстрого и грязного решения - если программа несложная и вы можете протестировать всё через входные параметры, можно в тесте запускать ее как внешний процесс (вызывать exe-шник) - тогда процессы будут независимы друг от друга и тесты можно будет гонять параллельно.

Решил таким образом. Game.exe и Update.exe закроются, но останется открыта консоль из Update.exe и будет независимым процессом.

Melz, В Windows я делал обновление похожим образом, но там при закрытии Game.exe, Update.exe не являлся для него дочерним и существовал далее.

Код Game.exe:

static public void Run(Version version)
		{
			ProcessStartInfo psi = new ProcessStartInfo() {
				WorkingDirectory = Path.GetDirectoryName(AppDomain.CurrentDomain.BaseDirectory),
				FileName = "/usr/bin/mono",
				Arguments = String.Format("Update.exe -exe \"{0}\" -ud \"{1}\" -v \"{2}\"", Process.GetCurrentProcess().ProcessName, Config.ServerUrl, version)
			};
			Process.Start(psi).WaitForExit();

			MainForm.Instance.Close();
		}

Код Update.exe:

public static int Main(string[] args)
		{
			ParseArguments(args);
			String tmpFile = Path.GetTempFileName();
			File.Copy("update.sh", tmpFile, true);
			Process.Start("xterm", String.Format("-e sudo bash {0} {1} {2} {3}", tmpFile, AppName, UpdateDomain, VersionToInstall));

			return 1;
		}

https://www.nuget.org/

Неважно что там в свойствах файла, это бесполезно.
Важно то, что без AssemblyInfo другие .net сборки не будут знать версию этой сборки, она будет 0.0.0
Это может создать проблему в будущем, при контроле версий, или когда у вас будет несколько версий сборки в продакшене. Если таких проблем не предвидеться, можно игнорировать AssemblyInfo. Но я бы порекомендовал вернуть и заполнить его.

У вас путаница в мыслях... Во-первых, "подпрограмма" - это в C# синоним метода. Если вы используете winforms - то вы уже используете кучу подпрограмм :) А то, чего вы хотите избежать, называется "внешняя программа" или "дочерний процесс".

Во-вторых, рефлексия возможна только в отношении программ на платформе .NET - а перечисленные вами программы являются нативными. Разумеется, рефлексия в их отношении невозможна. По той же причине бесполезно из декомпилировать - все равно вам надо будет писать то же самое на другом языке.

В-третьих, ping, tracert и netsh не являются командами cmd.exe. Команды cmd.exe - это echo, if, call, set, goto, for и т.д., а то, что вы перечислили - это системные утилиты.

Теперь по вопросу.

ping. Имеется вот этот класс: msdn.microsoft.com/en-us/library/system.net.networ... Ни разу с ним не работал, но выглядит удобным.

tracert. Используйте тот же класс, указав Ttl в PingOptions.

netsh. Тут все сложнее. Дело в том, что эта программа - обертка для кучи разных настроек, находящихся в совершенно разных местах. Если вам нужно получать данные - то попробуйте поискать их в msdn.microsoft.com/en-us/library/system.net.networ... Если их там нет - гуглите. Главное - гуглите без ключевого слова netsh.

etc. А вот тут все не просто сложно, а невозможно. Невозможно взять неизвестную заранее утилиту, и сделать то же самое, что она делает, не запуская ее при этом. Поэтому вам надо определиться - либо ваша программа умеет выполнять фиксированный список действий - либо ей можно передать любую команду, но она будет запускать дочерние процессы. Возможен и промежуточный вариант - есть действия, которые программа может выполнять сама, а для выполнения других будут запускаться дочерние процессы.

Здравствуйте!
Существует. Пожалуйста: zbar.sourceforge.net/
Работает. Опенсорс.