standalone app что это

Текст объемный и рассчитан на:

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

0. Pay-for-Play

BCL располагается в GAC, откуда приложения загружают необходимые для работы зависимости.

Примеры компонентов, которые поставляются через NuGet:

Этот подход называется «pay-for-play»; другими словами, приложения загружают только ту функциональность, которая им необходима, но каждая такая функциональность содержится в отдельной сборке.

1. FDD vs SCD

В Standalone (SCD)-приложении все компоненты для выполнения (CoreCLR, CoreFX), а также сторонние библиотеки, то есть абсолютно все зависимости, поставляются вместе с самим приложением (чаще всего в одной папке).

Важно понимать, что Standalone-приложение привязано к определенной ОС и архитектуре (например, Windows 7 x64 или OSX 10.12 x64). Такой идентификатор называется Runtime identifier (RID). Для каждой ОС/архитектуры существует своя версия библиотеки Core CLR (и прочих нативных компонентов), поэтому для Standalone-приложений на этапе компиляции в свойстве RuntimeIdentifier нужно указывать параметры целевой системы (RID).

.NET Core Runtime устанавливается в папку C:\Program Files\dotnet:

Файлы фреймворка(-ов) хранятся в папке C:\Program Files\dotnet\shared.

Можно установить несколько версий фреймворка:

Для выполнения Portable-приложения необходимо запустить хост-процесс dotnet.exe и передать ему в качестве аргумента путь к управляемой сборке.

«C:\Program Files\dotnet» добавляется к значению переменной среды PATH, благодаря чему Portable-приложения теперь могут запускаться из командной строки:

В папке приложения (там, где находится [AppName].dll) должен лежать файл [AppName].runtimeconfig.json. В нём указаны имя и версия фреймворка, которые должны быть использованы для выполнения Portable-приложения. Например:

Этот файл является обязательным для Portable-приложений.

Имея вышеприведенную конфигурацию, компоненты среды выполнения будут загружены из папки C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0.

Уменьшение количества файлов объясняется тем, что в Core FX 1.0 отсутствовали многие библиотеки, поэтому они шли в составе приложения, как обычные зависимости. В Core FX 2.0 эти сборки были добавлены, поэтому они больше не поставляются с приложением, а берутся из папки фреймворка.

Наблюдается картина, противоположная Portable-приложениям — чем больше становится Core FX, тем больше файлов поставляется с приложением.

Рекомендации по выбору типа развертывания

5. Runtime Configuration Files

Файлы [AppName].runtimeconfig.json и [AppName].deps.json называют Runtime Configuration Files (*.deps.json называют dependency manifest file). Они создаются в процессе компиляции и содержат всю информацию, необходимую для запуска dotnet.exe и выполнения приложения.

dotnet.exe ([AppName].exe) использует файл [AppName].deps.json для определения абсолютных путей всех зависимостей приложения при его запуске.

Секция targets определяет платформу и дерево зависимостей для нее в формате

[ID зависимости (пакета)]/[версия]: <
dependencies: < список зависимостей (пакетов) данного пакета >,
относительные пути к управляемым и нативным файлам данного пакета
>

Для выполнения любого приложения, target должен обязательно содержать RID, например .NETCoreApp,Version=v1.1/win10-x64. Файл deps.json Standalone-приложения всегда один и содержит RID целевой платформы. Для Portable-приложения файлов deps.json два — один в папке фреймворка, второй в папке приложения. RID для Portable-приложений указан в файле [FrameworkName].deps.json в папке фреймворка. После того, как dotnet.exe определил фреймворк для выполнения приложения, он сперва загружает deps-файл этого фреймворка (например, C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0\Microsoft.NETCore.App.deps), а затем deps-файл приложения. Deps-файл приложения имеет более высокий приоритет.

Рассмотрим подробнее содержимое файла deps.json Standalone-приложения:

В свойстве dependencies перечислены зависимости (пакеты) конкретного пакета.
Свойство runtimeTargets используется в deps-файле Portable-приложения и определяет пути файлов библиотек для конкретного RID. Такие RID-specific библиотеки поставляются вместе с Portable-приложением в папке runtimes.

Свойства runtime и native содержат относительные пути управляемых (managed) и нативных библиотек соответственно. Свойство resources содержит относительные пути и локали локализованных сборок-ресурсов.

