Хм ну да, если профиль был создан с ошибками то такое тоже возможно. Насчет поиска тут скорее имеет место быть несоответствие ожиданий — глупо было бы, если бы в пуске происходил поиск сразу по всей системе. А для обычного поиска вроде как всегда можно было использовать wildcards
Я слышал как-то что программы можно устанавливать как для конкретного пользователя, так и для всех пользователей. Соответственно программу, установленную для конкретного пользователя, в новом можно и не найти — т к ярлыки для него попросту не созданы. Справедливости ради не видел такого выбора для офиса, но и ваша ситуация она не про поиск, а про пуск в целом.
Самую малость неудобно, да, и как только нужно будет сделать что-то сложнее запуска программы (например, подложить отладочные файлы или собрать логи) опять придётся работать с файлами, только в виртуалке. А как удобно вести отладку в виртуалках, нет слов
Пуск уже давным-давно стал неюзабельным, проще и быстрее находить программы через поиск (Win+начало названия программы+Enter). Explorer (имхо) всегда был не очень (ещё и дырявым как дуршлаг), двухпанельные файловые менеджеры влёгкую его уделывают, поэтому в принципе пусть делают что хотят. Новое контекстное меню удобно только тем, кто на самом деле им не пользуется - для любого мало-мальски нужного действия +1 клик (или +1 комбинация клавиш). То что нельзя перетаскивать на таксбар, и уведомления, совмещённые с календарём - действительно спорное решение. В остальном ничего такого по сравнению с Windows 10, несколько дней назад поставил Windows 11 на рабочую машину, и разрабатываю абсолютно так же как и на Windows 10, ничего не поменялось.
К сожалению, методы winapi работают не только лишь с примитивными типами данных, такими, как byte, int, double. На самом деле очень часто они принимают на вход и возвращают как раз структуры, различной степени сложности (бывает такое что волосы дыбом встают, например, уведомления wlan api). Иногда нужно передать структуру по ссылке, чтобы метод что-то в ней изменил, или заполнил недостающие поля. В общем, с иммутабельностью это никак не вяжется, как бы вам этого ни хотелось. Не ваша область специализации, вот вы и делаете такие безапелляционные заявления, а сколько еще таких областей :)
Я вам про практику а вы мне про теорию, сами для начала попробуйте из directory.build.props подключить файл, формируемый таргетом позже — вот тогда и поговорим :)
Я вам говорю не про таргеты а про пропсы, они импортируются в самом начале и compile include определен там. Выполнить таргет с таской ранее этого момента невозможно.
Очень грубо говоря — система собирает все compile include и затем их компилирует. Если файл не существует — он пропускается. Или вы хотите сказать, что существует какая-то магия, позволяющая вмешаться в уже созданный список файлов для компилятора?
Вот не работает с BeforeTargets, перепробовали все. С GenerateAdditionalSources надо попробовать.
P.S. Точных деталей уже не помню, но кажется для Compile Include нужно чтобы файл уже существовал, и вот генерируется он после включения пропсов — т е билдить надо два раза, не комильфо.
Я заметьте ничего не имею против иммутабельных структур, но говорить, что это ошибка — заблуждение. Например, интероп с winapi ну иммутабельных структурах не построишь. Также я слышал, что в высоконагруженных участках кода разумная замена классов на структуры может снизить нагрузку на GC. Если задуматься — уверен, что найдутся и еще примеры.
Не думал, что это так сложно.
Вот у вас есть солюшен проектов на сто, из которого собирается продукт с большим количеством сборок. Вам бы хотелось, чтобы в каждой из них ассембли инфо было одинаковым, в частности версия. Есть несколько подходов для решения этой проблемы, один из них — создать для этого отдельный props-файл, который будет подключать какой-то файл типа GlobalAssemblyInfo.cs (или модные определения в sdk-style, не суть), и импортировать этот props-файл в Directory.build.props — так, чтобы каждый проект его получил. Пока все просто и понятно.
Теперь заметим, что держать версию прям в cs-файле неудобно, т к она бывает нужна и в других местах (CI например), поэтому версия сама по себе лежит где-то отдельно, откуда ее просто достать — в json, xml или даже plain-text — тоже не суть. По итогу ассембли инфо генерируется из шаблона подстановкой этой версии. Соответственно в системе контроля версий не участвует.
Теперь вы клонируете чистый репо, в котором еще ничего не сгенерировано. Сначала импортируются пропсы, потом выполняются таски при сборке. И на тот момент, когда нужна ассембли инфо — она еще не сгенерирована.
Попробуйте нажать Ctrl+Shift+F1, будете приятно удивлены
Самую малость неудобно, да, и как только нужно будет сделать что-то сложнее запуска программы (например, подложить отладочные файлы или собрать логи) опять придётся работать с файлами, только в виртуалке. А как удобно вести отладку в виртуалках, нет слов
Эх жаль разработку приложений под Windows до сих пор в онлайн не перенесли с драйверами и прочими прелестями
Пуск уже давным-давно стал неюзабельным, проще и быстрее находить программы через поиск (Win+начало названия программы+Enter). Explorer (имхо) всегда был не очень (ещё и дырявым как дуршлаг), двухпанельные файловые менеджеры влёгкую его уделывают, поэтому в принципе пусть делают что хотят. Новое контекстное меню удобно только тем, кто на самом деле им не пользуется - для любого мало-мальски нужного действия +1 клик (или +1 комбинация клавиш). То что нельзя перетаскивать на таксбар, и уведомления, совмещённые с календарём - действительно спорное решение. В остальном ничего такого по сравнению с Windows 10, несколько дней назад поставил Windows 11 на рабочую машину, и разрабатываю абсолютно так же как и на Windows 10, ничего не поменялось.
Жаль, но, конечно, это можно понять
Вот бы MS договорились с разработчиками paint.net, чтобы включить его в поставку системы...
P.S. Точных деталей уже не помню, но кажется для Compile Include нужно чтобы файл уже существовал, и вот генерируется он после включения пропсов — т е билдить надо два раза, не комильфо.
Вот у вас есть солюшен проектов на сто, из которого собирается продукт с большим количеством сборок. Вам бы хотелось, чтобы в каждой из них ассембли инфо было одинаковым, в частности версия. Есть несколько подходов для решения этой проблемы, один из них — создать для этого отдельный props-файл, который будет подключать какой-то файл типа GlobalAssemblyInfo.cs (или модные определения в sdk-style, не суть), и импортировать этот props-файл в Directory.build.props — так, чтобы каждый проект его получил. Пока все просто и понятно.
Теперь заметим, что держать версию прям в cs-файле неудобно, т к она бывает нужна и в других местах (CI например), поэтому версия сама по себе лежит где-то отдельно, откуда ее просто достать — в json, xml или даже plain-text — тоже не суть. По итогу ассембли инфо генерируется из шаблона подстановкой этой версии. Соответственно в системе контроля версий не участвует.
Теперь вы клонируете чистый репо, в котором еще ничего не сгенерировано. Сначала импортируются пропсы, потом выполняются таски при сборке. И на тот момент, когда нужна ассембли инфо — она еще не сгенерирована.
А как же .kkrieger