Все правильно - незачем. Но, считаю важным, указать, что она уже поддерживает проверку и установку .net core 3.1, что, конечно, не является поводом ее использовать)
Добрый день! Спасибо за ваш комментарий и внимательное прочтение статьи. На счет Inno Setup я не писал, что он позволяет создавать msi файлы, но, пожалуй, об этом следовало указать более явно.
На счет, wixproj - да, это обычный сценарий MSBuild со всеми вытекающими.
По поводу документации к Wix. Вопрос, конечно, дискуссионный, но официальная документация не описывает best practices, не содержит примеры готовых инсталляторов, а читая описание к тегу не всегда очевидно куда его необходимо вставить. Ну и, на мой взгляд, документация написана для людей, которые знакомы с подсистемой Windows Installer - не думаю, что среди людей, впервые столкнуышихся с технологией Wix, таких большинство.
На счет DiskPromt - еще раз отдельное спасибо за ваш комментарий! Когда работал над созданием своего инсталлятора столкнулся с проблемой, что проект wix не собирался, когда я не указывал этот атрибут. И с тех пор был уверен, что DiskPromt является обязательным (тем более, что практически во всех примерах, которые мне попадались в сети у Media был описан DiskPromt). Но, после вашего комментария специально во всех проектах проверил, что будет, если его удалить - о чудо, все они собрались корректно и произвели установку/удаление продуктов корректно!
Чтобы не вводить читателей в заблуждение, внес коррективы в статью.
По большому счету, для проверки установленных пакетов .net Wix и не нужен какой-то специализированный функционал. Проверку можно осуществить путем поиска по реестру соответствующего ключа (используйте RegistrySearch - https://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html). Далее, в зависимости от результата поиска можете или выкинуть пользователю предупреждение о необходимости установки соотвествующего пакета, или отменить установку. Если же стоит задача минимизации участия пользователя в процессе установки, то наилучшим вариантом будет использование проекта типа Wix Bootstrapper, который позволяет произвести установку нескольких пакетов: основной .msi с вашим продуктом + сопутствующее окружение, которое также может быть установлено по условию.
В целом, Wix в комплекте поставки имеет инструменты для проверки и установки .net framework (NetFx), но в 3-й версии они не работают с .net core, а в 4-й только до .net core 3.1 (но я бы не рекомендовал вести разработку с использованием Wix v4 ввиду слабой документации и отсутствия широкого пользовательского опыта), поэтому наиболее оптимальный вариант - это работа с Bootstrapper.
Да и сейчас, на самом деле, ситуация с документацией к Windows Installer и инструментами, которые должны упростить жизнь, не сильно поменялась. Очень доставляют ситуации, когда нужно добавить кастомный скрипт, который должен быть запущен на определенном этапе работы инсталлятора с возможностью откатить внесённые изменения. А попытки завязать логику на результате выполнения какого-нибудь CustomAction могут отправить разработчика с низким содержанием стали в нервных клетках на Канатчикову дачу.
Не могу не согласиться - код с использованием Wix# действительно выглядит гораздо более удобочитаемым, да и описывать инсталляционные пакеты с его использованием гораздо проще. Однако, главная проблема Wix# его недостаточно широкая распространенность, что создает риски при разработке крупных проектов, требующих длительной поддержки и глубокой кастомизации процесса установки. К тому же, зачастую, заказчик имеет собственные наработки и решения, которые должны быть интегрированы в конечный продукт, что вынуждает ориентироваться на существующий стек.
Я когда читал статью, у меня было ощущение, что ее 100% писал мой лид про опыт введения меня в проект))
Автор, у тебя отличный слог и толковые структурированные мысли — продолжай в том же духе!
Спасибо!
Гуглим "XSLT"
Я не вижу существенных преимуществ использования данного подхода над предложенным мной.
Гуглим "SAX parser"
Интересно, чем это саксафон, написанный под Java, превосходит XmlReader? Особенно в контексте текущей задачи?
PS Не очень вот это
Сорян, пропустил слово. Я хотел сказать, что не очень понятно вот это (имея ввиду ваш комментарий). Просто я не очень понял из какого файла в какой вы предлагаете конвертировать? Из odt в docx, txt, rtf? А зачем?
Доброе утро!
Бесспорно вы правы. Более того, в своей статье я об этом не только говорю, но и иллюстрирую.
Но, то, в каком виде хранятся данные в XML, расположенной внутри ODT документа, делает невозможным их использование для автоматизированного парсинга. Поэтому, прежде, чем скармливать такой файл парсеру, его нужно обработать, повыкидывать всякий "мусор" и навести марафет.
Также, если вы внимательно читали статью, то не могли не обратить внимание, что я рассматривал не только обработку ODT файла, но и иллюстрировал методы работы с XML документом в условиях, когда заведомо не только не известен размер обрабатываемого файла, но и когда такой файл может быть бесконечно огромным, а оперативная память лимитированной.
PS Не очень вот это:
Давайте лучше конвертировать документ в файл.
Или наоборот.
В данной статье под неопределенным количеством файлов понимается неизвестное количество документов, которые нужно преобразовать, в самом прямом смысле. Например, один источник может потребовать от нас преобразование 2-3 файлов, а другой — несколько сотен. Опираясь на собственный опыт, могу сказать, что еще не было ситуации, при которой приходилось конвертировать сильно больше 100 документов для одного из источников. В целом, каких-то проблем это не вызывало.
В моем кейсе, документы сильно отличались по количеству страниц: от 1 до 100 страниц. Языки документов: русский и английский — других не встречали.
Я не готов дать ответ на этот вопрос. Так как моей задачей являлось подготовка текста для последующего парсинга, то вопросами обработки графики, сохранения колонтитулов и иными вопросами оформлениями я не занимался. Однако, вы сами можете попробовать поиграться с b2xtranslator.
Спасибо!
Хороший вопрос. EPPlus, на сколько мне известно, не работает с xls, а бесплатная версия Spire имеет ограничения, которые исключили возможность ее использования. Поэтому с указанными библиотеками я, к сожалению, не работал.
Отличается тем, что, если данные приходят в потоке (например, через get-запрос), то нам придётся записать xls файл на диск, сконцентрировать в другой файл xlsx с помощью другого языка, а потом продолжить работать на C# с файлом xlsx.
В предложенном мной варианте можно произвести конвертацию без создания каких-либо файлов и подключения дополнительных сервисов.
Считайте, что это просто один из вариантов решения проблемы, который мне, в результате, подошёл больше.
Установка libreoffice — это решение из разряда установки Interop, которое имеет аналогичные недостатки:
установка дополнительного, далеко не самого легкого, ПО
требуется время на запуск
прожорливость по памяти
А так, такое решение вполне имеет право на существование, однако, в таком случае, логичнее использовать решения на других языках, решающих данную проблему: это как минимум будет менее ресурсоемким решением.
Конкретно в моем случае, есть пользователи программного продукта компании. Вот этим пользователям, для удобства работы с указанным ПО, необходимо иметь возможность получить xml-документ из обрабатываемого текстового документа. При этом, содержимое должно быть заключенным в соответствующие теги таблиц, абзацев и списков.
Вот и все. Не исключено, что кто-то еще сталкивался и столкнется с аналогичной задачей.
Все, она появилась: к своему удивлению столкнулся с проблемой исчезновения части текста из статьи при публикации. Почему так происходит, честно говоря, не особо пока разобрался: решал проблему путем добавления/удаления пустых абзацев. Подозреваю, что причина проблемы кроется в использовании Markdown и особенностях его интерпретации
во-первых, при таком подходе теряется возможность работы с потоком — нам необходимо будет записывать данные в файл, а потом этот файл конвертировать сторонним приложением.
во-вторых, разве плохо, если в сети появится информация о том, как получить из xls xlsx использую только C#, тем более, что на форумах периодически такие вопросы всплывают, но, к сожалению, остаются без ответа?
Проблема в том, что роль Apache POI фактически выполняют две либы: OpenXML, про которую я немного рассказал вот в этой статье и NPOI, про которую говорится в данном посте. При этом, библиотека NPOI синтаксически, как выяснилось, очень близка к джавовой Apache POI.
Все правильно - незачем. Но, считаю важным, указать, что она уже поддерживает проверку и установку .net core 3.1, что, конечно, не является поводом ее использовать)
Добрый день!
Спасибо за ваш комментарий и внимательное прочтение статьи.
На счет Inno Setup я не писал, что он позволяет создавать msi файлы, но, пожалуй, об этом следовало указать более явно.
На счет, wixproj - да, это обычный сценарий MSBuild со всеми вытекающими.
По поводу документации к Wix. Вопрос, конечно, дискуссионный, но официальная документация не описывает best practices, не содержит примеры готовых инсталляторов, а читая описание к тегу не всегда очевидно куда его необходимо вставить. Ну и, на мой взгляд, документация написана для людей, которые знакомы с подсистемой Windows Installer - не думаю, что среди людей, впервые столкнуышихся с технологией Wix, таких большинство.
На счет DiskPromt - еще раз отдельное спасибо за ваш комментарий! Когда работал над созданием своего инсталлятора столкнулся с проблемой, что проект wix не собирался, когда я не указывал этот атрибут. И с тех пор был уверен, что DiskPromt является обязательным (тем более, что практически во всех примерах, которые мне попадались в сети у Media был описан DiskPromt). Но, после вашего комментария специально во всех проектах проверил, что будет, если его удалить - о чудо, все они собрались корректно и произвели установку/удаление продуктов корректно!
Чтобы не вводить читателей в заблуждение, внес коррективы в статью.
Спасибо!
Добрый день!
По большому счету, для проверки установленных пакетов .net Wix и не нужен какой-то специализированный функционал. Проверку можно осуществить путем поиска по реестру соответствующего ключа (используйте RegistrySearch - https://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html). Далее, в зависимости от результата поиска можете или выкинуть пользователю предупреждение о необходимости установки соотвествующего пакета, или отменить установку.
Если же стоит задача минимизации участия пользователя в процессе установки, то наилучшим вариантом будет использование проекта типа Wix Bootstrapper, который позволяет произвести установку нескольких пакетов: основной .msi с вашим продуктом + сопутствующее окружение, которое также может быть установлено по условию.
В целом, Wix в комплекте поставки имеет инструменты для проверки и установки .net framework (NetFx), но в 3-й версии они не работают с .net core, а в 4-й только до .net core 3.1 (но я бы не рекомендовал вести разработку с использованием Wix v4 ввиду слабой документации и отсутствия широкого пользовательского опыта), поэтому наиболее оптимальный вариант - это работа с Bootstrapper.
Вооот! Про масонов прямо в точку!
Да и сейчас, на самом деле, ситуация с документацией к Windows Installer и инструментами, которые должны упростить жизнь, не сильно поменялась. Очень доставляют ситуации, когда нужно добавить кастомный скрипт, который должен быть запущен на определенном этапе работы инсталлятора с возможностью откатить внесённые изменения. А попытки завязать логику на результате выполнения какого-нибудь CustomAction могут отправить разработчика с низким содержанием стали в нервных клетках на Канатчикову дачу.
Не могу не согласиться - код с использованием Wix# действительно выглядит гораздо более удобочитаемым, да и описывать инсталляционные пакеты с его использованием гораздо проще. Однако, главная проблема Wix# его недостаточно широкая распространенность, что создает риски при разработке крупных проектов, требующих длительной поддержки и глубокой кастомизации процесса установки. К тому же, зачастую, заказчик имеет собственные наработки и решения, которые должны быть интегрированы в конечный продукт, что вынуждает ориентироваться на существующий стек.
Я когда читал статью, у меня было ощущение, что ее 100% писал мой лид про опыт введения меня в проект))
Автор, у тебя отличный слог и толковые структурированные мысли — продолжай в том же духе!
Спасибо!
Комментарий удален, так как является ответом к комментарию выше (пользователь не успел выпить кофе и промазал).
Доброе утро!
Бесспорно вы правы. Более того, в своей статье я об этом не только говорю, но и иллюстрирую.
Но, то, в каком виде хранятся данные в XML, расположенной внутри ODT документа, делает невозможным их использование для автоматизированного парсинга. Поэтому, прежде, чем скармливать такой файл парсеру, его нужно обработать, повыкидывать всякий "мусор" и навести марафет.
Также, если вы внимательно читали статью, то не могли не обратить внимание, что я рассматривал не только обработку ODT файла, но и иллюстрировал методы работы с XML документом в условиях, когда заведомо не только не известен размер обрабатываемого файла, но и когда такой файл может быть бесконечно огромным, а оперативная память лимитированной.
PS Не очень вот это:
Спасибо за вопрос!
Спасибо!
Хороший вопрос. EPPlus, на сколько мне известно, не работает с xls, а бесплатная версия Spire имеет ограничения, которые исключили возможность ее использования. Поэтому с указанными библиотеками я, к сожалению, не работал.
Отличается тем, что, если данные приходят в потоке (например, через get-запрос), то нам придётся записать xls файл на диск, сконцентрировать в другой файл xlsx с помощью другого языка, а потом продолжить работать на C# с файлом xlsx.
В предложенном мной варианте можно произвести конвертацию без создания каких-либо файлов и подключения дополнительных сервисов.
Считайте, что это просто один из вариантов решения проблемы, который мне, в результате, подошёл больше.
Установка libreoffice — это решение из разряда установки Interop, которое имеет аналогичные недостатки:
А так, такое решение вполне имеет право на существование, однако, в таком случае, логичнее использовать решения на других языках, решающих данную проблему: это как минимум будет менее ресурсоемким решением.
Да, все верно. Библиотека способна работать как со старыми файлами, так и с новыми.
Конкретно в моем случае, есть пользователи программного продукта компании. Вот этим пользователям, для удобства работы с указанным ПО, необходимо иметь возможность получить xml-документ из обрабатываемого текстового документа. При этом, содержимое должно быть заключенным в соответствующие теги таблиц, абзацев и списков.
Вот и все. Не исключено, что кто-то еще сталкивался и столкнется с аналогичной задачей.
Мой косяк. Конечно, бесспорно, информация хранится в бинарном виде. Спасибо за ваш комментарий: статью поправил.
Все, она появилась: к своему удивлению столкнулся с проблемой исчезновения части текста из статьи при публикации. Почему так происходит, честно говоря, не особо пока разобрался: решал проблему путем добавления/удаления пустых абзацев. Подозреваю, что причина проблемы кроется в использовании Markdown и особенностях его интерпретации
Бесспорно проще. Но,
Проблема в том, что роль Apache POI фактически выполняют две либы: OpenXML, про которую я немного рассказал вот в этой статье и NPOI, про которую говорится в данном посте. При этом, библиотека NPOI синтаксически, как выяснилось, очень близка к джавовой Apache POI.
Спасибо!
Нужно будет внимательно ее изучить.