Comments
Могу сказать, зачем это лично мне :)

Разрабатывая свой продукт для Windows Mobile, сталкиваешься с тем, что появляются люди, которые бы хотели пользоваться твоим продуктом на десктопе. Серьёзно. Полностью написать другое приложение, положим, просто нет ни времени, не желания. В моём случае, я потратил около 5 часов на то, чтобы всё собралось и заработало. Учитывая, что на разработку в целом было потрачено более 800 часов, можно сказать, что десктоп версия появилась даром.

Безусловно, можно сказать, что от десктоп приложений люди могут ждать большего или совсем другого, но, поверьте, это действительно удобно. Более того, даже тестировать десктоп версию проще, чем мобильную, т.к. не нужно поднимать эмулятор. Естественно, что особенности (или косяки) фреймворков не удастся отловить, но вот ошибки в логике приложения — легко! Доказано неоднократными багрепортами от пользователей десктоп версии.
Отписал в личку. Я просто через некоторое время напишу о приложении отдельную статью, не хочу раньше времени светить.
1$ за один символ с личного сообщения, символы отдаются в random порядке :D
остается надеятся, что автор топика был не слишком многословен :)
UFO landed and left these words here
Интересно, но вы немного пошли по своему пути.

Когда мы делали проект под windows mobile 6, никаких извращений с csproj файлами не делали. Проект собирался и выполнялся как есть.

По поводу отладки вы написали довольно интересный вариант, но простое решение лежит на поверхности:
либо ставим эмулятор нужной платформы (windows mobile 5 входит в комплект со студией, wm6 надо качать) либо используем wm девайс. Далее идём tools->connect to device, выбираем и нажимаем F5 (start debugging). Студия сама деплоит проект на выбранную платформу и подключается к процессу. Всё работает на ура.

При портировании на десктоп довольно редко используются те же формы, поскольку на большом брате разрешение побольше и намного больше возможностей визуального оформления. На выход приходит паттерн MVC: контроллеры, бизнес логика и уровень БД у вас общие, только делаете разные формы для разных платфор и никакого геморроя с #if #endif.

Да, и SQL Server Compact работает на десктопе, т.е. не придётся переписывать DA при портировании на десктопный вариант.
Отладка в эмуляторе — это одно, отладка десктопной сборки — другое. Эмулятор меня не устраивает тем, что даже на 2.5ГГц Core2Duo приложение визуально работает несколько хуже, чем на живом дивайсе :)

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

Про формы — в моём конкретном случае так сложилось, что у меня полностью свой GUI фреймворк, поэтому на десктопе просто используется VGA-скин, а весь внешний вид фактически такой же, как на дивайсе — поэтому мне вообще не нужно делать разные формы для разных платформ, только немного #if #endif.
А в чём проблема отладки версии для десктопа? Опять же, из моего опыта, никаких танцев с бубнами/конфигурациями не было. Запускаете и дебажите. Или, может, я что-то не так делал?
Хм. Проект, изначально созданный для смарт-дивайса, должен быть куда-то задеплоен, чтобы автоматически началась отладка по F5. Деплоиться ему можно только в выбранный из списка дивайс. Без описанного в статье хака, в списке либо реальный дивайс (подключённый через ActiveSync), либо эмулятор.

Я так понимаю, что если проект отдельно сделать для десктопа и использовать общий с мобильным устройством BLL, то тогда да, оттуда в эмулятор вообще никак не попасть. Но у меня-то соль в том, что я только таргет при сборке меняю, а файл проекта один, общий.

Возможно, у Вас на других этапах были танцы с бубном, но Вы подзабыли? Пока не вижу другого объяснения.

Короче говоря, то, о чём Вы говорите, больше похоже на общий BLL и абсолютно разный GUI.
Изначально мы сделали wm приложение с 3-х слойной архитектурой. Когда потребовалось портировать под десктоп — создали новый UI, остальные компоненты не трогали.
Также было 2 проекта для запуска wm и десктоп приложений. Отсюда никаких бубнов при дебаге не было. Нужно поработать на wm — запускаем wm проект, и наоборот.

