pletinsky

В классике по ООП нет примеров на c#.
В классике по c# и .net нет ООП.

Читайте по отдельности и будет вам счастье. По первому Страуструп, GOFF, Роберт Мартин.
По второму Рихтер и мсдн.

Хотя я бы конечно просто интернеты почитал и написал бы какую нибудь программу опираясь на гугл.

Все верно сказано в предыдущем ответе.
Ваша проблема не должна возникнуть — скорее всего это лишь запах настоящих проблем — проблем высокоуровневой архитектуры и системы деплоя.
И эти проблемы обязательно всплывут еще — ваши костыли вас не спасут.

Делайте как все нормальные люди — оперируйте классами и неймспейсами а не файлами и выносите общие части в отдельный проект.

Если по ходу придется решать какие то серьезные проблемы приложения — решайте их.
В частности если сборка используется в других программах — зафиксируйте ее внешний интерфейс как фасад и поменяйте внутреннюю реализацию на вызов кода из других сборок. Будет лишний повод покрыть тестами.
Или разберитесь с системой деплоя этой сборки в данные приложения.

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

Подробная инструкция.

Все верно. В случае WinForms мы управляем общей схемой расположения элементов и свойств их, но рисует злементы сам виндовс и многими вещами мы не можем управлять. И разные виндовсы могут рисовать их по разному.

Приложение заточенное под Windows XP (классический стиль) будет выглядеть убого в Windows 7 с аеро стилем. Так же и аеро стилю (Windows 7) нечего делать в метро стиле (Windows 8). Именно это и круто, что нам не приходится явно затачивать каждое приложение на специфический юай операционной системы.

WPF приложения тоже могу выглядеть по разному в разных операционных системах, но предоставляют больше возможностей управления стилями.

По второму вопросу InitializeComponent это часть работы по инициализации окна в WindowsForms. Отключат ее нельзя — иначе контролы в окне не будут проинициализированы.

Непонятно зачем вы хотите привести к одному внешнему виду. В двух разных виндовсах совершенно разные внешние стили. Они зачены под весь остальной дизайн операционной системы. Если даже это и можно как сделать (хотя врятли), делать этого не следует. Вам же под Android не придет в голову пытаться сделать точно такой же календарь. Выкиньте из головы эту ересь.

Вот по Asp.net Mvc 3.0 книженция.
Вот тут про asp.net 4.0 в принципе, включая asp.net mvc 4.0.

Простите, я понимаю что вы не хотите слышать таких ответов.

Но ей богу — забейте вы уже на книжки.

1) Ну на крайний случай выжимки с сайтов, где все коротко написано с типичными примерами.
2) Мсдн конечно — там уж точно уровень не английской литературы — написано все по простому в одном стиле. Пару дней с переводчиком даже если — привыкнете.
3) Ну и практика и поисковик. Застрял — погуглил — дальше делаешь.
4) Участие в проекте с опытными разработчиками — основа роста. Там вы будете писать код в общем стиле, используя тот подход который есть в остальном приложении. Там не будет стопперов, которые вы не сможете прогуглить. Работа в паре в идеальном варианте.

Ей богу — вовсе не книжки позволят расти в профессиональном плане быстро. Да — матчасть важна — но на более высоком уровне чем изучение того, как работать с конкретными фреймворками.
Если совсем плохо с английским можно использовать книжку как справочник в реальном времени на проекте, но возможно хватит и электронного варианта.

Во первых Вас следует разобраться что вообще такое модульные тесты. Как правило если речь о классическим модульных тестов в рамках TDD — то это тесты на методы класса в полном отрыве от внешнего окружения. Это значит что не только данные из базы там не могут оказаться, а вообще не должно быть каких либо вызовов за пределы класса. Все мокируется. Как правило TDD (если его умеют готовить) ускоряет написание кода (хотя вы можете услышать и иное мнение — но оно неверно). И имеет массу полезных побочных эффектов, но недешево в поддержке (хотя окупается за счет большей стабильности системы).
Такие тесты требуют архитектурной готовности системы. Например ваши бизнес энтити из базы должны реализовывать какой то интерфейс для мокирования. Чаще всего юнит тесты не окупятся на уже написанном проекте.

Поймите, чего вы хотите добиться. Если Вам нужна стабильность работы каких то определенных «злых» модулей программы пишите интеграционные тесты.
Если вы хотите добиться стабильности системы по отношению к требованиям — пишите системные тесты, которые работают с приложением как с черным ящиком. Есть много наработок в этой области в рамках BDD подхода.
Если у вам не формализованы требования — первым делом этим и займитесь — иначе никакие тесты вам не помогут.

Технология под дот нет называется asp.net, а не asp. Asp -технология тоже существует и она другая.

На мой взгляд если будете использовать современный подходы к разработке под .net (asp.net mvc 3.0-4.0), то стоимость разработки сайта будет существенно ниже, чем при использовании java.
Это результат и очень развитых инструментальных средств и очень развитого языка программирования.
Все эти средства вы можете получить бесплатно по системе поддержки стартапов или студентов.

Вам не понадобится ничего кроме MS Visual Studio на вашем этапе. Когда сайт будет создан — захостите бесплатно (первый год) например на амазоне. Есть и другие варианты.

Изучали следующие решения?

RESX Synchronizer.
Zeta Resource Editor
resx-localization-studio
Resharper для локализации.