• Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +2
    кому нужны все эти Grid.SharedSizeGroup и MarkupExtension

    Нужны при разработке чего-то более сложного, чем приложение для доставки пиццы. Свои markup extensions даже в Xamarin.Forms есть.


    В WPF завезли нормальную поддержку DPI и UI Адаптивный под разные инструменты ввода

    DPI всегда вполне вменяемо поддерживался. В 4.6.2 прикрутили поддержку per-monitor DPI. С DPI проблемы были не в WPF, а в винформах, ибо винформы базируются на технологиях из 90-х


    пуш уведомления
    пакетная упаковка приложений (аля мак ос).

    Делается через desktop bridge, к технологии отображения окон на экран отношения не имеет.

  • Почему я до сих пор не занимаюсь опенсорсом
    +2
    While the functionality you propose is definitely interesting, we feel that it's beyond the scope of our project and thus would be more useful as a separate library

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

  • Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов
    +2

    А у них там какой-нибудь свой не менее толстый nuget.org. Мелких пакетов для "раскраски консоли", правда, нет, так что граф зависимостей обычно поменьше и читаем. Но от проблемы выше не избавляет.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +1

    Grid.SharedSizeGroup завезли уже? А свои MarkupExtension уже можно делать? Уже сколько лет технологии, а даже таких базовых вещей нет.


    А WinRT-only-фичи — это какое-нибудь живое обновление плиток, которое нужно мессенджерам и приложениям по доставке пиццы.

  • 31 февраля
    –1
    секунда равная 61

    Вы не поверите, но это 62-ая. Они на часах с нуля идут.

  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +11

    Она позволяет добыть данные из ядра при условии возможности дёргать нужные сисколы и выполнять нужные инструкции CPU в контролируемых условиях. Из JS этого сделать нельзя, но можно сформировать код, который будет через другую уязвимость из перечисленных читать память своего процесса. Разберитесь в механизме работы, а потом делайте заявления.

  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +38

    На уровне ОС это "починили" следующим образом: они на выходе из сискола сбрасывают ряд кэшей процессора, через которые "утекают" данные, плюс заанмапили полностью kernel address space, а не только защитили от чтения/записи, так что надо теперь восстанавливать/убирать. Процесс этот небыстрый, что ведёт к нескольким дополнительным сотням циклов на каждый сискол. Отсюда просадка производительности на 30% в том же постгресе.

  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    –5

    Вообще в том же хроме JS вкладки крутится в её собственном процессе. Отдельном.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    0
    Под win S запускаются только приложения рз маркета.

    Через Desktop Bridge на этой Win S хоть Windows Forms можно запустить.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    0

    Они его продвигать могут сколько угодно, но разработчиков под UWP от этого не прибавится. По фичам он проигрывает WPF всухую, а единственную платформу, ради которой это дело хоть кто-то использовал, благополучно похоронили.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +5

    Дата-биндингов нормальных нет, шаблонов нормальных нет, lookless-контролов нет, т. е. идеологически Qt застрял где-то во временах Windows Forms и Delphi 7. А так хороший фреймворк, никто не спорит.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    0

    Где? В .NET Core? Или поддержка вайном UWP? Первое технически слабореализуемо (Mono уже пытались когда-то давно реализовать поддержку WinForms поверх вайна, получилось плохо), во второе слабо верится, ввиду общей непопулярности UWP как платформы.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +1

    Нет. Вместо него поверх CoreCLR работает UWP. Который нигде кроме Windows 10 работать не планирует.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +1

    Любителям синтаксиса QML рекомендую посмотреть в сторону AmmyUI.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +3
    layout & rendering в Electron действительно может быть быстрее

    Так рендерилку (Skia) мы у них в цельнотянутом виде утащили. На не-windows-платформах используется.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +3

    См. SharpGenTools, которым обрабатывается используемый нами SharpDX в процессе сборки. Мы себя отдельно SharpGenTools используем в AvalonStudio для генерации кода интеропа с libdbgshim/ICorDebug для отладки кода под .NET Core.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +7

    У JSON в плане использования как языка разметки есть фатальные недостатки — неименованые типы объектов и отсутствие встроенных текстовых нод. Из-за этого при определении списка элементов приходится писать что-то типа


    {
      "@type": "StackPanel",
      "children": [
        {
          "@type": "TextBlock",
          "text": "Hello world"
        },
        {
          "@type": "Button",
          "text": "Click me"
        }
      ]
    }

    вместо


    <StackPanel>
      <TextBlock>Hello world</TextBlock>
      <Button Text="Click me"/>
    </StackPanel>
  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +6
    потому что строка в .net и null-terminated UCS-2 в WinAPI — это разные штуки

    На самом деле нет, дотнетные строки нуль-терминированы, вы можете взять указатель и передать как есть. Да, в ряде случаев маршалинг нужен, но это контролируемый процесс. Так, всё взаимодействие с DirectX у нас идёт через msil-инструкцию calli, которая выполняет прямой вызов по указателю без автоматических преобразований.


    Демка из статьи выше у меня запустилась сильно медленнее, чем стартует Visual Studio Code

    А вы её запускали через dotnet run? Он каждый раз дёргает MSBuild и кучу ненужностей, чтобы определить, надо ли пересобрать проект (и обычно пересобирает даже тогда, когда не надо). Процесс этот не быстрый. Сделайте dotnet publish под нужную платформу и уже собранный релизный вариант запустите.

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +8

    Вы точно понимаете, как работает P/Invoke? Вы точно понимаете, как именно работает электрон и почему именно он тормозит?

  • Кроссплатформенная новогодняя демка на .NET Core и Avalonia
    +4

    Там всё достаточно примитивно в плане детекта — RuntimePlatform.GetRuntimeInfo().OperatingSystem выдаёт текущую операционку. А дальше создаются окошки уже через P/Invoke либо к Win32 API, либо к GTK3, либо к Cocoa.


    Подробнее по архитектуре см. с 15:00 здесь

  • ААА! Пришло время переписывать на .NET Coreǃ
    +3

    Нет. У вас всё ещё сохраняется уникальный шанс стать тем самым человеком, который перепишет все 50К+ строк кода опенсорсного грида из состава сильверлайта. Или 125К строк кода Xceed-овского грида.

  • ААА! Пришло время переписывать на .NET Coreǃ
    +4

    А что рассказывать, на дотнексте я уже по этому поводу вещал. Ждите релиза беты в начале года.

  • F# на Linux как лекарство для души
    +6

    Райдеровцы первоначально пытались использовать clrdbg (он же vsdbg), но наткнулись на лицензионные препятствия. Софтинка сия выдаёт на старте следующее:


    You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you develop and test your applications.

    В итоге отладки для .NET Core полгода у них не было, так как пришлось делать свою собственную обвязку вокруг libdbgshim.so, которая из Mono работает с COM-интерфейсами coreclr.


    В MonoDevelop же такую обвязку завозить никто не собирается — это теперь просто базовая платформа для VSforMac и Unity, а не самостоятельная полноценная среда разработки.

  • F# на Linux как лекарство для души
    +7

    MonoDevelop не умеет отлаживать .NET Core по лицензионным соображениям. И не научится. По ним же. Такой вот открытый опенсорсный дотнет-стек от майкрософта.

  • Знаки табуляции или пробелы: решаем с помощью Visual Studio
    +1

    Про поддержку editorconfig сказали, а про расширение TabSanity, которое заставляет пробелы ВЫГЛЯДЕТЬ как табы для клавиатурной навигации по коду — нет. Что ж за люди такие.

  • Используем фичи C# 5 (async и await) в .NET 2.0
    0

    (Удалено)

  • Объясняем современный JavaScript динозавру
    0
    кто софт делает на дотнете, делать его под 2 версию.

    ну мы вот по 4-ый для поддержки ХР делали, никто не умер.


    А что там с неткором на маке, его тоже можно компилить или это закрытый блоб для каждой платформы?

    Под MIT-лицензией всё давно. А до неткора было моно с вполне вменяемыми биндингами для Cocoa.

  • Объясняем современный JavaScript динозавру
    0

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

  • Объясняем современный JavaScript динозавру
    0

    Собрал сейчас для интереса каталог контролов авалониевский под макось. 25 мегабайт в zip весит полный бандл приложения вместе с .NET Core внутри, ничего на макось доустанавливать не надо. Это без использования линкера, линковкой можно до 15 где-то ужать. Standalone-приложение, ничего доустанавливать не надо.

  • Объясняем современный JavaScript динозавру
    0

    Ну так мы этот чудо-сайт и обернули в "приложение", только тогда это был не электрон, а просто CEF. Жрал те же самые 800-900 мегабайт.


    Собственно как только начали всех принудительно переводить со старого винформс-приложения (которое кушало 60 мегабайт на тот же набор фич но без звонков и красивой вёрстки) на чудесную версию с ангуларом, так проблемы с привлечением клиентуры и начались.


    Что касается "дотнета в 200 мегабайт", то это откровенный троллинг уже пошёл. Во-первых, он предустановлен. Во-вторых, я лично приложение на AvaloniaUI и .NET Core ужимал линкерами в 20, куда входят все нужные компоненты рантайма).

  • Что не так с уязвимостями в C# проектах?
    +4

    Это Entity Framework-ом не стоит особо увлекаться, ибо тормозит из-за своего change-tracking-а. Нормальные реализации типа linq2db (не путать с linq2sql) по производительности сравнимы с ручным написанием запросов.


    Это касательно доступа к БД. Манипуляции же с объектами внутри процесса, там да, можно использованием LINQ себе производительность хорошо так просадить. В особо терминальных случаях его запускают поверх байтмассивов, а потом удивляются, чому оно работает на 4-5 порядков медленнее вручную написанного цикла.

  • Что не так с уязвимостями в C# проектах?
    +3

    Касательно уязвимостей.
    Им в дотнете взяться особо неоткуда. Управляемый код со строгой статической типизацией перекрывает большинство классических проблем, так что выстрелить себе в ногу намного сложнее. Из потенциально дырявых технологий могу назвать разве что Remoting, которым уже лет 10 как не пользуются.
    Остаются в основном штуки связанные с вебом, но и там можно поймать разве что XSS — SQL-инъеккциям тоже неоткуда взяться, ибо все используют LINQ.

  • Что не так с уязвимостями в C# проектах?
    +2
  • Объясняем современный JavaScript динозавру
    0

    Вообще на самом деле там вообще не надо было лезть в веб, а просто пилить себе нативное приложение. Так что мы стали жертвой не сколько ангулара, сколько хайпа вокруг "теперь всё можно в вебе делать".

  • Объясняем современный JavaScript динозавру
    0
    А что скажете на то что мои проекты жрут по 250 мб оперативки?

    Предложу написать аналог слака, который 600 мегабайт при звонке не будет кушать. Ибо у нас было нечто на него похожее, только с большим набором фич и сильно другой ЦА.

  • Объясняем современный JavaScript динозавру
    0

    Нам вот ангулар проект угробил. Он жрал 900 мегабайт, а у 80% клиентуры были офисные компы с гигабайтом оперативки. Закопано в это всё 15 лямов в итоге. Зато SPA, рилтайм и пыщь-пыщь-звонки через webrtc.

  • Объясняем современный JavaScript динозавру
    +5

    Это вы директорию с нугет-пакетами в дотнете не видели. Хорошо хоть сейчас всё в глобальное хранилище в домашней директории вынесли, а так 600-800 мегабайт на проект было нормой, а сейчас просто 10 гигабайт сразу на всех.

  • Современная Web-платформа: как расслабиться и получать удовольствие? Практическое руководство, часть 1
    0

    Ну вот у вас на картинке режут на столбцы и строки, там сразу нарезали на ячейки.

  • Релиз кросс-платформенного XAML UI-фреймворка AvaloniaUI 0.5
    0

    Делаете


    dotnet restore|grep Detected|sed 's/.*downgrade../<PackageReference Include="/'|sed 's/ from /" Version="/'|sed 's/ to.*/"\/>/'

    получаете на выходе что-то типа:


    <PackageReference Include="System.Collections" Version="4.3.0"/>
    <PackageReference Include="System.Diagnostics.Debug" Version="4.3.0"/>
    <PackageReference Include="System.IO" Version="4.3.0"/>
    <PackageReference Include="System.IO.FileSystem.Primitives" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.Extensions" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0"/>
    <PackageReference Include="System.Text.Encoding" Version="4.3.0"/>
    <PackageReference Include="System.Threading.Tasks" Version="4.3.0"/>
    <PackageReference Include="System.Collections" Version="4.3.0"/>
    <PackageReference Include="System.Diagnostics.Debug" Version="4.3.0"/>
    <PackageReference Include="System.IO" Version="4.3.0"/>
    <PackageReference Include="System.IO.FileSystem.Primitives" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.Extensions" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0"/>
    <PackageReference Include="System.Text.Encoding" Version="4.3.0"/>
    <PackageReference Include="System.Threading.Tasks" Version="4.3.0"/>
    <PackageReference Include="System.Collections" Version="4.3.0"/>
    <PackageReference Include="System.Diagnostics.Debug" Version="4.3.0"/>
    <PackageReference Include="System.IO" Version="4.3.0"/>
    <PackageReference Include="System.IO.FileSystem.Primitives" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.Extensions" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0"/>
    <PackageReference Include="System.Text.Encoding" Version="4.3.0"/>
    <PackageReference Include="System.Threading.Tasks" Version="4.3.0"/>
    <PackageReference Include="System.Collections" Version="4.3.0"/>
    <PackageReference Include="System.Diagnostics.Debug" Version="4.3.0"/>
    <PackageReference Include="System.IO" Version="4.3.0"/>
    <PackageReference Include="System.IO.FileSystem.Primitives" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.Extensions" Version="4.3.0"/>
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0"/>
    <PackageReference Include="System.Text.Encoding" Version="4.3.0"/>
    <PackageReference Include="System.Threading.Tasks" Version="4.3.0"/>
    

    Вставляете это в файл проекта, у нугета внезапно случается просветление и он начинает нормально ставить зависимости.

  • Современная Web-платформа: как расслабиться и получать удовольствие? Практическое руководство, часть 1
    +1

    Ну вот почему у Microsoft в середине нулевых не возникло этой проблемы при проектировании XAML? У всех элементов управления отдельно логика, отдельно разметка. И всё скинуется и стилизуется как угодно.