Пути относительны к NuGet package cache, а не deps-файлу.

Добавить сторонний deps-файл можно передав значение аргумента —additional-deps или переменную среды DOTNET_ADDITIONAL_DEPS.

Такая возможность доступна только для Portable приложений.

Значение аргумента может содержать полный путь к deps-файлу, а также путь к директории, где расположены общие deps-файлы. Внутри этой директории deps-файлы должны быть расположены в структуре \shared\[FX name]\[FX version]\*.deps. Например, shared\Microsoft.NETCore.App\2.0.3\MyAdditional.deps.json.

Такой подход использует Visual Studio для неявного добавления в проект Application Insights через файл
C:\Program Files\dotnet\additionalDeps\ Microsoft.AspNetCore.ApplicationInsights.HostingStartup\
shared\Microsoft.NETCore.App\ 2.0.3\ Microsoft.AspNetCore.ApplicationInsights.HostingStartup.deps.json

Когда dotnet.exe (MyApp.exe) определяет пути зависимостей приложения, для каждой отдельной библиотеки составляется список из runtime- и native-путей.

6.1. Запуск приложения
выполняется при помощи мультплексора (muxer) из командной строки (одинаково на любой ОС).

6.2. [corehost] Поиск и загрузка Framework Resolver (hostfxr.dll)
На этом этапе dotnet.exe идет в папку [own directory]/host/fxr/. Для Portable-приложений эта библиотека расположена в общей папке C:\Program Files\dotnet\host\fxr\[FXR version]\hostfxr.dll. Если версий будет несколько, dotnet.exe будет всегда использовать последнюю.

После загрузки hostfxr.dll (Framework Resolver) процесс запуска переходит в рамки этой библиотеки.

6.3. [hostfxr] Определение режима выполнения (standalone, muxer, split/FX)
Первая задача hostfxr — определить режим, в котором будет работать хост процесс и таким образом тип приложения — Portable (FDD) или Standalone (SCD). В Portable (FDD)-режиме он также определяет: это запускаемое приложение или команда SDK.

Также для Portable (FDD)-приложения hostfxr определяет фреймворк (.NET Core Runtime), откуда будут загружены компоненты для выполнения.

Алгоритм проверки очень простой — если в папке, откуда был запущен мультиплексор [AppName].exe (в нашем случае dotnet.exe), отсутствует coreclr.dll или [AppName].dll, то приложение Portable. Если один из этих двух файлов существует, то далее идет проверка — приложение Portable (split/FX) или Standalone. Если существует [AppName].dll, то приложение Standalone, иначе — Portable (split/FX).

При запуске в таком режиме можно явно указать пути к файлам конфигурации:
—depsfile

которые будут использованы вместо файлов в папке приложения.

На текущем этапе hostfxr определяет (по данным файла конфигурации), является ли приложение Portable или Standalone.

После загрузки файлов конфигурации и определения режима hostfxr определяет папку фреймворка (.NET Core Runtime).

Для этого hostfxr сначала определит, какие версии установлены в папке shared, а затем выберет из этого списка релиз-версию, с учетом значений в [AppName].runtimeconfig.json.

При выборе версии учитывается параметр Roll Forward On No Candidate Fx, который указывает строгость соответствия заданной версии и имеющихся на машине.

6.5. [hostfxr] Поиск и загрузка hostpolicy.dll
На текущем этапе всё готово для определения путей runtime-компонентов. Этой задачей занимается библиотека hostpolicy.dll, которая называется Host library.

Процесс поиска hostpolicy.dll заключается в последовательных проверках различных локаций. Но сначала определяется версия hostpolicy из deps-файла фреймворка (напр. C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0\Microsoft.NETCore.App.deps). В этом файле будет найден пакет с именем Microsoft.NETCore.DotNetHostPolicy и взята его версия.

Если файл не был найден на предыдущем этапе, hostpolicy.dll будет найдено в папке фреймворка.

Как только опеределена hostpolicy.dll, hostfxr загружает эту библиотеку и передает ей управление.

6.6. [hostpolicy] Определение списка зависимостей
Библиотека hostpolicy.dll отвечает за определение абсолютных путей всех зависимостей приложения.

Прежде всего hostpolicy создаст компонент под названием Dependencies Resolver, который в свою очередь загрузит два deps-файла — файл фреймворка и файл приложения.

