There has to be an easier way than to read the entire source code and check each line against what's compatible from the msdn docs
Suggestions?
I am assuming you mean from a Silverlight solution to a Windows Phone 7 solution? Anyhow, the answer is no - there is no simple / easy migration path. Simply copy the project files into a new WP7 project and start working through the compilation errors.
There is on tool that can help you creat portable code, the Portable Class Library which allows you to create assemblies which can be linked to Silverlight, WP7, WPF, XNA solutions. However, the code that you can shae is somewhat limited.
Related
I'm looking for source code (as I bet a lot of others are / were and will) for learning purposes of DirectX. I would like something similar to the vs2013 Graphics Editor when dealing with *.fbx files, etc. Every thing I find is old and outdated, or way to simple and does not show the basics like transformation cursor, picking objects or points on objects. I'm just looking for something basic.
many thanks in advance
The DirectX Tool Kit is a good place to start and includes some tutorial content as well. It supports loading models using the VS 2013 content pipeline that produces CMOs from FBX files.
You didn't state if you were looking to write a Windows desktop application (aka a Win32 application) or if you were looking to write for Windows Store / Windows phone. DirectX Tool Kit supports either, although the tutorial is written using a Windows desktop application template so that developers using Windows 7 could also utilize it.
You should also refer to the DirectX SDK Samples Catalog for locations of updated versions of the legacy DirectX SDK samples that build fine using VS 2013 only.
I have a dot net dll which uses System.Drawing.dll for using classes like Bitmap, Rectangle,Size etc.. But my dll cannot be used on xamarin... Plz suggest me what else should I use in my dot net dll for using Bitmap etc.so that it can run on xamarin.
Your dot net dll is complied for specified platform, such as Windows. so you cannot use it in other phone OS. It is no way for you to directly use dll in Xamarin unless you build it for portable class. But portable class is a generic class base, it lack of lots of classes. Such as Bitmap, it is different in different OS like Nick Turner said, so you will failed to build your source file.
The best way, you can reuse some none-platform dependent code in you dll, but for others, you need to write new code in each Android, ios, winphone project. So the Xamarin is not so wonderful for writing once, using every where. There is still lots of work in Xamarin, especially for platform specific code.
I want to manipulate docx files in wp7,c#. In windows I always use : http://docx.codeplex.com/ but it can't be added as a reference to a wp7 project.
Is there any control or alternative dll? Or is there any simple documentation about making doxc file? I read msdn documentation and I just got confused!
As far as I know there isn't a library for editing docx files for WP7 / Silverlight. However, the DocX library you link to is only dependant on the ./NET 4.0 framework. As DocX is most likely composed of non-UI code, there is a good chance that if you place the code into a WP7 Silverlight class library, you will be able to compile it.
Independentsoft has set of Office APIs compiled as Portable Class Library. It works on Silverlight, Windows Phone 7/8 and .NET Windows Store Apps.
Can I use "System.Windows.Controls" and "Microsoft.Xna.Framework.Graphics" assemblies in the same project without facing any problems from Microsoft Certification process.
Because it has been said that, "4.2.5:-The application must not call any APIs in the Microsoft.Xna.Framework.Game assembly or the Microsoft.Xna.Framework.Graphics assembly when using any methods from the System.Windows.Controls namespace."
No you can't .The requirements are explicit. Can you describe what kind of functionality are you looking for? Do you want to combine Silverlight and the XNA Framework in a Windows Phone Application? Do you want to use one of its types?
The Marketplace certification requirements are explicit - and they were correct for applications which target WP7.0. However they aren't accurate for WP7.1 "Mango" apps.
For WP7.1 it is possible to write a combined SL/XNA application. There is even a code sample for this on MSDN (see link).
I wanted to know what i shouldn't do in code that will prevent my C# app from running on mac.
In general you shouldn't use anything from the Microsoft.* namespaces, no PInvoke (DllImport in C#) and UI might be problematic as well.
Further information on Mono compatibility is contained in the Mono Guide Porting Winforms Applications. Existing applications can be checked for compatibility using the Migration Analyzer tool.
UPDATE: PInvoke actually works in Mono, but if you want to have it working cross-platform you must provide a native shared library with the same interface for each platform (i.e. Win API most likely will not work).
Mono's Application Portability guide is a good reference.
In addition to divo's recommendations, I would recommend the Mono Migration Analyzer (MoMA) tool: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono"
Also, I would keep an eye on Miguel de Icaza's blog, and the Mono Project website.
In his presentation for the Boston.NET Users Group this month, he showed a preview of a Visual Studio plugin that launches your app on Mono using a VM! This lets you test compatibility during the development process.
I believe their goal was to release it at TechEd 2009, so look for an update over the next month or so.
You will, at the very least, want to try and avoid using Windows Forms, since that is just a paper-thin layer on top of the Windows native UI.
Mono emulates it somewhat with help from WINE, but I wouldn't trust that.
Mono did this a while ago but the effort was abandoned. See WinForms on Mono for more information. Thanks jpobst.
Try using GTK# or Qt# (although I'm not too sure the latter one actually exists) for cross platform support. You might also consider using Java with SWT or even Swing instead of C#, but that will probably not be an option you're willing to consider.
Using anything related to P/Invoke is probably also a bad idea, since that invokes native code which will probably not be portable (unless you write it yourself, then you can choose to make it portable).
I'm not sure if it is possible with mono, but WIN32 API calls will definitly not work ;)