eRKa

Я, думаю, Вы что-то не так поняли. Массив, это ссылочный тип и в случае
var a = new int[1] {5}
значение переменной a будет лежать в стеке, но значением будет ссылка на место в куче, указывающая на массив интов. Тоже самое касается и
a = new object[1] {5}

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

int a = 5;
var b = (object)a;

В первой строке мы положили в стек пятерку, а во второй эту пятерку мы помещаем в кучу. Переменная b будет лежать в стеке, значение которой будет указывать на адрес в куче, где лежит тип object, со значением value равным 5. И то, что у объекта поле будет интовое, не означает, что оно будет в стеке.

Юзают, нужная фича.
Первое, например тот же select. Толи его руками заполнять каждый option, толи в одну строчку вложиться.
Второе, это все-таки какая-то типизация разметки данными. Чем меньше твоей ответственности в заполнении разметки данными, тем меньше шансов на ошибку, особенно при последующих изменениях. Поэтому в нужном случае я даже для<a>буду использовать asp тег.

Если просто начать, понять принцип - не большая. Если писать проект - большая. Для изучения стоит смотреть минимум на MVC 5. Но я бы посоветовал сразу asp core.

Подключаться надо не к существующей таблице, а к существующей бд. Для этого надо в файле web.config указать в conectionstring путь к бд и соответствующий ей логин/пароль. Если conectionString укажете правильно, то будет соединение с ней. Только еще учтите, что все модели-сущности у Вас должны быть заранее реализованы под эту бд и соответствовать ее схеме.

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

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

Лучше никак не добавлять, а иметь один, разделяемый обеими программами, ресурс. Как вариант - общий файлик с данными.
Но если, все-таки, есть реальная необходимость извратиться и если говорить о windows forms, то у него есть файл ресурсов, который хранить свои данные в xml и который обычно используют как конфигурационный для запуска приложения, например для локализации приложения. Вот если Вы сможете получить доступ к этому файлу из другого приложения, то сможете его прочитать и подкорректировать как Вам нужно, сцылка. Примеров на C# как читать xml и как в него писать, в инете полно.

1. Не верно. Вы будете использовать GetWorkers, но тестировать AddWorker. На GetWorkers можете написать отдельный тест.

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

Самый нормальный способ перемешать, это в готовом массиве в цикле брать порядковый элемент и менять его местами с рандомным. Зачем Вам головняк с двойным циклом?

var rnd = new Random();
var arr = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 ];
for(var i; i < arr.Length; i++)
{
	var newPosition = rnd.Next(arr.Length);
	var temp = arr[newPosition];
	arr[newPosition] = arr[i];
	arr[i] = temp;
}

PS: А для того, чтобы понять что в массиве есть такое число или нет, можно применить linq
t_numbers.Any(x => x == number)
И никогда не делайте эту штуку внутри метода
Random random = new Random();
Это угрожает созданием одинаковых последовательностей. Объект Random должен быть полем класса, причем статическим.

Я пользуюсь такой конструкцией, проверенной временем

public class Singleton<T> where T : class
{
	private static readonly Lazy<T> _instance = new Lazy<T>(() => (T)typeof(T).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, new Type[0], null).Invoke(null), true);

	public static T Instance => _instance.Value;
}

public sealed class CustomSingleton : Singleton<CustomSingleton>
{
}

var single = CustomSingleton.Instance

Можно слегка извратится и сделать индексатор. Что-то подобие этого

public class Pixel
{
	public int X {get;set}
	public int Y {get;set}
	public string Text {get;set}	
}

public class LPixels
{
	public List<Pixel> ListPixels = new List<Pixel>();
  
	public Pixel this[int x, int y]
	{
		get
		{
			return ListPixels.FirstOrDefault(px => px.X == x && px.Y == y);
		}
		set
		{
			var point = ListPixels.FirstOrDefault(px => px.X == x && px.Y == y);
			if(point != null)
			{
				point.Text = value.Text;
			}
			else
			{
				var newPoint = new Point
				{
					X = x;
					Y = y;
					Text = value.Text;
				}
				
				ListPixels.Add(newPoint);
			}			
		}
	}
}

var lpixels = new LPixels();
var result = lpixels[1, 2];
lpixels[1, 2] = new Point { Text = "Test" };

How to Sort a List<> by a Integer stored in the st...

Потому, что синтаксис языка C# этого не разрешает.

Может потому что Вы х не сравниваете с 1, а присваиваете единицу иксу?

Все правильно, он и будет возвращать undefined. Я думаю, что Вы не верно трактуете выполнение setTimout(). Вот в этом участке

else {
    setTimeout(function() {
      opacity -= 0.1;
      console.log(opacity);
      return userFadeout2(el,delay,opacity.toFixed(1));
    },delay);
  }

не будет ожидания выполнения setTimeout, он создаст отложенное выполнение и вернет undefined, т.к. другого ничего не указано. Дальше setTimeout запустит Вашу функцию userFadeout2, но она так же, если opacity будет не равно 0, вернет undefined.
Лень проверять, но кажется setTimeout возвращает delay и Ваш return userFadeout2 не сработает как Вы хотите. Вам нужно сделать что-то подобие

else {
	$.when(setTimeout(function() {
		  console.log("pause");
		},delay)
	).then(function(){
		opacity -= 0.1;
		console.log(opacity);
		userFadeout2(el,delay,opacity.toFixed(1));
	});
}

Это без проверок с ходу, как пример, думаю мысль уловите.

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

Против:
1. Тесты это такая же кодовая часть проекта, на нее тратятся ресурсы (человеко-часы), а их нужно поддерживать так же как и остальную часть кода. Часто думают, что тест один раз написал и о нем можно забыть, но намного чаще приходят изменения, которые могут менять логику ожидания какого то поведения, может происходить рефакторинг, который так же может ломать тесты или делать какие то тесты ненужными или требовать новые и т.д. Если будете бояться сломать тесты, то и код перестанет быть гибким к изменениям.
2. Часто по неопытности стараются покрыть чуть ли не все 100% кода, получается избыточность, тесты на очевидные вещи. А это все время, а значит деньги.
3. Есть проекты, у которых срок жизни небольшой, пишется под конкретную одноразовую порцию задач. На них, я считаю, вообще нет смысла писать тесты.

Тесты имеет смысл делать:
1. Когда проект собирается жить долго и счастливо, и придет не одна порция изменений.
2. Над проектом работает не 1-2 человека, надо следить, чтоб кто-то другой не сломал то, что ты написал.
3. Во время разработки иногда удобнее написать тест на какой-то участок кода и запускать код для дебага через тест, чем каждый раз запускать тяжеловесный проект.