Сперва загружается список из deps-файл фреймворка, где будут определены такие зависимости, как CoreCLR и библиотеки CoreFX. Затем список из deps-файла приложения, в котором указаны сборки нашего приложения и их зависимости.

Для каждого deps-файла Dependency Resolver составляет список всех зависимостей для указанной runtimeTarget.

Для каждого пакета сначала составляется список файлов из всех секций runtimeTargets (RID specific зависимости), далее — список всех файлов из секций native и runtime. Такой объединенный список относительных путей всех зависимостей в условном формате
ID пакета — RID — тип asset’а (runtime, native) — пути к файлам называется Target assets.

После того, как были составлены эти два списка файлов зависимостей (RID и не RID), выполняется процесс под названием Reconciling libraries with targets (согласования). Он заключается в том, что для каждого пакета из секции libraries проверяется, существует ли RID specific-файлы, которые должны переопределить обычные.

6.7. [hostpolicy] Определение путей TPA, Core CLR и CLR Jit
Далее Dependency resolver составляет список абсолютных путей файлов управляемых сборок — зависимостей приложения. Этот список называется TPA (Trusted Platform Assemblies) и передается Core CLR для настройки AppDomain. Также составляется список абсолютных путей директорий, в которых находятся остальных файлы зависимостей (кроме coreclr, corejit).

Определение абсолютных путей управляемых сборок происходит путем поиска файлов в Probe paths (путей зондирования). По умолчанию их два — папка фреймворка и папка приложения, и они основаны на расположении deps-файлов. Также можно добавить дополнительные пути:

1) передав аргумент —additionalprobingpath, например
—additionalprobingpath %UserProfile%\\.nuget\\packages

2) указав в файле [AppName].runtimeconfig.json (приоритет ниже, чем у аргумента), например

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

После составления списка TPA, определяются пути CoreCLR и CLRJit.

При отсутствии deps-файла приложения, dotnet.exe вначале попытается найти эти библиотеки в [app directory]\lib\. При обычном выполнении пути берутся из папки фреймворка (отбросив относительный путь и взяв только имя файла).

Устанавливаются следующие настройки CoreCLR:

Процесс запуска Standalone-приложения отличается от Portable только начальным этапом, а также местоположением компонентов, которые по умолчанию должны располагаться в папке приложения.

Источник

Standalone app что это

VST (Virtual Studio Technology) – формат звуковых плагинов, внедрённый фирмой Steinberg. Формат распространён довольно широко и многие знают, что это такое и с чем его едят… Но до сих пор на форумах вижу посты типа: «Что такое VST?» или «Я установил VST инструмент, а он не работает. Даже ярлыка на рабочем столе и exe’шника у неё нету…» и т.д Итак, в двух словах: что это такое и как работает.

Что такое Vst инструменты (VSTi).

Источник звука, управляемый по midi. Это может быть Синтезатор, Сэмплер или Ромплер. Для того, чтобы Vst плагин функционировал, нужна хост программа, с помощью которой вы получите доступ к нему.
Всё просто: сначала устанавливаете хост программу (например: Sonar или Cubase, Nuendo, Fruity Loops, Logic и т.д. и т.п.). Затем, устанавливаете сам Vst инструмент, после его инсталляции, запускаете хост программу и пользуетесь.

Немного о содержании самих плагинов.

Standalone.

Это самостоятельные версии плагинов, не требующие хост-программы. Вот у них – совсем всё просто: после инсталляции появляется и экзэшник (exe файл), и ярлык на рабочем столе. Запустил и работай. Один недостаток. Вы можете легко играть звуками установленного инструмента, но чтобы записать то, что играете – всё равно потребуется хост программа 

Vst эффекты.

Как я уже говорил. ВСТ инструменты – это источники звука. Vst эффекты звуков не издают, они обрабатывают входящий звуковой поток. Всё остальное справедливо из написанного выше.

Dx, Dxi

Dxi инструменты и эффекты – альтернатива VST, формат разработанный Microsoft. Кардинальных отличий никаких, форматы идентичны по многим параметрам. Многие программы в равной степени поддерживают как ВСТ, так и Dxi плагины, кроме того, есть Vst адаптеры, легко адаптирующие их для работы в Dxi совместимых хост-программах…
Также, в оболочке при инсталляции многих плагинов есть меню, в котором вы можете выбирать, в каком именно формате устанавливать Plugin.

