Does the MonoProject or Xamarin studio support Microsoft's COM technology? Was wondering if I could use the ole32.dll in mono. I can already use some dll's for .net, but I get a not found exception when using others that rely on ole32.dll.
No.
Mono 1.0 and Mono 1.1.xx do not have support for COM, it is a known
missing feature of Mono. Initial work has begun on supporting MS COM
on Windows. The long term goal is to support a variety of unmanaged
component technologies including MS COM, XPCOM, and UNO.
Related
I am trying to understand the implications of starting a project on .NET core. One of the requirement I am facing is to use a .NET library that is leveraging COM.
So is COM supported by .NET core (obviously, assuming the OS is Windows)?
I understand that .NET Core is built for interoperability between different OS. But I was wondering if it is to be expected that there are Windows-specific features that may be included for the windows releases such as COM compatibility.
Thanks for your help.
.NET Core is developed to be cross platform and running also on Linux and Mac. COM is a windows specific thing and will not be supported in .NET Core
We are using some old open-source .Net Framework libraries that depend on things that are not in .Net Core. Can Mono be used to fill in the rest of .Net Framework?
Specifically I'm thinking of creating a Universal Windows class library that includes everything in Mono (excluding some of the System namespace) that changes the namespaces from System.* to MonoSupport.System.*.
Of course, better approaches would be to re-write the library's code, use a different library, or be more selective in taking things from Mono. I was hoping to do this as a temporary measure.
(I want to use iTextSharpLGPL but it uses XmlTextReader, streams with .Close(), System.Security.Cryptography, etc.. The pay version of the library does not support UWP either.)
Edit: I gave up on this and rewrote my app to use Apitron. That worked great until I tried to deploy and found out they don't support .NET Native. I'm now waiting for some library to support PDF generation on UWP.
I do not think so. The following immediate reasons
Mono is a clone of the .NET Framework and therefore based on mscorlib ideas, while UWP is based on System.Runtime. Would require significant extra effort.
UWP apps - when released - are based on the .NET Native runtime. This runtime enforces some patterns in the library implementations (e.g. no reflection, no C++ implementation of types etc). Mono is also strong in AOT, but I think there are dragons.
Mono is a bad choice. Better is the microsoft referencesource for the .NET Framework as published on github.
The time you will invest in your plan will be so significant high, it is much better invested fixing it in corefx directly and wait for the next release of UWP to contain your fixes.
For your problem I would urgently recommend you to fix the problem as a submission upstream at iTextSharpLGPL by surfacing new methods and removing of close or maybe by just copying the MIT licensed XmlTtextReader. But I highly recommend you, not to mess around with crypto ;)
I know the monodis tool does the same thing for Mono that ILDASM does for Microsoft .NET. But is the monodis tool compatible with .NET in that it would work against a Microsoft .NET assembly because it works to the same file layout as Microsoft?
Yes, it does. Also, it's trivial to check, why did you even bother asking this?
Will the applications written in .net CF 2.0 run on windows embedded standard OS?
Thank you!
It depends. CF assemblies are retargetable, so the full framework (which is what comes on Embedded Standard) can theoretically run them. That said, if the assembly uses any CE-specific stuff (like P/Invoking coreddl.dll) then it's going to fail when it tries those operations.
Is there any way to develop for MonoTouch using VB.NET, rather than C#?
Currently Visual Basic is not supported in MonoTouch, but we plan on adding this to the mix in the future, as well as expanding our language support.
The reason for our lack of support is that in addition to shipping the VB compiler, we have to ship templates and we have to port the VB runtime which currently has many dependencies on desktop features of .NET and Mono.
Currently, C# is the only supported language in Monotouch. Also, Monotouch apps are not your average managed .net assemblies. Monotouch C# code is compiled to native code (similar to Vala)
I don't expect to see VB.Net in Monotouch in the near future - as of now, Miguel and his gang is busy with Monodroid & the Mono framework proper. According to their roadmap, they do have plans to support VB.net in the future. No time-frame has been mentioned.