Oxoron

без опыта консоли, игру не создашь :)
p.s. всегда тестирую всякие штучки в консольке...
например выборка бд, парсинг json, заполнение коллекции и т д

Во-первых, не нужно пересоздавать список в цикле. Вы уже создали список в начале метода - вот его и используйте, иначе в каждом найденном элементе xml-документа затираются ранее найденные элементы (разве что вы так и хотите сделать, и то - лучше сделать это по другому). Уберите list = new List(); в цикле.

Во-вторых, вы уверены, что "Ссылка на объект не указывает на экземпляр объекта" - проблема с DbConf[0], а не с logger? Или, скорее, проблема в самом методе. Например, в n.SelectSingleNode("server").InnerText - и правда есть элемент "server"?. Потому что этот код метода выглядит как правильный.
Поставьте брейкпоинт в метод, и посмотрите по шагам, где именно возникает исключение.

Ну и в-третьих, названия методов принято называть, начиная с глагола. Метод (функция) - это действие с данным, а не данные. Назовите метод ReadXml().

UPD.

но как мне обратиться из любого места программы к данным?

Сколько у вас конфигов? Больше одного? ведь у вас список, значит, нужно выбирать конкретный конфиг:

var configs = DbConfig.GetDbConf();
Console.WriteLine("{0} {1}", c[0].Server, c[0].Port);

А если вы знаете имя сервера, то используйте словарь вместо списка:

public static Dictionary<string, DbConf> GetDbConf()
{
	try
	{
		var configs = new Dictionary<string, DbConf>();
		
		// ...

		foreach (XmlNode n in xml.SelectNodes(Properties.Settings.Default.setting_node))
		{
			string server = n.SelectSingleNode("server").InnerText;
			configs.Add(server, new DbConf
			{
				Server = server,
				Port = n.SelectSingleNode("port").InnerText,
				User = n.SelectSingleNode("user_id").InnerText,
				Pass = n.SelectSingleNode("password").InnerText,
				Db = n.SelectSingleNode("database").InnerText
			});
		};
		return list;
	}
	catch (Exception msg)
	{
		logger.Debug(msg);
		return null;
	}
}

var configs = DbConfig.GetDbConf();
var serverName = "localhost";
var config = configs[serverName];
Console.WriteLine("{0} {1}", config.Server, config.Port);

И сделайте в классе более типизированные поля - Port и User можно сделать int (тогда уж не User, а UserId).

Можете так попробовать.

public class SceneObject 
{
    //.....
    
    public void AddComponent<ComponentType>(Func<SceneObject, ComponentType> inst) where ComponentType : Component
    {
        components.Add(inst(this));
    }
    
    public static void Main(string[] args)
    {
        SceneObject sObj = new SceneObject();
        sObj.AddComponent((a) => new Component(a) );
      
    }
}

Наверное вам подойдёт простой FTP сервер (TFTP).
В сети есть много примеров реализаций:
https://tftp4net.codeplex.com/
sourceforge.net/projects/ctftpclient
www.codeproject.com/Articles/19314/A-simple-TFTP-c...

Судя по разным именам машины с TFS (ASDU789) и домена, из которого вы хотите взять пользователя (ASDU111) я предположу, что вы пытаетесь добавить в TFS локального пользователя другой машины. Это невозможно, т.к. TFS-сервер просто не знает про локальных пользователей машины ASDU111. Чтобы решить эту проблему, вам нужно либо развернуть Active Directory (которого у вас видимо нет), что удобнее, но требует нужной серверной редакции Windows, либо просто продублировать всех локальных пользователей рабочих станций на сервер: тогда у вас вместо ASDU111\fgh будет ASDU789\fgh и так для всех - у вас просто будет локальный пользователь НА СЕРВЕРЕ помимо такого же на рабочей станции.

Важно понимать, что это именно дублирование пользователя - например, смена пароля для fgh на сервере TFS никак не отразится на пароле локального пользователя. Собсно, чтобы этого не было, службы каталогов и придумали.

Типовая карьерная лестница архитектора:

Солюшн архитектор это почти топовая не-менеджерская должность. Если у вас такие вопросы, то вам еще лет 10 до него работать. Он должен знать всё, уметь всё и прочее. Он может не кодить, но должен предугадать все возможные косяки и костыли.

Чётность в теории чисел — характеристика целого числа

(Википедия)

> с более поздней версией
ну тогда уж с более ранней

> Проверяю версию добавляемой библиотеки перед тем как добавить
Добавляете из какого списка? Browse?

Откройте папку со сборкой в проводнике и проверьте в свойствах версию. Если там будет 2.0.0.0, то студия не при чем.

Кстати, а в NuGet этой либы нету?

Рискну предположить, что до лампочки ей ваш код. Цель расспросов - показать интерес к вашей деятельности. Не обязательно посвящать в суть дела, просто показывайте, что цените её интерес.

