C # в VS2005: проект устройства может предназначаться и для полной структуры и для CF? - PullRequest
4 голосов
/ 06 октября 2009

Мы разрабатываем с Compact Framework для устройства под Visual Studio 2005. Однако мы также хотим сделать эмулированную версию программного обеспечения, работающую на ПК (желательно выбираемую через конфигурацию сборки).

Однако, похоже, что файл .vsproj специфичен для устройств; нет никакого способа использовать полную платформу .NET, например, просто изменив цель.

Есть ли способ обойти это? Я полагаю, что мы можем запустить компактную среду на ПК, но все же проект не может быть нацелен, например, на процессор ARM, иначе я предполагаю, что JIT-компилятор сгенерирует непригодный код для ПК?

Ответы [ 7 ]

3 голосов
/ 06 октября 2009

Вы можете запустить приложение Compact Framework в обычной Windows (возможно). Однако есть две основные потенциальные проблемы.

Во-первых, поскольку определенные свойства формы и элемента управления, присутствующие в полной платформе, отсутствуют в компактной платформе, ваше приложение будет вести себя немного странно в Windows. Например, в полных формах каркаса есть свойство StartPosition, которое определяет, где формы появляются на экране при их первом создании. Это свойство не существует в компактной среде (по очевидным причинам), поэтому при запуске приложения CF в обычной Windows формы выбирают значение StartPosition по умолчанию, равное WindowsDefaultLocation, что означает, что настройка свойств Left и Top формы имеет не влияет на то, где они появляются, поэтому формы всплывают везде.

Во-вторых, любые вызовы Windows API PInvoke в CF должны ссылаться на «coredll», тогда как те же вызовы в полной структуре ссылаются на «user32», «winmm» и т. Д. Одним из способов решения этой проблемы является следующее: *

[DllImport("winmm.dll", EntryPoint="waveOutReset")]
private static extern int waveOutResetFULL(IntPtr hWaveIn);
[DllImport("coredll.dll", EntryPoint="waveOutReset")]
private static extern int waveOutResetCF(IntPtr hWaveIn);
public static int waveOutReset(IntPtr hWaveIn)
{
    if (Environment.OSVersion.Platform == PlatformID.WinCE)
    {
        return waveOutResetCF(hWaveIn);
    }
    else
    {
        return waveOutResetFULL(hWaveIn);
    }
}

Есть и другие способы сделать это.

Что касается первого набора проблем, одним из решений является установка свойств, отсутствующих в компактной структуре, с помощью Reflection, когда приложение работает в обычной Windows. Я думаю, что лучшей альтернативой является инкапсуляция всех элементов вашего пользовательского интерфейса в виде UserControls, каждый из которых размещается на одном «главном» UserControl, который создает и удаляет другие элементы UserControl по мере необходимости. Затем вы можете разместить свой единственный «главный» UserControl в одном экземпляре формы.

Кстати, я написал приложение, которое делает именно это (работает в Windows и на устройствах Windows Mobile) для крупного судостроителя, и оно все еще используется. Фактически, способность этого приложения работать в обеих средах буквально спасла его жизнь, когда использование мобильных устройств на верфи было временно приостановлено по соображениям безопасности.

2 голосов
/ 06 октября 2009

Джаред прав, вы не можете заставить Студию это сделать (ну, конечно, если вы не потянете за волосы и не получите очень хрупкие конечные результаты). Кроме того, есть кое-что еще, что стоит отметить.

Во-первых, MSIL не зависит от процессора, поэтому он не будет «генерировать непригодный для использования код» с этой точки зрения. ARM IL идентичен x86 IL (или MIPS или SH3 в этом отношении). Фактически, сборки CF могут напрямую использоваться в полной структуре, потому что они с возможностью перенаправления (обратное неверно, поскольку CF не реализует все коды операций, которые использует рабочий стол).

Тем не менее, довольно редко иметь приложение CF, которое не вызывает API для конкретного устройства, будь то P / Invoke для coredll.dll или сборка для конкретного устройства, например Microsoft.WindowsMobile.dll. В этих случаях сборка будет выполняться только во время выполнения (не может найти собственную DLL) или при загрузке (не может найти ссылочную сборку).

Вы можете (иногда только с большими усилиями) обойти эти проблемы. Вам решать, стоит ли это делать. Мой опыт таков, что, вообще говоря, это не так. Это гораздо меньше усилий, просто использовать эмулятор или виртуальный ПК под управлением CE.

1 голос
/ 06 октября 2009

У меня есть связанная проблема в некотором открытом исходном коде, который я поддерживаю; У меня есть отдельные файлы проекта, но чтобы уменьшить объем обслуживания, я использую созданный вручную файл проекта, который автоматически включает все файлы * .cs в дереве проекта:

<ItemGroup>
  <Compile Include="..\protobuf-net\**\*.cs" />
</ItemGroup>

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

1 голос
/ 06 октября 2009

Я думаю, что единственный способ сделать это - иметь 2 файла проекта для одного проекта. Тот, который является нормальным CF, и тот, который работает так же, как обычное приложение .Net. Наличие целевого файла проекта и для CF, и для полной структуры не поддерживается.

0 голосов
/ 21 октября 2009

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

Полный csproj имеет исходные файлы, а компактный csproj имеет ссылки на эти файлы. Всякий раз, когда класс вызывает метод, которого нет в компакте, я делаю это частичным классом и рассматриваемыми методами в файлах * .pc.cs и * .ppc.cs.

Объедините это с концепцией, опубликованной Marc Gravell (для автоматического включения файлов из полного проекта), и поддерживать ее будет довольно легко.

0 голосов
/ 10 октября 2009

Обходной путь НЕ использовать VS. Отличным примером является программное обеспечение Basic4PPC (см. здесь ).

Это язык программирования в стиле VB.Net (для всех приложений, написанных на нем, требуется Compact Framework, установленный на устройстве). Однако дело в том, что вы используете только одну IDE с тем же исходным кодом, но вы можете скомпилировать свои приложения для запуска на настольном компьютере или на устройстве. Доступно много пользовательских библиотек, и для определенных задач может потребоваться использовать определенную библиотеку для настольного компьютера или устройства.

Программа была написана на C #. Это стоит посмотреть.

0 голосов
/ 06 октября 2009

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

Как мудро заявляет MusiGenesis, одной из основных областей будет ваш P / Invokes. У меня также есть очень неполный список ошибок Compact Framework / Full Framework, которые собираются здесь :

...