d-stream

А поставить точку останова в начале цикла и посмотреть на ту кашу что оказалась в data - не позволяет религия?

hint: отделить мух от котлет - читать строки в массив и проходя по всем этим строкам разбивать их уже разделителем на логин и пароль.

Длина строки, назначенной Arguments свойству, долж...

Лучше для начала взять свой объект и сериализовать его в xml и сравнить его с тем что опубликован...
Ну или "ленятйски" попросить VS сгенерировать классы по xml ( Edit -> PasteSpecial) и тогда сравнить со своим классом

Собственно основные тенденции и c# (net.core) на сегодня - умение работать и на linux тоже. Что удивительно только сейчас, а не намного раньше.

Мало того: Windows все больше и больше становится Linux (гуглить WSL/WSL2)

Так что наверное стоит подумать либо смене симпатий либо о смене профессии, а то ведь даже разработчик макросов для ворда неожиданно столкнется что ms office то есть и для mac, который Linux))))

Разрядность тут точно не при делах.
Как уже отметили - Start требует указания явного пути к запускаемому (иначе ведь вполне могут подсунуть совсем иное).
Для "обхода" ограничения в виде обязательного указания явного пути можно задействовать несколько вариантов:
- запускать cmd.exe указав в параметрах запускаемое приложение - поможет только если приложение лежит где угодно, но прописано в path
- перелопатить файловую систему и найти конкретный путь к приложению (Directory.GetFiles) - приложений может оказаться несколько и придется делать выбор
- проверить наличие в ожидаемых местах и при отсутствии спросить у пользователя, а потом сохранить это для последующих запусков

p/s/ можно еще порыть в registry на предмет проверки наличия установленных программ и добыть путь оттуда

https://habr.com/ru/post/176671/

Можно в цикле проверять, но не равенство, а условно "приблизительность" - например что модуль разницы меньше некоей дельты. Можно просто больше чем запланированное время (время прошлого выполнения плюс интервал).
Для систем, которые не носят приставки "реального времени" - это все всегда будет примерным.
Или можно пойти иным путем - например таймер и по его событию выполнять действия.

Отрываем немного водопроводный кран... и черпаем хоть одной хоть сразу десятью кружками в ведро - скорость наполнения ведра будет одинаковой... Точнее при большом количестве кружек часть прольётся...

Так и тут - общее время на скачку будет определяться размером файла деленному на самую меньшую скорость между отправителем и получателем.

Единственное что можно сделать для сокращение времени при ситуациях обрывов связи и повторов закачки - использовать механизмы докачки (это если отдающая сторона умеет).

Тогда общая канва будет выглядеть следующим образом:

- получаем размер файла
- готовим список фрагментов исходя из размера и прочих предположений
- качаем файл фрагментами (Range)
- если скачка удалась - метим фрагмент полученным, а неудавшуюся - повторяем
- когда все фрагменты получены - собираем их в файл
profit

p.s. по вкусу вышеописанное можно пускать в несколько потоков - иногда лимитер отдачи может лимитировать по конкретному соединению, а не сессии и суммарная скорость может подрасти.

Почему бы и не плясать именно от расположения исполняемого файла?
Например ..\..\config

p.s. Только Environment.CurrentDirectory - штука несколько зыбкая, лучше Assembly.GetExecutingAssembly().Location

https://docs.microsoft.com/ru-Ru/sql/connect/ado-n...