Все записи автора Андрей Бушман

Приведение к нужному типу объекта, полученного из JSON

Комментарий в коде показывает место, в котором порой допускают ошибку в процессе решения обозначенной задачи.


// JS6
class Foo{
constructor(name,surname){
this.name=name;
this.surname=surname;
};
  fullName(){
  return this.name + ' ' + this.surname;
  };
};

let foo = new Foo('John', 'Smith');
console.log(foo.fullName());

let json = JSON.stringify(foo);
let _foo = JSON.parse(json);

/* ВНИМАНИЕ! Прототип экземпляров класса хранится в его свойстве prototype.
 * Т.е. пытаться получить нужный прототип через Object.getPrototypeOf() в данном
 * случае было бы неправильно. */
Object.setPrototypeOf(_foo, Foo.prototype);

console.log(_foo.fullName());

Многопоточность и GUI

Маленький пример использования многопоточности в приложениях, содержащих графический пользовательский интерфейс (GUI). Продемонстрировано два способа обращения к элементам пользовательского интерфейса из рабочего потока в UI-поток. Графический интерфейс при этом не "подвисает".

.Net Framework 4.5

 /* Sandbox.cs
 * © Andrey Bushman, 2017
 *
 * Небольшой пример создания дополнительного потока,
 * работающего параллельно с потоком пользовательского
 * интерфейса (UI) и обновляющего этот интерфейс по мере
 * необходимости. Дополнительных потоков можно создавать
 * сколько угодно. В данном примере для простоты создаётся
 * только один.
 *
 * В данном примере вместо прямого использоватия потока
 * (Thread) я использую задачу (Task), которая в свою очередь
 * использует пул потоков.
 *
 * Рабочий поток (т.е. задача) вычисляет текущую дату и время,
 * после чего записывает их в ListBox, находящийся в потоке UI.
 *
 * Снятие/установка галочки "Do work" управляет
 * стартом/завершением рабочего потока. Кнопка "Clear" очищает
 * ListBox и заголовок окна.
 *
 * В консоль выводятся идентификаторы текущих потоков и маркер
 * их принадлежности (или не принадлежности) к пулу потоков.
 *
 * В данном примере для обращения к потоку UI из рабочего
 * потока я использую два способа: диспетчер и контекст
 * синхронизации.
 *
 * В примере используется WPF, но всё то же самое применимо к
 * WinForms и ASP.NET.
 */
using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;

namespace Bushman.Sandbox {

    class MyWindow : Window {

        SynchronizationContext context = null;

        public MyWindow() : base() {

            Console.Title = "Sandbox";
            string prefix = "Main Window";
            Title = prefix;
            Topmost = true;

            Width = 300;
            Height = 600;

            ResizeMode = ResizeMode.NoResize;

            WindowStartupLocation = WindowStartupLocation
                .CenterScreen;

            Grid grid = new Grid();
            grid.RowDefinitions.Add(new RowDefinition());
            grid.RowDefinitions.Add(new RowDefinition());
            grid.ColumnDefinitions.Add(new ColumnDefinition());
            grid.ColumnDefinitions.Add(new ColumnDefinition());

            grid.ColumnDefinitions[1].Width = new GridLength(0,
                GridUnitType.Auto);
            grid.RowDefinitions[1].Height = new GridLength(0,
                GridUnitType.Auto);

            Content = grid;

            Thickness margin = new Thickness(5, 5, 5, 5);

            ListBox listbox = new ListBox();
            listbox.Margin = margin;
            grid.Children.Add(listbox);
            listbox.SetValue(Grid.RowProperty, 0);
            listbox.SetValue(Grid.ColumnProperty, 0);
            listbox.SetValue(Grid.ColumnSpanProperty, 2);

            CheckBox chBox = new CheckBox();
            chBox.Margin = margin;
            chBox.Content = "Do work";
            grid.Children.Add(chBox);
            chBox.SetValue(Grid.ColumnProperty, 0);
            chBox.SetValue(Grid.RowProperty, 1);

            Task task = null;
            long i = 0;

            chBox.Checked += (s, e) => {

                task = new Task(() => {
                    using (task) {
                        i = 0;
                        while (Dispatcher.Invoke(
                            () => chBox.IsChecked == true) &&
                            i < long.MaxValue) {

                            // В рабочем потоке выполняем
                            // некоторую работу. Например -
                            // формируем строку текущих даты и
                            // времени.
                            string value = DateTime.Now
                                .ToString("yyyy-MM-dd hh:mm:ss"
                                );

                            // В данном примере мы мы можем
                            // имитировать длительную работу,
                            // либо заблокировать эту строку
                            // кода, если такая имитация нам не
                            // нужна:
                            //Thread.Sleep(TimeSpan.FromSeconds
                            //    (1));

                            Console.WriteLine(
                                "Current thread Id: {0}. " +
                                "Is pull thread: {1}",
                                Thread.CurrentThread
                                .ManagedThreadId.ToString(),
                                Thread.CurrentThread
                                .IsThreadPoolThread);

                            // Результат наших "вычислений"
                            //записываем в поток UI
                            context.Post(_ => {
                                listbox.Items.Add(value);
                                Title = string.Format(
                                    "{0}. Items Count: {1}",
                                prefix, i++.ToString());

                                Console.WriteLine(
                                "Current thread Id: {0}. " +
                                "Is pull thread: {1}",
                                Thread.CurrentThread
                                .ManagedThreadId.ToString(),
                                Thread.CurrentThread
                                .IsThreadPoolThread);
                            }, null);
                        }
                    }
                });

                task.Start();
            };

            chBox.IsChecked = false;

            Button button = new Button();
            button.Content = "Clear";
            button.Margin = margin;
            button.Padding = margin;
            grid.Children.Add(button);
            button.SetValue(Grid.ColumnProperty, 1);
            button.SetValue(Grid.RowProperty, 1);
            button.Click += (s, e) => {
                listbox.Items.Clear();
                Title = prefix;
                i = 0;
            };

            EventHandler action = null;

            action = (s, e) => {
                context = SynchronizationContext.Current;
                Activated -= action;
            };

            Activated += action;

            NameScope.SetNameScope(this, new NameScope());
            RegisterName(nameof(listbox), listbox);
            RegisterName(nameof(chBox), chBox);
            RegisterName(nameof(button), button);
        }
    }

