Николай Мохов

Развернутый ответ на ваш вопрос, как обычно, уже есть на StackOverflow. stackoverflow.com/questions/151005/create-excel-xl... Успехов!

Тут смотрели?

Теоретически, раз вы создаете форму в том же потоке, в которым с ней работаете - то все нормально, другой вопрос - зачем это делать и чего вы этим добиваетесь. В 98% GUI-приложений весь интерфейс находится в одном потоке и все работает замечательно (если открывается модальное окошко или диалог, оно просто крутит свой собственный цикл сообщений), а вот как раз другие потоки нужны для проведения длительных вычислений и операций ввода-вывода, чтобы GUI-поток не останавливался и мог спокойно и дальше ловить мессаджи от операционки на перерисовку и пользовательские действия. Так что если это не эксперимент в вакууме, то нужно основательно подумать, зачем вам такие финты - управлять несколькими гуевыми потоками нужно очень аккуратно.

Сервис всегда работает - т.е. тратит чуть-чуть процессора и достаточно оперативной памяти. Если задача запускается раз в час и отрабатывает за минуту, то windows сервис явно излишен. Консольное приложение запускаемое по расписанию - самое то. График устанавливается через графический интерфейс Windows Scheduler, либо в случае очень нестандартного алгоритма запуска встраиванием Quartz.Net .Уведомление удобнее всего сделать в самой программе через NLog или что-то подобное. Функцию main обернуть в try/catch и в catch отправлять письмо опять же через NLog администратору об ошибке выполнения задачи.

Консольное приложение проще обновлять через FTP. Windows-сервис необходимо вначале остановить (что требует захода на сервер через удаленный рабочий стол), затем перезалить .exe, затем снова запустить сервис. Вероятнее всего, существуют средства автоматизации, но не в стандартной поставке Windows Server.

Также запуск через планировщик гарантирует на 100%, что приложение продолжит запускаться после перезагрузки сервера. С windows-сервисами были ситуации, когда сервис не стартовал, хотя в настройках был указан автозапуск.

Сейчас практически все проекты масштабом от среднего и выше выполняются отдельными командами backend и frontend разработки, так что не вижу проблем, просто ищите вакансии как backend специалист, а не как fullstack.
Работы такого рода огромное количество, просто она уровнем выше лежит, чем индусские объявления вида "I need a copy of website...".
Если у вас проблемы с поиском бекенд работы на фрилансе, что странно, то попробуйте либо устроиться в компанию на удаленке, либо поработать несколько месяцев в офисе, а потом попроситься на удаленку, в нормальных компаниях никогда бекенд специалиста не заставят в css ковыряться.
Если же вы вообще не любите веб, даже с серверной стороны, то все печально, desktop направление на фрилансе практически мертво.

Потому что контекст переключается по таймеру. Thread.Sleep(n) усыпляет поток на не менее чем n мс.
И да, гугл поможет.

Ну вот толковые в принципе ответы на SO: stackoverflow.com/questions/4279185/what-is-the-us..., посмотрите, и скажите что конкретно непонятно.

Работаю в Штутгарте UI/UX Interactiv Designer (живу в Германии уже 13 лет), на работу приняли даже не спросили где учился, и без аттестата. Просто показал им свои работы.
Решающим стал один проект, который я показал - приложение для андроид которое я оформил и создал рабочий прототип, а так же тот факт что я много в чём ещё умею и пробовал работать и с анимацией и 3д и печатал футболки и сайты делал и corporate identity и всё как бы на должном уровне с душой.

Но работу искал долго, скажу сразу... пару раз устраивался, через несколько месяцев сворачивался, полный ад...
По фрилансу работал нормально. Но уровень не тот, рост необходим, и проекты масштабные для известных брендов - это уже другое дело.

Думаю в профе дизайнерской/программерской, определяющим являются сами работы и клиенты/агенство для которых ты работал и только в меньшей степени образование.
Все эти бумажки скорее от лукавого, может и прибавят к зарплате 500 евро, но если тебе по способностям 1000 платят, то и толку с этого.

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

