I am developing a relatively simple .NET class library mainly using basic value and reference types. To save code duplication, I would like to export to 1 DLL which could be used by both Windows PCs and Windows Phone devices? Is this possible? As far as I know, all methods are compatible with the .NET and Compact .NET Framework.
Yes, as long as you stick to the Compact Framework subset, it will work. Check out this MSDN article on that same topic.
Quote:
The techniques and principles
discussed in this article can be
utilized when writing cross-device
code—applications that target Windows
devices with differing form factors
(different screen sizes, orientations,
touch screens and so on).
Related
And if not then what do I have to do to make them?
(Our apps are in latest C# .NET.)
No. You would need to port your apps to the WP7 platform. You may be able to reuse some code, but the UI model is completely different.
Much of the C# sharp code is most likely the same but some things like saving and loading are different as well as you having a choice between XNA and Silverlight. The link below should contain a lot of the information you need.
http://create.msdn.com/en-US/education/catalog/
We are looking to migrate our automotive diagnostic application from the PC to a Windows Embedded platform. We have an enormous application logic code base which we will migrate to the .net Compact Framework but we are struggling to decide on the UI framework. At the moment we have three options:
1) Silverlight
2) QT
3) Crank
I have a little experience in WPF so I'm naturally drawn to Silverlight but I have zero experience of the others. Have any of you used them on this platform? Can you give me some pros/cons and maybe some potential gotchas?
Cheers,
Chris.
If you are not tied to .NET and want to have a deployment choice between Windows, Windows Embedded, WinCE, Linux x86/x64 or ARM Embedded Linux you can take a look at:
fpGUI
CodeTyphon
CodeTyphon even includes complete cross platform SCADA package for visualization and communication with many protocols (MODBUS, Siemens, Allen Bradley and other PLCs).
What is the relationship between XNA and XNA for Windows Phone?
Is that latter a true subset of the former like the .NET Client Profile?
Mostly a subset (like Silverlight vs Silverlight for Windows Phone)?
Or is it simply a similar API like WPF vs Silverlight?
They're identical in terms of the XNA API, and both are developed using the same download, typically XNA + C# + Visual Studio.
There are differences in what each platform supports though. For XNA in general I'd always consult Shawn Hargreaves blog first, and this article is most relevant: http://blogs.msdn.com/b/shawnhar/archive/2010/03/10/xna-game-studio-on-windows-phone.aspx
The biggest differences vs Xbox 360/Windows are display resolution, input methods available, and the fact that Windows Phone 7 doesn't support programmable shaders (so you can't write your own velvet/Fresnel shader for WP7, but you can for Windows and the 360).
Performance also varies: on Windows XNA performs well without much effort as it runs on the full .NET Framework. On the 360 and WP7, it runs on the .NET Compact Framework, so whilst you get the full XNA API you only have access to a subset of the full .NET Framework (though in a typical game you won't miss much of it) plus its garbage collection is shocking so depending on your game you may really have to watch memory allocation.
According to the following MSDN page, it's a subset of full XNA:
http://msdn.microsoft.com/en-us/library/gg490768.aspx
If you're considering writing XNA games for Windows 8, you may want to hold fire, as it's none too clear if XNA is still a long-term strategy for Microsoft (at least, if their comments at the recent BUILD conference are anything to go by):
http://www.rabidlion.com/2011/09/opinion-why-xna-isnt-dead-yet.html
Some articles point to Windows 8 development being HTML-based instead of primarily using native code like C or C++ (as it has been until now) or .NET (as now, or even more so as it would have been in Longhorn, but never was.)
Is this true? Will the core APIs be accessible from Javascript then? What is the primary API / framework for Windows 8?
This is worth asking. When Windows 8 was demonstrated in June, a couple of comments by the presenter scared quite a few developers - or at least turned the Internet into panic mode. I'm surprised this question hasn't been asked here before.
The best article on the topic I have found is Windows 8 for Software Developers on Ars Technica.
The short answer is: it will remain the same.
The long answer is: it will remain the same, but several things will be added. You may want to pursue using those if you're willing to bet on new Microsoft technologies. One particularly interesting one is WinRT, which is a new object-oriented native code API exposed through COM, which is supposed to be a new version of the old flat Win32 API. Details are in the linked article.
It is very, very, very, very unlikely that anything that already exists, especially based on Win32 or .Net, would be removed. That means your existing programs written in .Net or native C++ or Delphi will continue to work fine. It is also unlikely that the primary development platform will be HTML. More likely is that HTML applications will be encourage for specific scenarios - perhaps touchscreen, kiosks and tablets.
I'd encourage you to read the article I linked to above - it covers this in far more detail than any answer here can.
There are three ways to develop for Windows 8, and they all access the same underlying API, the Windows Runtime.
Use C++ and call WinRT functions much like calling Win32 APIs back in the day (you know, yesterday)
Use C# or VB and call what appear to be .NET methods (but aren't)
Use Javascript and call WinRT functions
The UI is built with XAML using a pretty reasonable designer. More details are still coming out: check http://channel9.msdn.com/Events/BUILD/BUILD2011 for videos with detailed coding demos. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 is not a bad starting point.
There are 3 language/framework combinations that are all equally supported:
C++ and XAML
C#/VB and XAML
JavaScript and CSS/HTML
All are first class ways to write Windows 8 Metro style applications. Windows Runtime provides direct access to each of these languages and so choice of development environment can be based on familiarity or feature set of the language and not on restricted availability.
Update: I forgot one: C++/Direct3D (for games).
The original quote, in the context of writing a tablet desktop weather gadget application, is that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."
The demonstrator never said a gadget is the preferred type for applications (How many Vista sidebar gadget or Windows 7 desktop gadget have you written in your life? Even when you can write them in simple HTML!), or the platform is the preferred platform for desktop weather gadget applications (How many animation control have you add to your application with video playing requirement? It is THE control used by Windows Explorer to display video!).
Today, after spending a few minutes playing with Windows 8 developer preview, I found that you can use Expression Blend 5 to easily auto-generate metro-styled applications in HTML and Javascript. Also in Visual Studio you can create exactly looking applications in Silverlight. :)
I am very excited!!! Go Windows 8! :)
Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
Update1: 2012-12-17:
While native C++ still isn't officially supported for Windows Phone 7, Windows Phone 8 now supports native C++ code so you can more easily port your existing C++ codebase(s) to Windows Phone 8 (as well as Windows 8 and Windows desktop apps).
While there isn't 100% compatibility between the Windows8/Phone8 platforms and API's right now, I expect the two platforms to become increasingly integrated over the next couple of releases.
This is especially true now that one of the key barriers to closer cooperation between Windows and other groups at Microsoft recently left the company ;)
Update2: 4/15/2014:
As per the recent announcements at //BUILD/ 2014, you can now start building "universal" apps in C++ & XAML, C#/VB & XAML or JavaScript & HTML that will run on Windows 8.1, Windows Phone 8.1 and Xbox One! For more details on building Windows Phone 8.1 Universal Apps, read this article.
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port.
We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
It is on the horizon finally!
So a survey sent to windows phone developers about their future
development preferences and XNA isn't mentioned once in the Survey (A
survey sent to windows phone developers - did I mention that)
They do however ask:
How would you prefer to use C++ in your mobile apps/games?
Develop apps/games that are C++ from top to bottom (UI, business logic, and platform
APIs)
Use C++ for business logic and then write platform abstraction layer
Use C++ for business logic use 3rd party runtime engines
I don’t want to use C++