    class Sandbox {
        [STAThread]
        static void Main(string[] args) {

            MyWindow win = new MyWindow();
            Application app = new Application();
            app.Run(win);
        }
    }
}


Результат работы кода выглядит следующим образом:

 

О том, как можно генерировать локализованные версии справки

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

 Введение
Как известно, исходными данными для генерации справки являются XML-файлы, генерируемые MS Visual Studio. Эти файлы создаются в том случае, если в настройках нашего проекта, на вкладке Build установлена галочка XML documentation file. Эти же файлы используются технологией IntelliSense для того, чтобы выдавать всплывающие подсказки в редакторе кода, являясь весьма удобной и всеми нами любимой особенностью. 

 Обозначенные выше XML-файлы генерируются на основе специально оформленных комментариев, присутствующих в нашем коде. Такими комментариями обычно помечаются классы, свойства, методы, делегаты, события, структуры и перечисления. Полный перечень допустимых XML-тегов с примерами их использования опубликован в MSDN.

Для того, чтобы иметь возможность генерировать документацию для разных локализаций (например для русской и английской), XML-комментарии следует выносить во внешние файлы, вместо того, чтобы размещать их непосредственно в наших файлах исходного кода. Более того, для каждой интересующей нас локализации в составе нашего решения следует создавать отдельный проект. Такой способ, помимо прочего, способствует разделению процесса разработки приложения от разработки документации. Т.е. в то время пока один разработчик пишет программный код, другой в это же время может параллельно заниматься составлением русскоязычной документации, а третий - англоязычной.

Например, если целевой проект имеет имя HelloDocs, то для русской и английской версии справочной системы мы добавим в наш проект два новых решения - HelloDocs.Ru и HelloDocs.En (на основе шаблона Class Library). В этих проектах мы будем размещать все XML-файлы: в HelloDocs.En - англоязычная версия, а в HelloDocs.Ru - русскоязычная.
 
Затем в настройках обоих проектов следует указать один и тот же(!!!) каталог вывода: в настройках проекта, на вкладке Build в свойстве Output path. А для всех добавляемых (в дальнейшем) нами в эти проекты XML-файлов свойству Copy to Output Directory следует обязательно назначать значение copy always.

Вот пример исходного кода, определённого в составе файла Magic.cs проекта HelloDocs:

namespace HelloDocs {



    /// <include file='doc/Magic.xml'

    /// path='Documentation/Member[@Name="HelloDocs.Magic"]/*'/>

    public classMagic {

        /// <include file='doc/Magic.xml'

        /// path='Documentation/Member[@Name="HelloDocs.Magic.Foo()"]/*'/>

        public void Foo() { }

    }

}

Соответствующие ему XML-файлы с комментариями будут показаны ниже в данной заметке.
Обратите внимание на то, что в атрибутах file элементов include следует указывать файлы, размещённые не в каталогах локализованных проектов, созданных нами ранее, но файлы размещённые в директории, которую мы выше указали в качестве выходного каталога для локализованных проектов, добавленных нами. На данный момент в том каталоге ничего нет, но это временно, т.к. в процессе компиляции, нужные XML-файлы будут копироваться в тот каталог и Visual Studio найдёт их там в процессе сборки нашего проекта HelloDocs.

Поскольку теперь для нас становился важен порядок компиляции проектов, то мы должны указать, что наш целевой проект зависит от локализованных проектов справочной системы. Соответственно они должны собираться раньше него:


Затем в Менеджере Конфигураций для всех проектов локализованных справочных систем следует снять галочки, оставив только для одного из них. Поскольку в нашем примере локализованных версий будет две, то снимаем галочку только для одного проекта:


 
В проект HelloDocs.En добавим файл Magic.xml с таким содержимым:

<?xml version="1.0"encoding="utf-8" ?>

<Documentation>

  <Member Name="HelloDocs.Magic">

    <summary>

      The <c>HelloDocs.Magic</c> is super-class...

    </summary>

    <remarks>

      Late it will be very popularly :)

    </remarks>

  </Member>

  <Member Name="HelloDocs.Magic.Foo()">

    <summary>

      The super-method...

    </summary>

    <remarks>It does nothing still... :)</remarks>

  </Member>

</Documentation>

В проект HelloDocs.Ru добавим файл Magic.xml с таким содержимым:

<?xml version="1.0"encoding="utf-8" ?>

<Documentation>

  <Member Name="HelloDocs.Magic">

    <summary>

      Наш <c>HelloDocs.Magic</c> есть супер-класс...

    </summary>

    <remarks>

      Позднее он будет очень популярен! :)

    </remarks>

  </Member>

  <Member Name="HelloDocs.Magic.Foo()">

    <summary>

      Это супер-метод...

    </summary>

    <remarks>Пока он ничего не делает... :)</remarks>

  </Member>

</Documentation>

Не забываем для этих XML-файлов изменить значение свойства Copy to Output Directory, как было указано выше. Обратите внимание, что эти файлы имеют одинаковые имена и одинаковую XML-структуру. Различие состоит только в содержимом соответствующих XML-элементов (это важно!!!).

Теперь наше решение выглядит следующим образом:


