Коллеги, подскажите, вот правильно ли я понимаю, что для запуска софта, написанного с использованием .net 4.5 (версия, выбранная в свойствах проекта), на компьютере тоже должен быть установлен .net 4.5? Или там есть какая-то возможность использовать 4.5 для сборки, но сделать сборку бинарно-совместимой с 4.0?
Есть кое-какой десктопный софт, в данный момент все исходники собираются под .net 4.0 Хочется переползти хотя бы на 4.5, но есть опасения, что у нас могут быть пользователи с Windows XP, а для XP 4.5 не доступен.
Здравствуйте, Artem Korneev, Вы писали:
AK>Коллеги, подскажите, вот правильно ли я понимаю, что для запуска софта, написанного с использованием .net 4.5 (версия, выбранная в свойствах проекта), на компьютере тоже должен быть установлен .net 4.5?
Да.
AK>Или там есть какая-то возможность использовать 4.5 для сборки, но сделать сборку бинарно-совместимой с 4.0?
Это как вы себе это представляете? Напишу код под 4.5, а запускаться он будет под 4.0? Если у вас нет необходимости в фичах 4.5 спокойно пишите на 4.0.
Здравствуйте, Artem Korneev, Вы писали:
AK>Коллеги, подскажите, вот правильно ли я понимаю, что для запуска софта, написанного с использованием .net 4.5 (версия, выбранная в свойствах проекта), на компьютере тоже должен быть установлен .net 4.5?
Да.
AK> Или там есть какая-то возможность использовать 4.5 для сборки, но сделать сборку бинарно-совместимой с 4.0?
Есть. Указать в свойствах проекта 4.0.
AK>Есть кое-какой десктопный софт, в данный момент все исходники собираются под .net 4.0 Хочется переползти хотя бы на 4.5, но есть опасения, что у нас могут быть пользователи с Windows XP, а для XP 4.5 не доступен.
Собирайте под оба фреймворка на сервере CI. Недостающие в 4.0 фичи 4.5 обычно можно сравнительно легко сэмулировать. См., к примеру, https://github.com/rsdn/CodeJam — там даже под 3.5 версия есть, хоть и в несколько урезанном виде, но в свойствах проектов указан 4.5.2.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Doc, Вы писали:
Doc>Это как вы себе это представляете? Напишу код под 4.5, а запускаться он будет под 4.0?
Ну да. А почему нет?
Более новые версии компилятора вполне могут использовать уже существующие возможности виртуальной машины дотнета. Не знаю, как там сейчас дела, но вроде бы Java довольно долго поддерживала обратную совместимость с виртуальной машиной. Код, собранный новыми компиляторами был обратно совместим со старыми версиями JRE.
Doc> Если у вас нет необходимости в фичах 4.5 спокойно пишите на 4.0.
Ну это как бы очевидно. Вопрос был о том, насколько болезненным будет переход с 4.0 на 4.5 в плане обратной совместимости с десктопными операционками у пользователей.
Здравствуйте, Artem Korneev, Вы писали:
Doc>>Это как вы себе это представляете? Напишу код под 4.5, а запускаться он будет под 4.0? AK>Ну да. А почему нет?
А что будет, когда произодет обращение к коду .NET появившемуся в 4.5?
Здравствуйте, Artem Korneev, Вы писали:
AK>Более новые версии компилятора вполне могут использовать уже существующие возможности виртуальной машины дотнета.
А чтобы не использовать то, что не существует в более старых версиях рантайма как раз и предназначен выбор версии рантайма в свойствах проекта.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Doc, Вы писали:
Doc>А что будет, когда произодет обращение к коду .NET появившемуся в 4.5?
А такого не было бы в принципе. Я ж написал:
AK>> Более новые версии компилятора вполне могут использовать уже существующие возможности виртуальной машины дотнета.
Т.е. результат компилляции был бы полностью совместим, например, с рантаймом 4.0
В некоторых языках такая возможность есть — Java, как я уже говорил, вроде бы это поддерживает. JavaScript через дополнительные костыли — тоже. Но как мне тут уже ответили, в дотнете такого нет. А жаль. Ничего принципиально невозможного в этом нет, это можно реализовать кучей разных способов, но тут наверное решение чисто политическое — дотнет обновляется для всех поддерживаемых версий Windows, а неподдерживаемые, видимо, хотят побыстрее утилизировать чтоб перевести пользователей на новые версии.
Здравствуйте, Doc, Вы писали:
Doc>Тогда я не понимаю в чем профит от сборки 4.0 кода как 4.5. Поясните?
Два варианта:
1. Зависимые нюгет-пакеты бинарно несовместимы. Например, в версии под 4.5 в качестве параметра используется тип из фреймворка, в 4.0 такого типа нет, в сборку добавлена копия типа, но type forwarding не настроен. Тут надо пинать авторов, если никак — разные сборки под разные целевые платформы. На практике такое встречается крайне редко.
2. Речь не про отдельную сборку, а про приложение. Тогда см вот эту ссылку, @vorona выше приводил.
Здравствуйте, Sinix, Вы писали:
S>2. Речь не про отдельную сборку, а про приложение. Тогда см вот эту ссылку, @vorona выше приводил.
Если с первым ясно, то вот какой бенефит в (2)? Учитывая что по ссылке вообще сказано
Some compatibility best practices covered in this article include:
Don’t re-target existing projects to newer .NET Framework versions unless necessary. This will minimize compatibility issues by allowing the app to take advantage of compatibility quirks.
Здравствуйте, Doc, Вы писали:
Doc>Если с первым ясно, то вот какой бенефит в (2)? Учитывая что по ссылке вообще сказано Doc>или я что-то все же упустил?
Да не, всё верно. Профит может быть, если проект решено развивать дальше или что из зависимостей требуется обновить. Иначе смысла нет.
Здравствуйте, Doc, Вы писали:
Doc>Тогда я не понимаю в чем профит от сборки 4.0 кода как 4.5. Поясните?
Всё наоборот, я хотел проект на 4.5 сделать совместимым с 4.0, чтоб можно было запускать на вин ХР.
А причина простая. Есть проект, писанный на 4.0 Проект живой, развивается, пару месяцев назад наняли меня чтоб двигать всё это дело в облако. Я начал с внедрения Dependency Injection. Т.к. Unity (DI контейнер) требует .net 4.5 и выше, то и возник этот вопрос — можно ли оставить проект совместимым с 4.0
Независимо от этого, начальство решило что пришла пора обновляться до 4.6, так что вопрос сам по себе разрешился. Иначе пришлось бы брать другой DI контейнер, совместимый с 4.0
Здравствуйте, Artem Korneev, Вы писали:
AK>Т.к. Unity (DI контейнер) требует .net 4.5 и выше, то и возник этот вопрос — можно ли оставить проект совместимым с 4.0
С этого инадо было начинать, а не ребусы загадывать. Если он его требует, значит с очень большой вероятностью он использует фичи 4.5, а значит на 4.0 работать не будет. Используй версию 2.1, она на FW35 работает. Ну либо можно скачать исходники и посмотреть, можно ли его быстро сбекпортить на 4.0.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK> Используй версию 2.1, она на FW35 работает. Ну либо можно скачать исходники и посмотреть, можно ли его быстро сбекпортить на 4.0.
Ну я ж говорю, вопрос уже разрешился — шеф сказал, что все наши пользователи, как минимум, на Windows 7, а значит, можно использовать .net 4.6
Если б всё-таки понадобилось бы поддерживать XP и .net 4.0, то я просто взял бы другой DI-контейнер — вроде, StructureMap это поддерживает и ещё какие-то контейнеры. Нет большой нужды возиться со старыми версиями Unity или портировать что-то самому.
Здравствуйте, AndrewVK, Вы писали:
AK>>Почему? Удобно же. AVK>Чем? Тем что проверки компилятора заменяются рантайм проверками и здравствуй отладка?
Что и где заменяется?
Строгая типизация никуда не пропадает, да и вообще никак не соотносится с Dependency Injection.
DI работает через интерфейсы. Интерфейсы, в целом, вообще удобная штука сама по себе и полезна даже без DI. Когда класс реализует интерфейс, то компилятор делает все нужные проверки, никаких отличий от варианта без интерфейсов тут нет.
Единственное, что неудобно — когда в Visual Studio переходишь на реализацию метода, оно прыгает в определение интерфейса, а не в класс с реализацией.
Здравствуйте, Artem Korneev, Вы писали:
AK>Строгая типизация никуда не пропадает, да и вообще никак не соотносится с Dependency Injection.
Еще как соотносится. И механизм injection, и service locator, и регистрация реализаций — все это происходит в рантайме и проверено может быть только в рантайме, не смотря на наличие интерфейсов. Если оно так нужно вне зависимости от применения DI — ок, вопросов нет. Но чаще я вижу другое — никакой runtime магии до использования DI не было, несколько реализаций интерфейса в одно место не уперлись, все жестко связывалось компилятором.