Работай иди.

Oxoron ну что тут сказать навскидку...
Я всегда считал .net допиленной java-платформой. Не то, чтобы в дотнете прям нереальные невероятные новшества, но все же некоторые вещи были обдуманы еще раз. Например, очень важным считаю разделение на reference и value типы. Правда, ИМХО, MS не довела идею до победного конца (слишком много технических вопросов нужно учитывать при выборе struct vs class), но все равно шаг очень правильный.
Плюс, считаю важным отсутствие корреляции между логическим структурированием библиотек (по неймспейсам) и физическим (по сборкам). На каждом уровне должны приниматься отдельные решения насчет того, что куда класть.
Еще одним преимуществом (нивелированным на данный момент) была изначальная ориентация .net на мультиязычную поддержку. Сейчас конечно JVM-языков навалом, но раньше это все-таки смотрелось киллер-фичей .net. Особенно поддержка "склеивающих" языков, таких как C++/CLI, которые позволяли интегрировать уже существующие компоненты с .net-приложениями. Дотнет изначально не был платформой в себе, разработчикам давали массу инструментов для интеграцией с COM и native-кодом. Ну и само собой managed-языки в приличном количестве, вон F# уже довольно давно подтянулся как официально (!!) поддерживаемый.

А вообще конечно изначальным преимуществом .net были именно языки. Я думаю даже самые ярые джависты со мной согласятся, что с момента выпуска C#, язык Java развивается догоняющим образом. Можно опять сказать, что есть Scala, но тогда нужно учесть, что C# изначально был визитной карточкой платформы с момента ее появления. Ну и самое главное - инструменты. В мире Java достаточно хороших IDE, но уровень взаимоподдержки Студии и .net насколько мне известно пока не достигнут.

И тут мы выходим на стандартное основное преимущество решений от MS - максимальная "готовность" и интеграция продуктов. К сожалению последние года 3 в Джаву не совался, но знакомые не раз говорили, что с отсутствием знаний об обеих платформах им гораздо легче было поднять hello-world веб-сайт (!) на asp.net в студии, нежели на том же Spring. Так или иначе, это фактор.

Теперь библиотеки. Конечно, в мире джава их огромное количество. Я думаю и сегодня их значительно больше, чем в дотнет. Две либы в моем текущем проекте - NHibernate и NetTopologySuite - это порты с джавовских либ. Джава рулит на сервере. Про..аная Майкрософтом настоящая кроссплатформенность .net не давала ему потеснить джаву. Сейчас конечно это усиленно исправляется - в дотнете уже наступило перерождение после массовых релизов в open-source, переделанного asp.net, и появления DNX. По сути теперь .net официально поддерживается на *nix - системах. Это конечно надо было сделать намного раньше, но и сейчас этому рады.
NuGet прекрасно справляется со своими задачами, более тесная интеграция в билд-процесс в DNX только улучшит процесс взаимодействия с ним.

Ну и последнее - разработка UI. Все что есть в Java-мире (JavaFX, Java3D, Swing) это совсем не то. Windows Forms был отличным аналогом Дельфийских компонентов для UI, WPF в свое время вышиб немало дверей своим появлением. Если б он еще и развивался как подобает... Да, конечно, на джавовских технологиях вы напишите кроссплатформенную вещь, но она будет одинаково чужеродно смотреться и на винде, и в линуксовых desktop-средах. А людям в enterprise не особо нужна кроссплатформенность в UI - им намного важнее аккуратный привычный интерфейс, в том числе на Винде. Сейчас WPF может потеснить только современный Qt. Выбирая сегодня UI для десктопа, я бы выбирал между WPF и Qt, про джаву бы даже не подумал (да, я считаю что сегодня далеко не все можно и нужно пихать в браузер на тормозной JS. Весь новомодный неповоротливый софт, написанный с использованием Atom-а, меня удручает).
ПРАВКА: посмотрел последние демки по JavaFX. В общем-то неплохо, осталось только дождаться хорошего роста коммьюнити и надеяться что не будет проблем с производительностью в сложных приложениях.

Сколько тут преимуществ в штуках, посчитайте сами. Самый главный вывод - мало у кого возникает желание переходить на другую платформу просто потому, что обе сейчас очень хорошо развиты, и в обоих есть что поизучать, в обоих есть клиент и сервер, куча библиотек. Изучив один стек, никто не будет тратить время на другой, в этом просто нет смысла. Если кто-то и переучивается, то ради хорошей зарплаты: в банках и прочих страховых джава чуть популярнее, и за нее больше платят, процентов на 20.

P.S. Да, тут кстати пишут что игродельство на C# достигло серьезного уровня. Я 3d делал и делаю на C++, поэтому тут пусть кто-нибудь другой прокомментирует.