XML-файлы, генерируемые Visual Studio на основе XML-файлов наших локализованных проектов теперь могут использоваться в Sandcastle для генерации конечной документации.

Если Sandcastle ещё не установлен на вашей машине, то теперь самое время это сделать. Для установки Sancastle требуются административные права. После установки, в перечне доступных типов проектов IDE появляется дополнительный тип проекта, при помощи которого можно генерировать справку для интересующего нас проекта. Добавим в наше решение новый проект, созданный на основе нужного нам шаблона и присвоим ему имя HelpDocs.Doc:




Создав проект справки, первым делом мы указываем в его настройках источник, откуда нужно будет получить данные для формирования документации:



Интересующий нас формат справки указывается в настройках нашего Sandcastle-проекта:

Теперь запустив сборку нашего решения мы получим не только наш DLL, но и сгенерированный файл справки:



На скрине красной линией подчёркнут английский текст нашего XML-файла. Теперь отключим сборку англоязычной справки и включим русскоязычную:




Затем в настройках проекта HelpDocs.Doc меняем свойство Help file language, выбрав в нём русскую локализацию (чтобы дополнительный текст, присутствующий в документации, был так же на русском языке):



Теперь снова запускаем сборку нашего решения и проверяем сгенерированный файл справки:



Как мы видим - теперь мы получили русский вариант справки. Т.о. при желании мы можем реализовать столько локализаций нашей справочной системы, сколько посчитаем нужным.

P.S.
В идеале, конечно же, было бы избавиться от необходимости переключения галочек и правки свойства нашего Sandcastle-проекта, путём создания такого проекта отдельно под каждую локализацию. Но проблема заключается в том, что в нашем исходном коде жёстко прописан каталог, в котором следует искать XML-файл.

Конечно, можно было бы решить эту проблему при помощи конструкций #if/#elif/#endif:

namespace HelloDocs {

#if ENU
/// <include file='Magic.doc.enu.xml'
/// path='Documentation/Member[@Name="HelloDocs.Magic"]/*'/>
#elif RUS
/// <include file='Magic.doc.rus.xml'
/// path='Documentation/Member[@Name="HelloDocs.Magic"]/*'/>
#endif
public class Magic {
#if ENU
/// <include file='Magic.doc.enu.xml'
/// path='Documentation/Member[@Name="HelloDocs.Magic.Foo()"]/*'/>
#elif RUS
/// <include file='Magic.doc.rus.xml'
/// path='Documentation/Member[@Name="HelloDocs.Magic.Foo()"]/*'/>
#endif
public void Foo() { }
}
}

Однако писать такие конструкции - процесс весьма трудоёмкий. К тому же, в случае добавления новой локализации придётся везде в коде добавлять дополнительный блок #elif, что может оказаться очень затратным по времени для больших и даже средних проектов.

Дополнительные ресурсы

NuGet-пакет для Revit 2017

На https://www.nuget.org не нашёл от Autodesk NuGet-пакетов для Revit 2017. Соответственно, сделал свой.

Результат здесь: https://www.nuget.org/packages/Revit-2017x64.Base/1.0.0

Пакет подключает к проекту файлы RevitAPI.dll, RevitAPIUI.dll, RevitAPIIFC.dll, RevitAPIMacros.dll, и RevitAPIUIMacros.dll. В процессе подключения обозначенных сборок, пакет назначает их свойству Copy Local значение False.

CHM: о наименовании каталогов и файлов исходников.

Недавно столкнулся с проблемой, когда Help and Manual не мог успешно компилировать мой проект в документацию CHM-формата. Причём тот же самый проект успешно опубликовывался в PDF-версию.

При формировании CHM-файла программа Help and Manual использует "родной" инструмент от Microsoft - утилиту hhc.exe. Мой проблемный проект находился в каталоге "%projects%MyProjectName.help" и файл проекта имел имя "MyProjectName.help.hmxp". Любые попытки собрать на его основе CHM-документацию приводили к ошибкам компиляции:



Группа технической поддержки Help and Manual помогла мне разобраться с причиной возникновения подобных ошибок (за что я им весьма признателен):
In your case the error may be caused by the dot and the word "help" in the folder name and CHM file name. The combination of the dot and the letter "h" (and possibly also the word "help") in filenames and folder names is poison for the Microsoft CHM system on some versions of Windows. It is very ancient and has not been updated or bugfixed since it was originally released with Windows 98. 

Получив такой ответ, я заменил "." на "_" (перед "help") в имени каталога проекта, а так же в имени HMXP-файла, после чего проблема со сборкой CHM-справки сразу же исчезла.

Динамический вызов функций неуправляемых DLL

В .NET-атрибутах можно указывать только константные выражения. Т.о. атрибуту DllImport нужно указывать имя библиотеки статически, дабы это имя было известно на этапе компиляции. Порой это порождает уродливые конструкции, разрастающиеся как снежный ком, по мере появления новых версий AutoCAD. Наглядный тому пример можно увидеть здесь в коде Александра Ривилиса: по мере появления AutoCAD 2018, 2019 и т.д. - этот код придётся каждый раз дописывать.


Как правило, имя нужной DLL достаточно просто выяснить во время выполнения кода. Например, в обозначенном выше коде Александра Ривилиса нужная функция хранится в файлах acdb17.dll, acdb18.dll, ac1st19.dll, ac1st20.dll, ac1st21.dll. Т.е. мы видим, что каждая библиотека в качестве суффикса использует значение Major версии приложения. Кроме того, мы видим, что начиная с версии 19 (AutoCAD 2013) функция была перенесена в др. библиотеку (т.е. изменился префикс в её имени). Зная обозначенные выше правила, можно динамически вычислить имя DLL файла, в котором находится интересующая нас функция.

