Я работаю над довольно большим проектом, и я собираюсь внедрить механизм автоматического обновления для него. Теперь каждый класс находится в одном проекте, а выход - это только один .exe-файл, и каждый раз, когда пользователю необходимо обновить приложение, ему необходимо загрузить новый .exe-файл.Как управлять проектами для будущих обновлений
Я думал, что было бы лучше отделить классы в разных проектах, чтобы строить разные сборки, и каждый раз и сборка изменяется, пользователю нужно скачать только тот.
Впоследствии я выясняю, что каждый раз, когда я перестраиваю конкретную сборку, мне нужно также перестроить проект запуска.
Теперь мне нужно знать, что лучше всего подходит для управления проектами решения C# для будущих обновлений.
Вы не _need_, чтобы перекомпилировать сборку, ссылающуюся на другую сборку, когда последнее изменяется, например, до тех пор, пока вы не измените членов, к которым вы уже имеете доступ. Прочитайте [окончательное руководство по изменениям API в .NET] (http://stackoverflow.com/questions/1456785/a-definitive-guide-to-api-breaking-changes-in-net). Для управления версиями вы можете использовать переадресацию сборки. Теперь, что именно вы спрашиваете? Как не перекомпилировать основной исполняемый файл? – CodeCaster
Да, как сказал @CodeCaster, это проблема согласованности API. Я не согласен с ClickOnce и почти всегда пишу собственные автообновления. – caesay
@CodeCaster, я каждый день перестраиваю все решение. иногда версия изменяется, но классы вообще не меняются. – user3530012