I wanted to convert a small test application from Windows .NET 4 to MonoTouch but I am missing System.IO.MemoryMappedFiles.
Then I tried it with a plain Mono console app and the namespace isn't there either.
I tried Mono 2.10 in combination with MonoDevelop 2.4.
Is it supposed to be there or not? I'm kind of confused, as .NET4 compatibility was announced with Mono, as far as I know.
Mono 2.10 has some support for memory mapped file. However it is not 100% complete (and Windows-specific things like security are not likely to be ever included) so YMMV.
You can browser what's available from the GIT repository:
https://github.com/mono/mono/tree/mono-2-10/mcs/class/System.Core/System.IO.MemoryMappedFiles
Since this is a .NET 4.0 feature you'll need to use the 'dmcs' compiler to get your code to compile (and also reference System.Core.dll where the types resides).
As for MonoTouch it provides a subset of Mono (originally based on the 2.1 profile from Silverlight and extra, even some 4.0, features). Currently (for MonoTouch 4.x) this does not include any type from System.IO.MemoryMappedFile.* namespace. Future versions will offer more .NET 4.0 features (if they are available from iOS).
Related
I was inspecting the change log of Windows Azure Storage nuget from here. I do not get the usage of CoreCLR, PCL and WinRT.
For instance
Changes in 7.2.0 :
All (CoreCLR): NetStandard target framework changed to netstandard1.3
All (PCL): Removed support for PCL in favor of NetStandard GA release
...
Changes in 7.1.2 :
...
All (WinRT): Fixed a bug where HttpClient default timeout caused unhandled TaskCancellation exceptions.
...
A simple search on google tells that CoreCLR is a .NET execution engine and WinRT stands for Windows Runtime. I do not know what PCL is.
So what is the importance of these in change log in simple terms?
Those represent versions of the package capable of running on different versions of .Net:
WinRT is used in Windows Store apps, it uses a trimmed version of .Net
PCL is short for Portable Class Library, the old approach of targeting multiple versions of .Net from a single library
NetStandard is a new approach of targeting multiple versions of .Net, that came along with .Net Core, the new modular cross-platform version of .Net
CoreCLR is the runtime used by .Net Core, though marking changes to NetStandard version of the library as "CoreCLR" is confusing
Is there any way to statically link Direct3D so the program doesn't depend on any D3D DLLs? It seems impossible with Direct3D 9 and later (although I would like to be proven wrong), but I can't find any information on older versions. I'm making a small simple game and I really don't want a mandatory installer, but I want to use Direct3D.
No, there was never a time when you could statically link any version of Direct3D into your app. The same is true for OpenGL.
If what you are asking is "How do I create a Direct3D app that doesn't require an installer?", then this is actually quite easy to achieve as long as you give up on trying to support ancient and irrelevant versions of the Windows OS.
The simplest thing to do is target DirectX 11.0. Your system requirements would read:
Windows 8.1, Windows 8.0, Windows 7, Windows Vista Service Pack 2 with KB 971644
See Direct3D 11 Deployment for Game Developers
Use Direct3D 11.0 APIs
Use DirectXMath, DirectX Tool Kit, DirectXTex, and/or DirectXMesh which are all statically linked
If desired, you could use Effects 11 as it is also statically linked.
Avoid all use of D3DX9, D3DX10, and D3DX11
Use XInput 9.1.0; avoid XInput 1.3 (on Windows 8.0+ you could use XInput 1.4)
Avoid use of XAudio2.7 (On Windows 8.0+ you could use XAudio 2.8)
Avoid use of XACT
If you use VS 2010 or later, then you can deploy the required VCREDIST files side-by-side with your application with a simple copy
If you use the Windows 8.x SDK version of D3DCompile, you can deploy it side-by-side with your application with a simple copy.
Audio is the biggest challenge here since XAudio 2.8 is only on Windows 8.0 or later, and XAudio 2.7 requires the DirectSetup redist to deploy. Most audio middleware solutions use WASAPI directly on Windows Vista+, so these are reasonable options. You could use legacy DirectSound8, and the headers for that are at least in the Windows 8.x SDK that comes with VS 2012/VS 2013.
If you need Windows XP support, then require Windows XP Service Pack 3 as the minimum OS. This will include DirectX 9.0c and WIC components as part of the OS.
You'll need to use Direct3D 9 and DirectSound8
Avoid using D3DX9 at all so all HLSL shaders would have to be pre-built offline, and you can't use the Effects (FX9) system or D3DXMath.
If you are using VS 2012/VS 2013, you can target Windows XP using the *_xp Platform Toolset, but remember that that uses the Windows 7.1A SDK and not the Windows 8.x SDK so it has some implications for DirectX development.
Direct3D 9 debugging on Windows 8.0 or later is also a huge pain as there's no developer runtime available for it.
All of this assumes you are using C++. Using .NET is not realistic as the deployment story for .NET is rather complicated. You could in theory use .NET 2.0 if you require Windows Vista+ or later, but it may require enabling a Windows feature on some versions of the OS, and you can't count on any version of .NET to be present on Windows XP. .NET 4.0 is on by default for Windows 8.0+, but support for .NET 3.5 and earlier is off by default. However, all use of DirectX from C# requires additional assemblies which themselves likely have dependencies on the legacy DirectSetup deployment.
In my question about using .NET 4.0.3 in a Portable Class Library I spoke a little too soon: I got the PCL working on my Windows machine, but now I can't get it working on the Mac. If the library is set to use .NET 4.03, I get compiler errors in MonoDevelop, saying that the framework is not supported. So I'm stuck on PCL for .NET 4.0, which is annoying because I need some features from 4.0.3.
So, is there a way to target .NET 4.0.3 in MonoTouch/MonoDevelop on the mac?
MonoDevelop (up through 3.0.6) is/was hard-coded to only work with PCL Profile1 (I think it was Profile1, anyway). As a workaround, you can try changing over to Profile1 and building that.
On MacOS, MonoDevelop simply links with MonoTouch (or Mono4Android) system assemblies and ignores the PCL profile constraints (other than verifying that the profile is Profile1). If MonoTouch has the 4.0.3 APIs that you are trying to use, then things will build fine.
I have got an application developed with Monotouch 4.0.7. This app is running on iPads with iOS 4.3.
Now, I want to migrate to the latest Monotouch version is 5.0. Will I be able to deploy my app on iPads with iOS 4.3? Or Monotouch 5.0 only for iOS 5.0?
Yes, it is possible to develop for iOS 4.3 (or even earlier iOS versions) with MonoTouch 5.0.
To set the minimum iOS version your app needs, go to the project's options, and in the iPhone Application page set Deployment Target to the minimum version.
Have in mind that MonoTouch will not tell you if you use iOS 5.0 API in your app. You can add iOS 5.0 features to your app, but you must not try to use those features on a lower version (here you can see how to accomplish this).
You can upgrade to Monotouch 5.x without any problems. In Monodevelop, change your SDK to 5.x
Just make sure your deployment target remains 4.3, if you still want to target that platform.
You will have to pay attention to not calling any methods that don't exist in 4.3.
If you want to have different/extended behavior on iOS 5 devices, you can check the OS version and use a different code branch.
Another small thing to be prepared for: iOS5 behaves differently in some situations. For instance if you are having hierarchical UIViewControllers, iOS5 will automatically call all UI events like ViewWillAppear(), even if you don't use the new UIViewControllery hierachy API.
What I want to say: test your app thoroughly on both iOS versions.
I want to run my c# application with OS Linux using Mono. I am new to this cross platform migration? Please tell the procedure for doing that?
Thanks & Regards.
It very much depends on what type of application it is. For a console or WinForms app, it may be simple. Mono doesn't support WPF.
Well, the first think you'll need to do is install Mono of course. Then you probably want to run MoMA to determine your application's compatibility. There's a whole separate page about porting WinForms apps.
If all is well, you should just be able to run your application using:
mono MyApplication.exe
after copying the binaries over.
If your application is actually a web service or web application, you'll want to think about the various hosting options.
I suspect you'll want to read a lot of the pages on the Mono Start Page.
Check if your application is 100% compatible with Mono Framework using MoMA.
Remove or replace those unimplemented parts with Mono's implementation or third party libraries that works with Mono. Or if you think it should work fine, just execute it with Mono Framework 2.8 or higher. Better go with 2.10 which is default's profile is on 4.0.
There is an IDE, MonoDevelop that supports Web and Desktop applications. Open the project files (monodevelop supports visual studio project files) from monodevelop, compile and run.
you can browse mono website here, where you can find which features are supported and which are not supported and why.