Далее показываю небольшой пример того, как можно динамически вызывать функцию acedSetEnv в разных версиях AutoCAD, не создавая для неё статических обёрток. На всякий случай напоминаю, что до версии AutoCAD 2013 эта функция находилась в файле acad.exe, а начиная с AutoCAD 2013 была перенесена в accore.dll.

Код проверялся в AutoCAD 2009 и 2016.

-------------------------------------------------------------
/* Utils.cs */
using System;
using System.Text;
using System.Runtime.InteropServices;
using cad = Autodesk.AutoCAD.ApplicationServices.Application;

namespace Bushman.AutoCAD.Sandbox {

    [UnmanagedFunctionPointer(CallingConvention.Cdecl, CharSet
        = CharSet.Auto)]
    public delegate int acedSetEnvDelegate(string envName,
        StringBuilder NewValue);

    public static class Utils {

        [DllImport("kernel32.dll")]
        public static extern IntPtr LoadLibrary(string
            dllToLoad);

        [DllImport("kernel32.dll")]
        public static extern IntPtr GetProcAddress(IntPtr
            hModule, string procedureName);


        [DllImport("kernel32.dll")]
        public static extern bool FreeLibrary(IntPtr hModule);

        const int AutoCAD_2013_Major = 19;

        public static string GetDllName() {

            if (cad.Version.Major < AutoCAD_2013_Major)
                return "acad.exe";
            else
                return "accore.dll";
        }

        public static acedSetEnvDelegate acedSetEnv;

        static Utils() {
            acedSetEnv = GetAcedSetEnv();
        }

        static acedSetEnvDelegate GetAcedSetEnv() {

            string dllName = Utils.GetDllName();
            IntPtr pDll = Utils.LoadLibrary(dllName);

            if (pDll == IntPtr.Zero) {
                return null;
            }

            string funcName = "acedSetEnv";

            IntPtr pAddressOfFunctionToCall = Utils
                .GetProcAddress(pDll, funcName);

            if (pAddressOfFunctionToCall == IntPtr.Zero) {

                return null;
            }

            acedSetEnvDelegate acedSetEnv = (
                acedSetEnvDelegate) Marshal
                .GetDelegateForFunctionPointer(
                pAddressOfFunctionToCall,
                typeof(acedSetEnvDelegate));

            bool result = Utils.FreeLibrary(pDll);

            return acedSetEnv;
        }
    }
}

 ------------------------------------------------------------

Далее создадим тестовую команду, которая изменит значение переменной "ACAD":

------------------------------------------------------------
/* Commands.cs */
using System;
using System.Runtime.InteropServices;
using System.Text;
using cad = Autodesk.AutoCAD.ApplicationServices.Application;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.EditorInput;
using Autodesk.AutoCAD.Runtime;

namespace Bushman.AutoCAD.Sandbox {

    public sealed class Commands {

        [CommandMethod("Test", CommandFlags.Modal)]
        public void Test() {

            Document doc = cad.DocumentManager
                .MdiActiveDocument;

            if (doc == null)
                return;

            Editor ed = doc.Editor;

            acedSetEnvDelegate acedSetEnv = Utils.acedSetEnv;

            if (acedSetEnv == null) {
                ed.WriteMessage("acedSetEnv function was " +
                    "not found.");
                return;
            }

            /* For example, we'll edit the "Support File Search
             * Path" value: */
            string varName = "ACAD";
            StringBuilder sb = new StringBuilder(
                @"C:\abc\def");

            int theResult = acedSetEnv(varName, sb); // 5100
        }
    }
}

---------------------------------------------------------------

Динамическое связывание и изменение системой переменной ACAD успешно происходит в обоих тестируемых версиях AutoCAD: 2009 и 2016.



Работа с реестром в операционных системах Windows (часть 2)

Когда-то здесь я выкладывал инструменты по работе с реестром для .NET 3.5 SP1. Обнаружилось, что начиная с .NET 4.0 сигнатура нужных для обозначенного кода конструкторов класса RegistryKey была изменена. Как следствие - если наша сборка, скомпилированная под .NET 3.5 SP1 в дальнейшем окажется загруженной в .NET 4.0 (или любую более новую), то мы будем получать исключение времени выполнения при вызове некоторых методов опубликованного кода.


Я внёс некоторые правки в исходный код класса RegistryExtensions и написал несколько интеграционных тестов, проверяющих корректность работы кода в различных ситуациях (в т.ч. избавился от всех директив препроцессора - теперь они не нужны). Проверял в .NET 3.5 SP1, 4.0 и 4.6.1 для платформ x86|x64|AnyCPU:


Обозначенный код я поддерживаю в виду того, что у меня имеется в наработке некоторый объем кода, компилируемого под .NET 3.5 SP1 (т.к. AutoCAD 2009 не поддерживает более новые версии .Net Framework). Этот код должен без проблем компилироваться и успешно работать  не только в .NET 3.5 SP1, но и во всех более новых версиях .NET. Кроме того, необходимо, чтобы ранее скомпилированные мною под .NET 3.5 SP1 сборки успешно загружались и работали в .NET 4.0 - 4.6.1.

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

======================================================================
/* AcProducts
 * RegistryExtensions.cs
 * © Андрей Бушман, 2014
 *
 * В файле RegistryExtensions.cs определён дополнительный
 * функционал, расширяющий возможности работы с реестром из
 * .NET приложений, написанных на .NET 3.5 SP1.
 *
 * ИЗМЕНЕНИЯ:
 * 10-авг-2016
 *      В код внесены правки для того, чтобы он мог
 *      использоваться не только в .NET 3.5 SP1, но и во всех
 *      более новых версиях .NET Framework: например, когда
 *      сборка, скомпилированная под .NET 3.5 SP1 загружается в
 *      код .Net 4.6.1. Код не зависит от разрядности (x86|x64|
 *      AnyCPU).
 */
