Снача почтовик берет MX запись, если почта не проходит, то использует А запись. То есть, при любых ошибках удаленный почтовик будет юзать А запись.
потому что нашими серверами нельзя пользоваться для разрешения IP яндекса, это сделано для того, чтобы те, кто зачем-то прописал их себе на компьютер, увидели бы проблему быстро, т.к. у них бы ни яндекс ни гугль бы не работал они не для этого и про Яндекс спрашивать их не надо
Как хранить неопределенное количество товаров
1) Split не подойдёт тут.
using System;
class SplitDemo {
static void Main() {
var src = "{\"Mesmes\":khdfskhfkjshadfjh{}ds{jaf8674535}234}{\"Mesmes\":hhTTY7{864938}523_{}jhg{dfsRRRRRRR}}";
var parts = src.Split(new string[] { "{\"Mesmes\":" }, StringSplitOptions.None);
foreach(var part in parts)
{
Console.WriteLine(part);
}
}
}khdfskhfkjshadfjh{}ds{jaf8674535}234}
hhTTY7{864938}523_{}jhg{dfsRRRRRRR}}назови хоть одну задачу, где на самом деле нужно получить путь к запущенной сборке, а не путь к папке с конфигом или к папке, куда установлено приложение.
А действительно ли нужен именно путь к исполняемому файлу?
Но суть не в этом. Есть такая парадигма - Test Driven Development. Огромное количество книг и материалов написано, можете погуглить. Однако, она накладывает определённые ограничения и требования. Самое главное требование - сделать ваш код тестируемым. Юнит-тест - это проверка некоторого условия, AAA - Arrange, Act, Assert. Подготовка, действие, проверка, если хотите.
Иными словами, вы должны написать программу, которая проверит, как работает ваш код. При этом для нужд тестирования вы не должны никаким образом ничего добавлять или иным образом модифицировать код бизнес-логики. Все операции по тестированию должны проводиться извне, как с "чёрным ящиком". Человек, который пишет юнит-тест вообще не должен знать, что там внутри у вашего метода понаписано.
Соответственно, ваш код должен быть представлен в виде методов, которые что-то берут на вход и что-то выдают в качестве результата (либо бросают исключение - на это тоже можно тестировать).
Ваш код инкапсулировал программную логику так, что протестировать что-либо извне без модификации методов изнутри не представляется возможным.
Пусть, мой пример не отвечает требованиям задания, зато он гораздо лучше приспособлен для юнит-тестов.
И последнее - для TDD (Test Driven Development) лучше всего подходить к разработке "Test First". Сначала тесты, потом код. Сначала вы пишете набор тестов, исполнение которых гарантирует вам правильную работу программы, а уж затем вы пишете код так, чтобы эти тесты выполнялись.