Вы просто по-другому это реализовали, отсюда и небольшие манипуляции с конфигами.
Да, именно. В моём опыте ценно, что UI полностью общий, т.е. трудозатраты на поддержку двух платформ минимальны.
и, в-седьмых, коммерческие пользовательские приложения практически никогда (не припоминаю ни одного, честно говоря) не пишутся на .NET CF ;)
Если уточнить что под «коммерческими пользовательскими приложениями» вы имеете ввиду шареваре и прочие прикладные софтины рассчитанные на широкий круг юзеров, то с вашими словами можно будет согласиться ;) Но рынок ими не ограничивается ведь.
да, я примерно их и имею в виду — в Top 100 самых продаваемых программ под WM едва ли наберётся пяток написанных на .NET
Ну так ведь и для десктопа на C# далеко не сразу начали активно программировать. Но сейчас-то это совсем не так.

Лично в моей ситуации попасть в top100 просто физически невозможно — сегмент узковат :)

Кстати, если, например, сравнить различный софт от Spb Software House ( судя по профилю, Вы оттуда :) ). Сегмент юзеров Mobile Shell однозначно шире, чем Wireless Monitor или Finance, верно? И причина ведь очевидна!

И если для Wireless Monitor, вероятнее всего, платформа критична, то для Finance — очень сомневаюсь. Конечным юзерам Finance с большой вероятностью всё равно, дотнет там или нет. Т.к. приложение работает и выполняет свои функции.
вы забываете про один из важнейших факторов ПО для end-user'-ов — скорость запуска и работы, которая является слабой стороной .NET'а. Применительно к тому же финансу можно вспомнить Quick Entry (маленькое приложение, с помощью которого можно добавить транзакцию в пару кликов) — если оно будет запускаться за 10 секунд, то немногим пользователям это понравится.
да и с совместимостью у .NET CF не всё идеально…
Я не забываю, я смирился. Но только со скоростью запуска. С ней почти ничего нельзя поделать. Отчасти спасает демонстрация прогресса загрузки. А ещё спасает модель выгрузки приложений из памяти в Windows Mobile — после запуска и сворачивания, повторное разворачивание происходит моментально.

А вот со скоростью работы я решил вопрос полностью — всё летает от и до. (Ну и что, что из родных контролов только TextBox и InputPanel)

Quick Entry вспомнить, к сожалению, не мог, т.к. с Finance знаком только по описанию, но идею улавливаю, безусловно — я ведь сам такоей же end-user, как и все.
Кстати, а вот ещё момент интересный. На том же Андроиде мы вынужденны программировать на чём? Верно, на Java. А чем Java (в общемировом масштабе) отличается от .Net? В случае с Андроидом отличие большое — это единственный способ писать программы для него (если не считать веб-приложений, которые почти что не считаются).

А в реальности-то Java — ни разу не нативный язык для устройств и этим не сильно отличается от .Net…
Про Java vs .NET в мировом машстабе я сейчас не настроен холиварить, извините ;)

С андроидом, кстати, всё гораздо сложнее и интереснее одновременно — там практически все приложения (втч, скажем, звонилка) написаны на Java — и ничего, прекрасно работают, так что вопрос нативности весьма спорен…

>А в реальности-то Java — ни разу не нативный язык для устройств
ru.wikipedia.org/wiki/Jazelle ;)
Да я и не ради холивара этот момент вспомнил :)

Про сложнее и интереснее — не спорю. Гугл не по делу не выпендривается. Мне кажется, что тут вопрос в поддержке Java на системном уровне в Android… Отчасти можно сравнить с поддержкой .NET в десктоп Windows.

Кста, из той же википедийной статьи — там крутая концовка:
>> Набор команд RCT не привязан жёстко к языку Java и может использоваться для компиляции байт-кодов прочих интерпретируемых языков, таких как Perl, Python, а также языков, поддерживаемых технологией .NET фирмы Microsoft.

Т.е. нас может то же счастье ждать и в CF.NET? Кайф :) Другой вопрос, что может не значит будет… Мы и Windows Mobile 7 вряд ли дождёмся в обозримом будущем :(
Only those users with full accounts are able to leave comments. Log in, please.