Подтвердить что ты не робот

Есть ли способ поделиться кодом между приложениями UWP и приложениями WPF?

Чтобы быть ясным, я следую шаблону MVVM, и я хочу структурировать свой проект, чтобы я мог поделиться своим кодом модели между UWP-приложением и стандартным WPF-приложением. Код, который я хочу использовать, не имеет интерфейса. Мне не нравится мысль о поиске новых инструментов для замены тех, которые я использую в течение многих лет, которые занимаются определенными задачами, такими как ведение журнала, подключение к базе данных, ориентированной на документ, и т.д.

Я попытался начать писать UWP-оболочку вокруг некоторого кода, который у меня уже есть, и напрямую ссылаться на проект модели. Visual Studio отказалась это допустить, показывая мне сообщение об ошибке, в котором говорится: "Невозможно добавить ссылку на проект" ACK.Model ". То же самое произошло, когда я попытался поместить модель в универсальную библиотеку и ссылаться на нее из приложения WPF. Я не хочу делиться WPF-кодом. Только слой модели, не имеющий ссылки на библиотеки пользовательского интерфейса.

Это страшное предложение, потому что это означает, что если я хочу сделать что-то существенное, я должен выбрать либо перейти на 100% в UWP, либо остаться на 100% WPF. NewtonSoft.JSON может иметь универсальное распространение (ASP.NET MVC), но как насчет ElasticSearch.NET и других инструментов, необходимых для создания важных приложений?

Я нашел, где скрывался тип проекта "Portable Class Library". PCL позволят мне поделиться своим кодом в WPF и Universal приложениях, поскольку это был один из вариантов. Это решает простой случай части модели моего кода, но я (по-прежнему) не могу использовать некоторые из библиотек, которые я хочу. Мне все еще нужно большое количество библиотек, которые не имеют PCL.

4b9b3361

ОТВЕТЫ

Ответ 1

Примерно через год, с появлением Visual Studio 2017, существует более полное решение. Если вы нацеливаете свои библиотеки на .Net Standard, то библиотека совместима с приложениями .Net Core и монолитным целевым приложением .Net. Поддержка стандартных библиотек .Net и API-интерфейсов довольно полна, так же как и поддержка современных функций языка С#.

Теперь общий совет:

  • Целевой стандарт .Net для всех библиотек
  • Настройте подходящую платформу для вашего реального приложения. (UWP или WPF).

ПРИМЕЧАНИЕ. Если ваша библиотека должна взаимодействовать с библиотеками или приложениями C, вам необходимо проявлять особую осторожность, чтобы убедиться, что вы загрузили правильную версию.

Похоже, что есть решение, но оно должно быть принято всей цепочкой инструментов, которую вы хотите использовать. Когда Microsoft представила приложения Windows Store в Windows 8, они также представили портативную библиотеку классов (PCL). Цель PCL - обмен кодами между различными частями вашего приложения.

При создании PCL в Visual Studio 2015 вы можете указать типы API-интерфейсов, из которых вы хотите получить доступ:

  • Универсальные приложения
  • Mono
  • .Net Core 5
  • .Net 4.6

Это, конечно, ограничивает доступные API, но большинство из них вы хотите использовать, если это не связано с пользовательским интерфейсом. Существуют и другие ограничения:

  • Ваш проект может быть отредактирован только в Visual Studio 2015 или выше
  • У вас нет доступа к специальным каталогам из переменной среды (т.е. папке "Документы пользователя" и т.д.).
  • Вы не можете ссылаться на библиотеку, предназначенную только для одной из ваших целевых платформ (например, libgit2sharp и т.д.).
  • Невозможно просмотреть API для этого подмножества - MSDN нужно зайти на палку. MSDN обновила большую часть документации по API, но по-прежнему трудно понять, что относится к вашей PCL

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

Стек ASP.NET MVC был перенесен на использование PCL, поэтому вы можете напрямую использовать NewtonSoft.JSON, а также любые другие библиотеки, используемые этим приложением. Однако есть несколько библиотек, которые не были перенесены.

Эта схема заставляет вас думать о том, как вы хотите лучше интегрироваться. Ядро .Net Core 5, похоже, стабильно, но поддержка в нем находится в зачаточном состоянии. В текущем поколении Universal Apps по версии VS 2015 версии 1 напрямую используется .Net Core 5.

В Nuget есть несколько функций, которые в настоящее время не поддерживаются, хотя работа ведется:

  • Расширения MS Build (основные изменения в структуре MSBuild и project.json)
  • Установить/удалить скрипты (связанные с удалением концепции установки)
  • Содержимое (связанное с установкой/удалением, но на этом выполняется работа)
  • Преобразования содержимого (связанные с отсутствием установки/удаления)

Мне хотелось бы получить более полный ответ. Но это насколько я получил, когда обнаружил PCL и как он развился для текущей инфраструктуры.

Я создаю инструментарий для создания игр, который включает управление версиями сразу. Я хочу, чтобы иметь возможность развертывать игру в качестве приложения Windows 10 или как стандартное приложение WPF, но из-за библиотек, которые я использую для интеграции контроля версий, мне нужно создать редактор как стандартное приложение WPF. Я должен был быть немного творческим в создании общего кода и импортировании правильных библиотек.

Во-первых, моя иерархия проектов:

  • Project.Model(Portable Class Library)
  • Project.Model.Versioning(стандартная библиотека С#)
  • Mvvm.Toolkit(переносная библиотека классов)
  • Редактор (стандартное приложение WPF)

Я хочу, чтобы основной PCL мог загружать проект и десериализовать объекты, закодированные JSON. PCL имел доступ к System.IO, но на удивление это не то же самое, что определено в стандартной библиотеке С#. Вот как мне пришлось исправлять вещи:

  • После добавления ссылки на пакет NewtonSoft.JSON мне пришлось изменить целевую структуру в файле packages.config:

    <package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />

  • Все проекты, зависящие от моего класса Project.Model, должны были установить пакет `system.io.filesystem 'из nuget, чтобы объекты System.IO.FileInfo и т.д. были одинаковыми.

Хотя это определенно не панацея, это тоже не тупик. Я уверен, что есть больше ошибок, но это, по крайней мере, поможет с некоторыми проблемами.