Weageoo

Например так:

var array = from i in Enumerable.Range(0, 5)
            from j in Enumerable.Range(0, 3)
            select new { Row = i, Col = j };

Однако в этом случае у пользователя есть возможность ввести «x 1», и это будет воспринято как одна лексема «x1»:variable. Можно ли учесть все условия в одном регекспе, чтобы не производить предварительное удаление пробельных символов?

Предварительно удаляя пробелы вы не упрощаете задачу разбора выражения, а напротив — усложняете.

Уберите удаление пробелов и добавьте вместо этого пробелы в качестве ещё одной альтернативы в
regexp идущий сейчас вторым.

Т.е.:

var match = Regex.Match(infix, @"[-+*/^%()]|[A-Za-z][A-Za-z0-9]*|[+-]?[0-9]+\.?[0-9]*|[ \t]+");

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

При более-менее серьёзной задаче, естественно, стоит написать нормальный лексер, а не городить огород из Regex. И модифицировать его проще будет и работать он будет быстрее.

Как лучше всего проверить валидность выражения?
…
можно ли обойтисть только регулярками, или лучше заюзать генератор вроде Сосо/R

Задачу проверки корректности арифметического выражения средствами одних толкьо regexp-ов, насколько мне известно, решить нельзя.

Можно задействовать генератор парсеров, а можно написать простенький свой, работающий по методу рекурсивного спуска.

Всё зависит от того, что вам нужно — разобрать выражение или разобраться, как разбирать выражения.

Если вас интересует тема парсеров/компиляторов и т.п., то однозначно стоит прочитать «Компиляторы. Принципы, технологии и инструментарий».

Построение парсера арифметических выражений есть там в качестве пошагового примера.

Конкретно в случае статического внешнего класса можно сделать следующее:

Параметры в конструктор добавить по вкусу.

public static class MyClass
{
    private static Func<NestedClass> _nestedClassFactory;

    public static NestedClass New()
    {
        return _nestedClassFactory();
    }

    public sealed class NestedClass
    {
        private NestedClass()
        {

        }

        static NestedClass()
        {
            _nestedClassFactory = () => new NestedClass();
        }
    }
}

private static void configStep_addShortcutToStartupGroup()
{
using (ShellLink shortcut = new ShellLink())
{
    shortcut.Target = Application.ExecutablePath;
    shortcut.WorkingDirectory = Path.GetDirectoryName(Application.ExecutablePath);
    shortcut.Description = "My Shorcut Name Here";
    shortcut.DisplayMode = ShellLink.LinkDisplayMode.edmNormal;
    shortcut.Save(STARTUP_SHORTCUT_FILEPATH);
}
}

stackoverflow.com/questions/234231/creating-application-shortcut-in-a-directory

Вот, например, интересная ссылка на статью в КТ, где эксперты обсуждали вопрос.

Кодирование != шифрование, это, я думаю, вы и сами понимаете.

Кодирование — произвольное преобразование исходной информации в другой вид. Часто это делается для хранения/передачи данных. В таком случае прямое преобразование называют собственно кодированием, обратное — декодированием. Кодирование == преобразование (причем не обязательно обратимое, например mp3).

Шифрование — частный случай кодирования. При этом, в отличие от кодирования, фиксируется цель данного преобразования — предотвращение несанкционированного доступа. Ну и (наверно) шифрование обязательно обратимо.

По пунктам:
1) Да.
2) Как синоним — однозначно нет. Как более общее понятие — в принципе да, но по возможности лучше использовать наиболее специфический термин.
3) А можно ли кодировать сообщения при помощи DES? Можно. Но чтобы подчеркнуть цель такого кодирования — защита информации, лучше использовать слово «шифровать».

С помощью base64 можно как кодировать информацию (так делают в email), так и шифровать (правда этот способ шифрования не слишком надёжен), в зависимости от цели применения.

Некоторые программы «шифруют» пароли пользователя, причём могут делать это даже без использования мастер-пароля, например браузеры. Несмотря на то, что тут нет ключа (мастер пароля) — этот процесс называют шифрованием, из-за его семантики.

У Шнайера этот вопрос хорошо освящен (стр 296 «Прикладной криптографии» — pdf легкой найти). Генерируете случайное p. Сначала проверяете p на четность (по младшему биту). Затем проверяете остаток от деления на 3,5,7,… — первые простые числа кроме 2, меньше 2000. Затем прогоняете 5 тестов Рабина-Миллера (google) для 5 разных случайных чисел a. Если прошел все 5 — можно считать число простым. В целях эффективности можно генерировать небольшие a.

Еще, возможно, вас заинтересует статья об эллиптических кривых — http://eax.me/elliptic-curves-crypto/. Криптография на ЭК не менее безопасна, чем RSA, но существенно проще в реализации и более эффективна благодаря тому, что ключи длиной 256 бит так же надежны, как RSA ключи длиной 4096 бит.