using System;
using Microsoft.Win32;
using System.Reflection;
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

namespace Bushman.AcProducts {

    /// <summary>
    /// Данный класс предназначен для предоставления 32-битным
    /// приложениям доступа к 64-битным разделам реестра. Класс
    /// так же может использоваться для предоставления
    /// 64-битным приложениям ветке реестра, предназначенной
    /// для 32-битных. За основу взят код, опубликованный в
    /// блоге http://clck.ru/96A9U
    /// </summary>

    public static class RegistryExtensions {

        /// <summary>
        /// Открытие ключа реестра, с указанием того, какую
        /// именно часть следует открывать: записи для
        /// 32-битных приложений, или же записи для 64-битных.
        ///
        /// ВНИМАНИЕ
        /// У данного метода имеется побочный эффект: свойство
        /// `Name` у возвращаемого объекта `RegistryKey` даёт
        /// пустую строку. Однако это не страшно, т.к. имя нам
        /// известно - первую часть можно получить из родителя,
        /// а вторую часть этого имени мы и так знаем,
        /// поскольку передаём её в виде параметра.
        /// </summary>
        /// <param name="parentKey">Родительский элемент
        /// RegistryKey, в котором следует выполнить открытие
        /// подраздера.</param>
        /// <param name="subKeyName">Name of the key to be
        /// opened</param>
        /// <param name="writable">true - открывать для чтения
        /// и записи; false - открывать только для чтения.
        /// </param>
        /// <param name="options">Какую именно часть реестра
        /// следует открывать: относящуюся к 32-битным
        /// приложениям или же относящуюся к 64-битным.
        /// </param>
        /// <returns>Возвращается RegistryKey или null, если по
        /// каким-либо причинам получить RegistryKey не
        /// удалось.</returns>
        public static RegistryKey OpenSubKey(this RegistryKey
            parentKey, String subKeyName, Boolean writable,
            RegWow64Options options) {

            // Проверка работоспособности
            if (parentKey == null || GetPtr(
                parentKey) == IntPtr.Zero) {

                return null;
            }

            // Назначение прав
            Int32 rights = (Int32) (writable ? RegistryRights
                .WriteKey : RegistryRights.ReadKey);

            // Вызов функций неуправляемого кода
            Int32 subKeyHandle, result = RegOpenKeyEx(
                GetPtr(parentKey), subKeyName, 0,
                rights | (Int32) options, out subKeyHandle);

            // Если мы ошиблись - возвращаем null
            if (result != 0) {

                return null;
            }

            /* Получаем ключ, представленный указателем,
             * возвращённым из RegOpenKeyEx */
            RegistryKey subKey = PtrToRegistryKey((IntPtr)
                subKeyHandle, writable, false, options);

            return subKey;
        }

        /// <summary>
        /// Получить указатель на ключ реестра.
        /// </summary>
        /// <param name="registryKey">Ключ реестра, указатель
        /// на который нужно получить.
        /// </param>
        /// <returns>Возвращается объект IntPtr. Если не
        /// удалось получить указатель на обозначенный объект
        /// RegistryKey, то возвращается IntPtr.Zero.</returns>
        public static IntPtr GetPtr(this RegistryKey
            registryKey) {

            if (registryKey == null)
                return IntPtr.Zero;

            /* The `RegistryKey.Handle` property appears since
             * .Net 4.0, therefore for .Net 3.5 I get it
             * through reflection. */
            Type registryKeyType = typeof(RegistryKey);

            FieldInfo fieldInfo = registryKeyType.GetField(
                "hkey", BindingFlags.NonPublic | BindingFlags
                .Instance);

            SafeHandle handle = (SafeHandle) fieldInfo.GetValue
                (registryKey);

            IntPtr unsafeHandle = handle.DangerousGetHandle(
                );

            return unsafeHandle;
        }

        /// <summary>
        /// Получить ключ реестра на основе его указателя.
        /// </summary>
        /// <param name="hKey">Указатель на ключ реестра
        /// </param>
        /// <param name="writable">true - открыть для записи;
        /// false - для чтения.</param>
        /// <param name="ownsHandle">Владеем ли мы
        /// дескриптором: true - да, false - нет.</param>
        /// <returns>Возвращается объект RegistryKey,
        /// соответствующий полученному указателю.</returns>
        public static RegistryKey PtrToRegistryKey(IntPtr
            hKey, Boolean writable, Boolean ownsHandle,
            RegWow64Options opt) {

            if (IntPtr.Zero == hKey) {
                return null;
            }

            Type safeRegistryHandleType =
                typeof(SafeHandleZeroOrMinusOneIsInvalid)
                .Assembly.GetType("Microsoft.Win32." +
                "SafeHandles.SafeRegistryHandle");

            /* Получаем массив типов, соответствующих
             * аргументом конструктора, который нам нужен. */
            Type[] argTypes = new Type[] { typeof(IntPtr),
                typeof(Boolean) };

            BindingFlags flags = default(BindingFlags);

            if (Environment.Version.Major < 4) {
                flags = BindingFlags.Instance | BindingFlags
                    .NonPublic;
            }
            else {
                flags = BindingFlags.Instance | BindingFlags
                    .Public;
            }

            // Получаем ConstructorInfo для нашего объекта
            ConstructorInfo safeRegistryHandleCtorInfo =
                safeRegistryHandleType.GetConstructor(flags,
                    null, argTypes, null);

            /* Вызываем конструктор для SafeRegistryHandle.
             * Класс SafeRegistryHandle появился начиная с .NET
             * 4.0. */
            Object safeHandle = safeRegistryHandleCtorInfo
                .Invoke(new Object[] { hKey, ownsHandle });

            Type registryKeyType = typeof(RegistryKey);
            Type registryViewType = null;

            /*Получаем массив типов, соответствующих аргументом
             * конструктора, который нам нужен */
            Type[] registryKeyConstructorTypes = null;

            if (Environment.Version.Major < 4) {
                registryKeyConstructorTypes = new Type[] {
                safeRegistryHandleType, typeof(bool) };
            }
            else {
                registryViewType = typeof(
                    SafeHandleZeroOrMinusOneIsInvalid).Assembly
                    .GetType("Microsoft.Win32.RegistryView");

                registryKeyConstructorTypes = new Type[] {
                    safeRegistryHandleType, typeof(bool),
                    registryViewType };

                flags = BindingFlags.Instance | BindingFlags
                    .NonPublic;
            }

            // Получаем ConstructorInfo для нашего объекта
            ConstructorInfo registryKeyCtorInfo =
                registryKeyType.GetConstructor(flags, null,
                registryKeyConstructorTypes, null);

            RegistryKey resultKey = null;

            if (Environment.Version.Major < 4) {
                // Вызываем конструктор для RegistryKey
                resultKey = (RegistryKey) registryKeyCtorInfo
                    .Invoke(new Object[] {
                    safeHandle, writable });
            }
            else {
                // Вызываем конструктор для RegistryKey
                resultKey = (RegistryKey) registryKeyCtorInfo
                    .Invoke(new Object[] {
                    safeHandle, writable, (int) opt});
            }

            // возвращаем полученный ключ реестра
            return resultKey;
        }

