zhaparoff

А какой вообще смысл переводить введенные строки в числа?
Просто храните все и обрабатывайте как строки.
Исходный массив, как я понял, в двоичной системе? { "10001", "1202", и т.д. }?

Просто откусывайте от каждого числа 3 (для восьмеричной) или 4 (для 16-ричной системы) символа с конца (справа); дополняйте до 3х или 4х символов нулями слева (чтобы корректно обработать самую старшую часть); и обычным switch выбирайте соответствующее число в восьмеричной или 16-ричной системе:
"101" -> "5" (oct)
"1101" -> "D" (hex)

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

Странное требование не использовать стандартные методы C# - я понимаю, что это скорее всего учебная задача, но вся суть языка C# в очень развитой объемной библиотеке "из коробки".
Console.ReadLine и Int32.Parse - тоже стандартные функции... Так что вообще без стандартных никак не выйдет, это 100%.

Переходите на VDI :-)

А если по существу - поддерживаю мнение Михаил Иванов.

В 3rd party халявного нормального софта мало, тот что есть - зачастую под linux - вышеупомянутый opsi тому пример. Если вы работаете на стеке Microsoft устраивать в серверной зоопарк - дороже выйдет.

SCCM - монстр. Требует: денег, знаний (причем на деле все с ним не так гладко как на бумажке) и что немаловажно - уйму ресурсов для нормальной работы. Стоит заморачиваться только если у вас реально большой парк ПК (штук эдак более 300), вы всерьез планируете перейти на полноценный ITIL (управление конфигурациями и прочие кошерные вещи).

Если у вас 100-150 компов - связки WDS + WSUS хватит с головой. Для большинства сценариев хватит базовых знаний в администрировании винды. Стандартный компонент Windows Server, визарды в стиле "next, next, next", куча документации и прочих плюшек.

Интерпретирую поток сознания автора вопроса:
Дано - ?
Решение - такое-то.
Вопрос - подходит ли данное решение?
Ответ, равноценный вопросу - "а зачем вы спгашиваете?"

Но любопытство победило лень )
Насколько я понял, автору нужно обработать непустые элементы массива. Большого массива.

Вариант 1
Вспомнить аббревиатуру KISS: перебирать все элементы по порядку и не изобретать велосипедов, в которых потом по два дня будете баги искать. А так же свести к минимуму риск быть проклятым тем человеком, которому ваш код достанется по наследству.
if (Array[i] == 0) continue; не такая уж и дорогая инструкция.

Вариант 2
Если массив приходит сортированный - проходить его с заполненного края.
Если нет - сортировать нет смысла. На сортировку потратите в любом случае больше времени чем на один проход по массиву.

Вариант 3
Если можете влиять на заполнение массива значениями, не вставляйте пустых, а только те, которые надо обработать.

В общем, для нормальной оптимизации в любом случае нужно больше входных данных.