Станислав Макаров

ideone.com/HLeMY2

#include <algorithm>
#include <iostream>

class one
{
public:
	one(std::string a) : _a(a) { }
	std::string a() { return _a; }
private:
	std::string _a;
	int b;
	bool c;
};

int main() {
	const std::vector<one> ones = {
		one("Vasya"),
		one("Meh"),
		one("Foo"),
		one("Vasya"),
		one("Vasya"),
		one("Bar")
	};
	std::cout << std::count_if(
			ones.cbegin(), ones.cend(),
			[](one o){ return o.a() == "Vasya"; }
		);
	return 0;
}

Если есть вопросы - задавайте

Вам нужно организовать темпоральную таблицу из таблицы клиентов. Если очень коротко, то смысл такой таблицы в том, что каждая запись у вас может хранить не только актуальные в ДАННЫЙ момент факты (как это происходит в обычной таблице), а еще и те, которые были актуальны в какой-то промежуток времени ранее (или даже те, которые БУДУТ актуальны позже). Сейчас очень неплохая темпоральная модель предлагается в свежем стандарте SQL:2011. К сожалению, сейчас далеко не все СУБД внедрили поддержку этого стандарта (сейчас поддерживают Oracle и DB2), но вы можете использовать саму идею, и реализовать логику через триггеры или на уровне приложения. Эта идея в том или ином виде повторяется в большинстве "велосипедов", связанных с историей данных в реляционных базах.

SelectedRows - это коллекция DataGridViewSelectedRowCollection, а она реализует только не-generic IEnumerable, который при перечислении возвращает System::Object-ы. Поэтому делайте for each (System::Object^ item in dataGridView->SelectedRows) и затем кастуйте к строке явно.

> Четкого формата таблиц нет.
Значит реляционная модель как таковая вам не подходит. Тут есть два варианта:
1) Entity-Attribute-Value (возможно это вы и имели в виду под "Сохранять каждую ячейку по отдельности", ну тогда решать вам. Работать будет разумеется медленнее, чем нормальная таблица, но у вас же нет схемы, ничего не поделаешь)
2) JSON/XML. Тут уж либо поля типа XML, либо привет документно-ориентированная СУБД.

Второй вариант годится, если выборки внутри таблицы не нужны или нужны редко (раз уж вы заговорили про CSV). Если нужны часто - то тогда EAV самое оно.

Про соответствие вариантов ответа не очень понятно, поподробнее пожалуйста.
Про один из нескольких или письменный - можно попробовать так: если у вопроса в базе указан только один (!) вариант ответа, то тогда он же - правильный, и тогда по определению нет смысла показывать ответ пользователю - значит вопрос письменный. Если у вопроса в базе несколько вариантов ответа, то имеет смысл показать их пользователю, что он выбрал, тогда вопрос на выбор правильных вариантов.
Ну или действительно ставить у вопроса тип, и каждый тип обрабатывать по-разному, тем более у вас там вопросы с левыми-правыми колонками, которые не похожи на предыдущие типы.

Community-редакция DotFuscator. Вам поддержка MSBuild на каком уровне нужна? EXE-шник всегда можно вызвать, а вот есть ли сборки с msbuild-тасками - не могу сказать.

А что же вам конкретно не понятно? Папку можно преобразовать в бранч, что вам и нужно сделать сначала с основной веткой, а затем для каждого релиза делать отдельную ветвь от основной. Стратегии разные есть, по ссылкам что вы дали это написано все. Вам нужно текущее содержимое проекта переместить в одну папку, например Master или Main и преобразовать ее в ветвь.
Да, кстати, зачем вам packages в репозитории? Автоматическим восстановлением не пользуетесь?