        /// <summary>
        /// Получение числового значения указателя на искомый
        /// подраздел реестра.
        /// </summary>
        /// <param name="hKey">Указатель на родительский раздел
        /// реестра.</param>
        /// <param name="subKey">Имя искомого подраздела.
        /// </param>
        /// <param name="ulOptions">Этот параметр
        /// зарезервирован и всегда должен быть равным 0.
        /// </param>
        /// <param name="samDesired">Права доступа (чтение\
        /// запись) и указание того, как именно следует
        /// открывать реестр. Значение этого параметра
        /// формируется путём применения операции логического
        /// "И" для объектов перечислений RegistryRights и
        /// RegWow64Options.</param>
        /// <param name="phkResult">Ссылка на переменную, в
        /// которую следует сохранить полученное числовое
        /// значение указателя на искомый подраздел.</param>
        /// <returns>В случае успеха возвращается 0.</returns>
        [DllImport("advapi32.dll", CharSet = CharSet.Auto)]
        static extern Int32 RegOpenKeyEx(IntPtr hKey,
            String subKey, Int32 ulOptions, Int32 samDesired,
            out Int32 phkResult);
    }

    /// <summary>
    /// Перечисление указывает, какую именно часть реестра
    /// следует открывать: относящуюся к 32-битным приложениям
    /// или же относящуюся к 64-битным.
    /// </summary>
    public enum RegWow64Options {

        /// <summary>
        /// Открывать ту часть реестра, которая хранит
        /// информацию приложений, разрядность которых
        /// соответствует разрядности текущего приложения
        /// (x86\x64).</summary>
        None = 0,
        /// <summary>
        /// Открывать часть реестра, относящуюся к 64-битным
        /// приложениям.
        /// </summary>
        KEY_WOW64_64KEY = 0x0100,
        /// <summary>
        /// Открывать часть реестра, относящуюся к 32-битным
        /// приложениям.
        /// </summary>
        KEY_WOW64_32KEY = 0x0200
    }

    /// <summary>
    /// Перечисление, указывающее на то, с каким уровнем
    /// доступа следует открывать ветку реестра: для чтения,
    /// или же для чтения\записи.
    /// </summary>
    public enum RegistryRights {

        /// <summary>
        /// Открыть только для чтения.
        /// </summary>
        ReadKey = 131097,
        /// <summary>
        /// Открыть для чтения и записи.
        /// </summary>
        WriteKey = 131078
    }
}
==================================================================

Интеграционные тесты:

==================================================================
/* AcProducts.IntegrationTests
 * RegistryExtensionsTests.cs
 * © Andrey Bushman, 2016
 *
 * Integration tests of Bushman.AcProducts.RegistryExtensions
 * class.
 */
using System;
using Microsoft.Win32;
using NUnit.Framework;

namespace Bushman.AcProducts.IntegrationTests {

    [TestFixture]
    public class RegistryExtensionsTests {

        [Test]
        public void GetPtr_Returns_ValidPtr() {

            // `Registry.LocalMachine` key always exists.
            RegistryKey rk = Registry.LocalMachine;
            IntPtr rkPtr = rk.Handle.DangerousGetHandle();

            /* The `RegistryKey.Handle` property appears since
             * .Net 4.0, therefore for .Net 3.5 in the code
             * under test I get it through reflection. */
            IntPtr rkPtr2 = RegistryExtensions.GetPtr(rk);

            Assert.AreEqual(rkPtr, rkPtr2);
        }

        [Test]
        public void GetPtr_ReturnsZero_ForNull() {

            /* The `RegistryKey.Handle` property appears since
             * .Net 4.0, therefore for .Net 3.5 in the code
             * under test I get it through reflection. */
            IntPtr ptr = RegistryExtensions.GetPtr(null);

            Assert.AreEqual(IntPtr.Zero, ptr);
        }

        [TestCase(@"SOFTWARE\7-Zip", RegWow64Options
            .KEY_WOW64_64KEY, false)]

        [TestCase(@"SOFTWARE\7-Zip", RegWow64Options
            .KEY_WOW64_32KEY, true)]

        [TestCase(@"SOFTWARE\Notepad++",
            RegWow64Options.KEY_WOW64_64KEY, true)]

        [TestCase(@"SOFTWARE\Notepad++",
            RegWow64Options.KEY_WOW64_32KEY, false)]