Сейчас, в эпоху онлайн-сервисов, даже десктопные приложения частично работают с веб-службами и прочими интернетами, так что некоторые серьезные производители ПО уже начинают забивать на защиту десктопного приложения, ограничиваясь только проверками на стороне сервера при работе с сетевым функционалом (ну не знаю, например заливка файла в облако). Конечно, это пока не для всех подходит, но имеет смысл с учетом того что не ломаются только малопопулярные приложения (т.к. не интересуют взломщиков), а любые нормальные клиенты будут покупать продукт (на Западе вообще другой менталитет, люди считают работу ПО не по лицензии таким же воровством, как и украденный кошелек). Код на C++ тоже вполне себе неплохо дизассемблится тем, у кого есть опыт. Да, исходник восстановить гораздо сложнее, даже невозможно, но это и не нужно - все ломается в каком-нибудь OllyDbg по ассемблерному коду.
Кстати, Word и Photoshop это скорее "коммерческое" ПО, энтерпрайзом обычно называют всякий внутренний софт (банковские системы, всякие автоматизаторы, генераторы отчетов), и там C# не просто используется, а конкрурирует только с джавой. WPF и прочие технологии как раз для такого софта и создавались. Если хотите примеры продаваемого ПО на шарпе: ну вот хотя бы Citavi - вполне серьезный софт для референс-менеджмента (управление библиографией и ссылками в научной деятельности). Все на шарпе, использует кучу библиотек, при этом вполне себе стоит денег.

Нашел такую штуку www.stimulsoft.com/ru

Может есть еще что? Или мануал как делать такое?

Тут зависит от деталей. В частности - надо ли это действие выполнять, даже если ни один пользователь не вошел в систему, или же вне контекста пользователя это бессмысленно. Если первое - тогда в общем-то лучше сервис, однако нужны дополнительные усилия, чтобы его устанавливать в систему, и, что еще важнее, из сервиса не стоит пытаться создавать окошки и вообще взаимодействовать с UI - это возможно, но сложно и требует доп. заморочек. Поэтому:
а) подумайте, выполняет ли ваше приложение какую-то глобальную задачу, не зависящую от пользователя (а-ля дефрагментация или, там, архивация). Если да, то:
б) оцените, возможно ли разбить ваше приложение на: собственно сервис, который будет выполнять полезную задачу; панель управления - обычное десктопное приложение, которое будет взаимодействовать с сервисом и менять его настройки и состояние;
в) оцените, есть ли у вас ресурсы (время/деньги), чтобы разбираться с дополнительными тонкостями (установка и запуск сервиса, особенности написания сервиса (в шарпе нужно наследоваться от библ. класса), взаимодействие UI управления и сервиса);
г) если пункты а, б, в истинны, то делайте в соответстии с ними, если хотя бы один ложный - сделайте лучше десктопное приложение.

Вообще на шарпе нормально пишутся сервисы, пробовал, разобраться можно за пару дней, включая простейшие скрипты установки.

Был подобный вопрос про книги на Тостере. Здесь мой развернутый ответ.
Если вкратце: ты выбрал правильные книги и правильный порядок. Разве что, Шилдта стоит поискать 5 издание, а Троелсена читать на английском - перевод ругают.
Кроме того, для работы вполне достаточно первой части Шилдта (до потоков).
Так же обрати внимание, что в этих книгах рассматривается, в основном, сам язык, его синтаксис. Помимо этого программист частенько занимается тестированием (как минимум модульным), проектированием, работой с системами контроля версий, работой с БД. В случае с .NET (C#) БД скорее всего лежит на MS SQL Server.

Так что после первой половины Шилдта рекомендую написать Unit-tests (модульные тесты) на один из своих проектов (в качестве литературы гугли Art of Unit Testing, для начала хватит первых нескольких глав), написать несколько модульных тестов с MS Fakes (Shims, Stubs), почитать про рефакторинг, например, тут, завести профиль на Гитхабе, закинуть туда один из своих проектов, сделать несколько коммитов. Для работы с БД используются либо родные классы .NET (C#), либо EntityFramework, NHibernate, etc.
Важно все перечисленное в этом абзаце выполнять после освоения первой части Шилдта. До этого у тебя скорее всего не будет проектов, для которых нужны подобные навыки.

.NET и C# в названиях подобных книг почти равнозначны. Если проводить (очень грубую) аналогию, платформа .NET - это ассемблер, в нем все кодируется байтами (ну, или ноликами и единичками). Так программировать неудобно. Поэтому есть несколько ЯП (C#, VB6, в некотором роде PowerShell), которые свой код переводят в байты .NET кода. Для начала можешь считать, что .NET и C# это одно и тоже, понимание разницы придет со временем (либо прочтением Троелсена).

Удачи.