Метка «.net» - 20

Рецензия на книгу Марка Сиимана «Dependency Injection in .NET»

Открывая книгу по «новомодной технике проектирования», такой как инверсия зависимостей ожидаешь увидеть описание очередной серебряной пули. Дескать, вот, до этого все мы жили неправильно, а теперь, вооружившись ломом контейнером и какой-то матерью мы сможем писать новые приложения за 10 минут.
Поскольку сам я к подобным новомодным инструментам отношусь с некоторой осторожностью, то я был приятно удивлен тем, что в книге Марк делает акцент на общепринятых практиках проектирования, роли стандартных паттернов проектирования, да и вообще, рассматривает принципы управления зависимостями в отрыве от конкретных инструментов.
Читать полностью »

В продолжение своего предыдущего поста habrahabr.ru/post/164305/ продолжаю публиковать интересные тонкости при разработке на C# под AutoCAD. Сегодня речь пойдет о решении проблемы передачи фокуса в AutoCAD при использования Modeless Window.
Читать полностью »

image
Простой проект с описанием изготовления 4WD машинки с управлением от Android-устройства через Bluetooth канал. Управление машинкой происходит при помощи акселерометра, путем наклона планшета/смартфона. Видео работы смотрите в конце статьи. Все исходные тексты прилагаются.

Инструментарии разработки: Java/Eclipse для Android и .NET Micro Framework/Visual C# Express для микроконтроллера.

Читать полностью »

Главным недостатком Mono для Android является то, что для работы приложений требуется отдельная среда выполнения, отличная от Dalvik. И хотя полный доступ к CLR выглядит весьма привлекательно, проксирование и маршаллинг вызовов от одной среды выполнения к другой могут сильно повлиять на производительность. Так почему бы не убрать промежуточную компиляцию в IL-код и получать сразу рабочий Dex-код? Этим и занимается проект dot42.

dot42 — компилятор C# для Dalvik Runtime

В январе, после 1 года разработки, авторы проекта dot42 наконец-то перешли от обещаний к пряникам. И, хотя проект еще не дотягивает до состояния боевого продукта-конкурента Mono, стоит, как минимум, его рассмотреть и попробовать.
Читать полностью »

в 17:30, , рубрики: .net, tpl, метки: , ,

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task<TResult>. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

  • CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
  • CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
  • OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.
Читать полностью »

Я думаю многим читателям блога .Net знакомо имя John Skeet. Особенно после вчерашнего поста юзера SergeyT. Поэтому я не буду повторять про сравнение с Чаком Норрисом и первое место по карме на StackOverflow.com. А вот упомянуть лишний раз про его замечательную книгу “C# In Depth” точно лишним не будет. Центральное место в ней занимает LINQ вообще и LINQ to Objects в частности. Джон очень обстоятельно описывает все возможности языка C# и платформы .Net, которые сделали возможным появление LINQ в его нынешнем виде, а также подробности его реализации. Именно после прочтения этой книги я стал активно использовать LINQ to Objects в своих проектах. Однако в стандартной библиотеке не хватает нескольких крайне нужных операторов. К счастью, Джон Скит исправил это недоразумение. Так появилась небольшая, но очень полезная библиотка morelinq. А с конца прошлого года она доступна в виде NuGet-пакета. Читать полностью »

В статье автор пытается очертить некоторые необходимые для понимания аспекты интернационализации в .NET, особенности китайской и не только локализаций, и несколько забавных моментов.
Читать полностью »

На дворе наступал Новый год, а из головы никак не выходила мысль, что XAML может быть лучше. И, чтобы ему быть лучше, ему нужно перестать быть. Так родилась затея написать альтернативу кошмарному и ужасному XAML'ю: без <Setter.Value>, без {Binding Path=Name, RelativeSource={RelativeSource AncestorType={x:Type Button}}, Converter={StaticResource Converter}}, без FirstValueEqualsToSecondValueOrThirdValueEqualsNullConverter, без <Grid.ColumnDefinitions> <ColumnDefinition/> <ColumnDefinition/> <ColumnDefinition/> <ColumnDefinition/> </Grid.ColumnDefinitions>, без <MultiDataTrigger> <MultiDataTrigger.Triggers> <DataTrigger> <DataTrigger.Binding> <MultiDataBinding>..., без xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml", без всего этого барахла, от написания которого в десятый раз возникают позывы нежно погладить компьютер табуретом и вспоминаются далёкие индусские родственники разработчиков WPF.

Приветствуем: JAML = XAML − XML + JSON

Фичи:

  • Тёплый ламповый синтаксис JSON без кавычек вместо дьявольских уголовых скобок XML.
  • Краткий и вменяемый синтаксис для markup extensions: километровые один-раз-написал-потом-читать-страшно-байндинги {Binding Path=Name, RelativeSource={RelativeSource AncestorType={x:Type Button}}, Converter={StaticResource Converter}} превращаются в почти присваивания {= ~Button.Name, Converter={@Converter} }.
  • Кошерные выражения на C# на замену некошерным конвертерам: {= ${=Property1} == ${=Property2} || ${=Property3} == null }.
  • Смерть «элементной» записи свойств — <Setter.Value> уходят в небытие.
  • Зубодробительное повторение повторений объявляется устаревшим: если куда-то можно положить только ColumnDefinition, не надо повторять это десять раз.
  • Сеттеры и триггеры перестают быть многобуквенными сериализованными костылями: сеттеры выглядят как присваивание свойств, триггеры выглядят как условия.
  • Смерть дублированию десяти «clr-namespace» с указанием имён соборок и прочей нечисти.

Звучит классно? А выглядит оно так:

_={
    $: 'Window root',
    Resources: [{
        $: 'Style MyButtonStyle Button',
        set: {
            Background: 'Red', Foreground: 'Green'
        },
        on: {
            '{=this.IsMouseOver}': {set: {
                Background: 'Yellow', Foreground: 'Blue'
            }}
        }
    }],
    _: [{
        $: 'Grid',
        RowDefinitions: [ { Height: '*' } ],
        ColumnDefinitions: [ { Width: '*' } ],
        _: [{
            $: 'Button btnPressMe', Content: 'Press me!', Style: '{@MyButtonStyle}'
        }]
    }]
}

Читать полностью »

Суть вопроса

В большинстве случаев .NET-приложения являются платформонезависимыми. Мы ожидаем, что наше приложение будет одинаково выполняться как в 32-хразрядной ОС, так и 64-хразрядной.

Так обычно и происходит до тех пор, пока нам не понадобится использовать внешние платформозависимые библиотеки, например неуправляемые. Если такая библиотека существует в вариантах и для x86, и для x64, то это может принести нам определенную головную боль. Будем исходить из того, что ограничивать наше приложение, например, только 32-хразрядным процессом не в наших правилах.

Возможно, нам придется поддерживать вдвое больше конфигураций проекта. В этом случае при отладке придется переключать конфигурации, ведь разработческий веб-сервер Cassini существует только в x86 варианте, а ReSharper может запускать тесты и в 64-хразрядном процессе. Кроме того, придется выпускать два дистрибутива и предоставлять пользователю при скачивании с сайта ох какой нелегкий выбор. Поэтому разумным решением выглядит выбор подходящей для работы библиотеки уже в runtime в зависимости от того, в каком процессе (32-х или 64-хразрядном) код выполняется. При этом сами проекты остаются AnyCPU.

В нашем приложении необходимо подключаться к к Oracle Database, для чего используются библиотеки Oracle Instant Client и Oracle Data Provider for .NET.
Читать полностью »

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js