        [Description("7-Zip and Notepad++ are to be installed"
            )]
        public void OpenSubKey_ReturnsValidValue(string subkey,
            RegWow64Options opt, bool isNull) {

            RegistryKey rk = Registry.LocalMachine;

            RegistryKey rk2 = RegistryExtensions.OpenSubKey(rk,
                subkey, false, opt);

            if (isNull) {
                Assert.IsNull(rk2);
            }
            else {
                Assert.IsNotNull(rk2);
            }
        }

        [Test]
        public void OpenSubKey_ReturnsNull_ForInvalidSubkey() {

            string subkey =
                "{F28A3464-0A5D-48FB-AFF6-B07F058D3EFC}";

            RegistryKey rk = RegistryExtensions.OpenSubKey(
                Registry.LocalMachine, subkey, false,
                RegWow64Options.None);

            Assert.IsNull(rk);
        }

        [Test]
        public void PtrToRegistryKey_Returns_ValidValie() {

            RegistryKey rk = Registry.LocalMachine;
            IntPtr rkPtr = rk.Handle.DangerousGetHandle();

            RegistryKey rk2 = RegistryExtensions
                .PtrToRegistryKey(rkPtr, false, false,
                RegWow64Options.None);
            IntPtr rkPtr2 = rk2.Handle.DangerousGetHandle();

            Assert.AreEqual(rkPtr, rkPtr2);
        }

        [Test]
        public void PtrToRegistryKey_ReturnsNull_ForZero() {

            RegistryKey rk = RegistryExtensions
                .PtrToRegistryKey(IntPtr.Zero, false, false,
                RegWow64Options.None);

            Assert.IsNull(rk);
        }
    }
}
==================================================================

NuGet пакеты для AutoCAD .NET API

Пару лет назад, компания Autodesk начала (наконец-то!) опубликовывать NuGet-пакеты для AutoCAD .NET API. Об этом так же было радостно сообщено в блоге ADN. Однако, как это обычно и бывает у Autodesk, тестированием пакетов перед их публикацией в Autodesk не заморачиваются (как собственно и тестированием самого AutoCAD, ибо длительная, печальная практика показывает, что группа тестирования даже самого AutoCAD в компании Autodesk в принципе нарисована только "для галочки" - примеров, доказывающих это - множество, в т.ч. и в моём блоге).

 Пробежавшись по комментариям, оставленным пользователями в обозначенной выше записи блога ADN можно сразу заметить, что пакеты работают криво. Т.е. их тестированием себя никто не утруждал. С тех пор Autodesk выпустил ещё две версии AutoCAD. Казалось бы, что за два года можно было вполне довести до ума пакеты, на создание которых (с нуля) уходит не более получаса (причём сразу под все версии AutoCAD от 2009 и выше)... Но печальная практика в который раз демонстрирует обратное...

Я попробовал установить самую свежую на сегодняшний день версию пакета AutoCAD.NET (version 21.0.1). В душе теплилась надежда, что за два года проблему с CopyLocal в Autodesk всё же победили, тем более что её решение находится в Google за пару секунд по элементарной фразе: "NuGet CopyLocal false". Однако, как оказалось, воз и поныне там - ни одна сборка, подключенная путём установки NuGet пакета не имеет свойства CopyLocal установленного в false.

Я не верю в то, что в Autodesk работают настолько глупые люди (глупых бы не взяли на работу, как мне кажется). То, что я систематически вижу, всякий раз подтверждает моё давно сформировавшееся убеждение в том, что в Autodesk работают люди, многим из которых просто наплевать на качество своей работы (это ещё хуже, чем первый вариант)... К таким людям (ИМХО) на все 100% относится группа тестирования (во главе с Михаилом Белиловским, насколько я помню), которая выполняет свою работу (если вообще выполняет) из рук вон плохо - достаточно посмотреть на качество работы того же accoreconsole.exe. Подобным отношением к своей работе страдает и тот сотрудник Autodesk, которому поручили собирать и опубликовывать NuGet пакеты AutoCAD.NET. Можно сколько угодно с умным видом разъезжать по различным конференциям, изображая бурную радость и воодушевление в процессе разговоров о программировании в AutoCAD, но если ты не выполняешь свою прямую, первостепенную обязанность - отвечать за качество тестирования продукта, то грош цена таким разговорам, улыбкам... да и самим специалистам (ИМХО).

 Ладно, не буду более трепать себе понапрасну нервы из-за качества работы обозначенных выше персонажей (моих нервов они не стоят :) ) - давайте лучше вернёмся к их злосчастным NuGet пакетам...

Отсутствие нужного значения в свойстве CopyLocal не является единственной проблемой. Текущая реализация пакетов подразумевает, что каждый раз, запуская команду Update-Package (без опции -Version) вы тем самым будете обновлять все сборки AutoCAD, подключенные в вашем проекте, до самой последней версии AutoCAD (для которой имеется соответствующий NuGet пакет).

Однако вовсе не факт, что разработчик захочет именно такое поведение. Лично я хочу, чтобы если я в своём проекте указал использование сборок от AutoCAD 2016, то и все обновления должны происходить только в рамках интересующей меня версии AutoCAD. Мне не нужно, чтобы происходило автоматическое обновление сборок до версии AutoCAD 2017, 2018 или 2020 - не надо за меня принимать подобных решений(!!!)...

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

Для того, чтобы избежать обозначенной выше проблемы, созданной Autodesk'ом, нужно для каждой версии AutoCAD формировать (всего лишь!) уникальное имя пакета (т.е. его Id). Значения Minor и Major для версий этих пакетов можно брать либо из соответствующий значений версий AutoCAD, либо начинать с 1 (это не имеет значения, но выбрав стиль нумерации версий, следует придерживаться его и в др. пакетах во избежание путанницы).