Эта запись была опубликована 09.06.2008 в 17:36. В рубриках: База знаний. Вы можете следить за ответами к этой записи через RSS 2.0. Также, вы можете пройти в конец страницы и оставить свой комментарий.

Источник

Авторизация для standalone-приложений

Рады сообщить Хабрасообществу о запуске возможности использования VK API для standalone-приложений.

С сегодняшнего дня разработчики могут создавать различные Desktop-приложения, в том числе приложения для мобильных платформ (iPhone, Android и др.), виджеты и расширения для веб-браузеров. Подробная документация размещена в официальной группе — авторизация теперь не обязательна.

Помимо этого, команда «ВК» расширила набор API, добавив в него доступ к личным сообщения, статусам, стенам и фотографиям. Такая информация понадобится, вероятно, не только разработчикам мобильных клиентов «ВКонтакте». Примером работы с этими данными является наша веб-версия для iPhone и Android:

Однако пока расширенным доступом могут воспользоваться только ограниченное количество приложений. Заявки на получение доступа к этим функциям мы принимаем по электронной почте:

В предыдущих постах было множество вопросов про использование открытых стандартов авторизации. Появление Open API — это как раз первый шаг к открытым стандартам. Так, в ближайшем будущем появится поддержка oAuth и протокола XMPP.

До выходных постараемся порадовать разработчиков еще несколькими нововведениями.

Источник

Создание приложения ВКонтакте с типом «Standalone-приложение». Пошаговая инструкция

Для создания приложения ВКонтакте с типом Standalone-приложение перейдите по ссылке http://vk.com/editapp?act=create.

В открывшемся окне необходимо выбрать тип приложения Standalone-приложение и указать произвольное название вашего приложения.

После заполнения всех полей нажмите кнопку Подключить приложение. ВКонтакте попросит вас подтвердить действие отправив вам код доступа в СМС. Получив этот код введите его в соответствующее поле и нажмите «Отправить код». Если все сделано верно, то перед вами откроется окно с настройками созданного приложения. Вам необходимо перейти на вкладку Настройки и выставить в поле Open API значение Включен. На странице появится дополнительный блок настроек Open API. В этом блоке вам необходимо заполнить поля Адрес сайта и Базовый домен. В поле Адрес сайта укажите адрес вашего сайта (магазина). Например, mysite.ru или shop.mysite.ru или mysite.ru/shop/vk. В поле Базовый домен укажите основной домен вашего сайта. Для всех вышеприведенных примеров базовым доменом будет являться mysite.ru. В поле Состояние выберите Приложение включено и видно всем.

Остальные поля можно ставить незаполненными.

Поздравляем, ваше приложение ВКонтакте с типом Standalone-приложение создано! Вам останется лишь скопировать значение полей ID приложения и Защищенный ключ приложения в соответствующие поля окна настроек плагина.

Источник

Makag

Своё Standalone-приложение и три полезных скрипта.

Предупреждение от 08 мая 2017: данная тема устарела.

Всё что написано ниже — в значительной степени утратило актуальность.

Пара слов о том, как создать своё Standalone-приложение и три полезных скрипта.

Своё Standalone-приложение для вКонтакте — вещь нужная и полезная, потому что с ним можно делать всякие грязные штуки.

Создать приложение для вКОнтакте можно по ссылке vk.com/apps?act=manage

Настройки в общих случаях минимальны:

«Защищённый ключ» наверное нужен иногда, но пока что он мне не пригодился. Самое важное — это ID приложения, которое используется для получения access_token.

О вариантах получения acess_token от различных приложений:

Какое-то чужое приложение

Вроде бы айпад, токен рабочий был

Чужое приложение вечного онлайна (hiw/ru вроде бы)

ВКонтакте для Windows

ВКонтакте для iPhone

ВКонтакте для iPad

ВКонтакте для Android

ВКонтакте для Windows Phone

ВКонтакте для Windows

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

Все скрипты отлично работают с одним и тем же токеном.

Online

Incoming Friends Add

Outcoming Friends Chancel

Чтение из файла в буфер и передача содержимого буфера в переменную

Источник