Autodesk предоставляет NuGet пакеты только начиная с версии AutoCAD  2015. Для более поздних версий пакеты не предоставляются.

Поскольку NuGet пакеты компани Autodesk не пригодны к полноценному использованию в том виде, в котором они уже который год поставляются пользователям (ИМХО), а так же поскольку отсутствуют пакеты для интересующих меня версий AutoCAD, то я создал свои NuGet пакеты, предоставляющие AutoCAD .NET API, в которых отсутствуют обозначеные мною выше проблемы.

Чаще всего я компилирую код своих проектов под AutoCAD 2009 и 2013. Результат компиляции первого из них может затем успешно загружаться в AutoCAD 2009-2012, а второго - в AutoCAD 2013 и во все более новые версии. В виду этого, в первую очередь я создал NuGet пакеты именно для AutoCAD 2009 и 2013.

В ближайшее время я, на всякий случай, создам аналогичные NuGet пакеты для всех остальных версий AutoCAD из диапазона AutoCAD 2009-2017 (на тот случай, если мне в каком-то проекте, по какой-то причине, понадобится иная версия API).

UPD
Опубликовал NuGet пакеты для AutoCAD 2009-2017 (на каждую версию AutoCAD по три пакета).

Прокси в AutoCAD

Обновлена утилита по работе с прокси в AutoCAD.

Что нового...

1. CadProxy был переименован в Proxy Tools for AutoCAD (т.е. в Прокси-инструменты для AutoCAD).
2. Теперь это бесплатное программное обеспечение вместо открытого программного обеспечения.
3. Добавлены русская и английская лицензии.
4. Добавлена русская локализация.
5. Для AutoCAD 2009-2011: в процессе загрузки приложения в AutoCAD, родительский каталог приложения будет добавлен в Путь доступа к вспомогательным файлам (если это ещё не было сделано ранее).* Это необходио для работы справочной системы приложения.
6. Для AutoCAD 2009-2011: в реестре будет выполнена регистрация приложения (загрузка по требованию), если это не было сделано ранее.* В виду этого, вызов команды _NETLOAD для этих версий AutoCAD потребуется только один раз.
7. Операция ПРОВЕРИТЬ (_AUDIT) будет выполняться каждый раз перед расчленением или удалением прокси, если команды ВЗПРОКСИ (_XPROXY) или УДПРОКСИ (_RMPROXY) не являются предыдущей выполненной командой. Так же команда ПРОВЕРИТЬ (_AUDIT) будет автоматически выполняться и после работы этих команд.
8. Если файлы меню CUICUIX были ранее загружены пользователем в AutoCAD непосредственно из каталога расширения, тогда они будут выгружены, скопированы в Windows-профиль пользователя и затем в AutoCAD будут загружены эти копии.*
9. Изображения в файлах меню CUICUIX были заменены. Теперь эти изображения используют ICO формат вместо BMP (новые изображения используют прозрачность).
10. MNR-файлы были удалены из MSI-инсталлятора.
11. MSI-инсталлятор был полностью переписан. Теперь он показывает лицензию, устанавливаемые наборы компонентов, а так же предоставляет фиксированный набор каталогов, в которые может быть выполнена установка приложения.
12. Имеется две версии локализации MSI-установщика: английская и русская.
13. Инсталлятор добавляет пункты меню в Пуск -> Все программы. Локализация этих пунктов меню совпадает с локализацией использованного MSI-инсталлятора.
14. Теперь 32-битная версия MSI-инсталлятора не может использоваться для Windows x64 (ограничение добавлено намеренно).
15. Теперь расширение может быть установлено как с административными правами, так и без них. Это зависит от выбора, который сделает пользователь в процессе установки приложения.
16. Файл справки полностью переписан.
17. Исправлены некоторые ошибки в программном коде.


* - Проверка будет выполняться каждый раз при загрузке приложения в AutoCAD.

Пользовательское меню:



 Меню в Пуск -> Все программы:


 Дополнительная информация, размещаемая в реестре:


Возможность выбрать целевой каталог установки:


Локализованная справка:




Изменение серийного номера для MS Office 2016

Порой, производя очередную активацию MS Office, можно получить сообщение о том, что лимит количества активаций с этим ключом уже исчерпан... В этом случае можно выполнить активацию переписав ключ новым значением. Возникает вопрос: как заменить ранее указанный ключ продукта на более новый?


Ответ на обозначенный вопрос я нашёл на форуме Майкрософт (спасибо Faruk Ekiz). Копирую ответ Faruk Ekiz в своей записи в качестве шпаргалки, дабы позднее всегда мог быстро находить его.


1. Open a command prompt. For instance via:
  • Start-> All Programs-> Accessories-> Command Prompt
  • Windows XP
    Start-> Run: cmd
  • Windows Vista, Windows 7 and Windows 8
    Start-> type: cmd
2. In the command prompt, type the following:
  • Office 2016 (32-bit) on a 32-bit version of Windows
    cscript "C:Program FilesMicrosoft OfficeOffice16OSPP.VBS" /dstatus
  • Office 2016 (32-bit) on a 64-bit version of Windows
    cscript "C:Program Files (x86)Microsoft OfficeOffice16OSPP.VBS" /dstatus
  • Office 2016 (64-bit) on a 64-bit version of Windows
    cscript "C:Program FilesMicrosoft OfficeOffice16OSPP.VBS" /dstatus
3. You should now get a screen with some license details such as the license name, type and the last 5 characters of the Product Key.

Image


You can also change the Product Key via the OSPP.VBS script. Instead of using the /dstatus switch, you must use the /inpkey:value switch where you should replace value for your Product Key.

For example:
cscript "C:Program Files (x86)Microsoft OfficeOffice16ospp.vbs" /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX