c# Compact Framework Not Supported Exception on Math.Sinh - c#

I'm devolping on Compact Framework 2.0 SP1 and when I try to use Math.Sinh it throws me a Not Supported Exception
If I can't use this function, is there any other alternative?
Thanks!

sinh(x) = (e^x - e^-x) / 2
see wikipedia
So you should be able to write your own function !

We use OpenNETCF to gain access to a lot of APIs that the Compact Framework just doesn't support. The Math package is just one of the them. Indeed, OpenNETCF does support the Sinh function.
OpenNETCF.Math2.Sinh(angle: double)
If you do a lot of work with the Compact Framework, the OpenNETCF Smart Device Framework can be very helpful.

Look at the PInvoke signatures of Math.Sin for example, I suspect Sinh would be there on the mobile device, but just not mapped/imported into the CF to save a byte or 2.

Related

Database wrapper like Massive by Rob Conery for SQL Server 2005 and ASP.NET 2.0

Yes I still use the older version of the .NET Framework & love it. Would like to use a database wrapper now massive by rob is awesome if I had 3.5 but Nooooo.
You got any suggestions for a database wrapper ?
Please don't suggest a ORM(ex NHibernate, Active Record) all we do is write stored procedures and supply them parameters in our data access layer. Nothing more nothing less, we are thinking of abstracting away parameters as object now thinking wrapper might be out there or rolling out our own.
Dapper dot net - written by Sam Saffron of Stackoverflow fame - is a good alternative to Massive, and it's very similar, but also supports .NET 3.5.
https://github.com/StackExchange/dapper-dot-net
But you definitely need to upgrade to at least .NET 3.5 - 2.0 is really really REALLY old by now..... since it still uses the same CLR version (2.0), it shouldn't be any problem anyway - just upgrade - it's not more effort than installing a security update...
The 3.5 support is a bit less "elegant" in some places (like when you need to provide lots of parameters to a method call, since 3.5 doesn't have optional and default parameters yet), but it works like a charm!
It handles stored procedures without any problem - even those that return multiple result sets....
If you really cannot upgrade to .NET 3.5 (why is that again??), then the best you can do is the Microsoft Data Access Application Block - but that's light years behind the nicety of Massive or Dapper.NET .....
How about Microsoft's Enterprise Library? Older versions that will work with 2.0 are still available. I've used this in the past quite effectively (although we have since moved to the Entity Framework in 3.5).

Why C# is an open standard but .NET is not?

Why C# is an open standard but .NET is not? What is the point in this? Why Microsoft decide to open only some part of their .NET?
Various parts of the .NET runtime are indeed standardised by ECMA just like C# - CIL, the CLI, the CLS.
.NET is the runtime and C# is the language. C# can be compiled and run on other runtimes, such as Mono. I am actually not aware of any other runtimes besides Mono, but since the spec for C# is open, you could read it and make your own runtime. ;)
C#, like Java, C, C++, etc. is just a language definition. In and of itself, it does nothing. It defines the means by which a user can define a program or procedure and interface with external libraries.
The .NET framework, on the other hand, is not a language. It's a class library and development framework.
Actually, there is an open standard (ECMA 335 for the runtime api instead of ECMA 334 for the language).
Going beyond this, the source code for Microsoft's implementation of .Net is available and there are multiple separate implementations (the most prominent of which by far is mono).
There is some additional concern about patent encumbrance. However, Microsoft has also issued a legally binding and irrevocable community promise on the .Net platform that covers both specifications (a lot of people miss the legally binding part).
I assume you mean the framework. I guess they want to maintain control over the library implementation on Windows. There is nothing stopping someone from implementing a call-compatible version of all or part of the framework based on their own source as was done by Mono.

Is there a BackgroundWorker replacement for .NET Compact Framework 3.5?

I want to use something similar to the BackgroundWorker, which is known from the full .NET Framework, on mobile devices. Sadly it is not available in the compact framework.
What can I use instead?
There is an MSDN site discussing the Background Processing Techniques on the CF.
The most common option is to use ThreadPool.QueueUserWorkItem instead of a BackgroundWorker, although there are other options.
There is implementation of BackgroundWorker for CF:
http://www.danielmoth.com/Blog/2004/12/backgroundworker-sample.html
Here is an implementation that was created using Reflector. You could use Reflector to check out various implementations within the .NET framework
There is a framework, called Smart Device Framework by OpenNETCF, which tries to fill the gap between the compact framework and the full .NET framework. This framework contains and provides a BackgroundWorker implementation.
This framework is available as a community version, which can be used for free.
From the old version 1.x is also the source code directly available from here (scroll down to the last link). This source code is similar to the link, which #Filip Navara provided.

Retrieving machine information from .NET/Mono

I'm wondering if is it there any easy, and common between .NET and Mono, way to retrieve machine statistics (eg. free space left, total memory, etc.).
Under the .NET 2.0 profile I was able to identify DriveInfo class, but in the previous versions (1.0, 1.1) and Compact framework, which I would like to support, there's nothing like this.
I already excluded the WMI API, since it's not supported by Mono and Compact Framework.
Anyone has ideas about it?
Mono supports the DriveInfo class. You should be able to get this information the same way in Mono as you do in Microsoft's .NET implementation.
There's no way to do most of those things with .NET CF without resorting to P/Invoking Windows Mobile API. So you can strike out cross-platform compatibility with it right away.
As per making this work on .NET 1.1 (I'll pretend you did not mention 1.0...) - why? Do you have any Windows NT 4.0 clients that require this?

Equivalent of MappedBytesBuffer for .NET?

I'm considering porting an application from Java to .NET. This application makes a massive use of the NIO package which is totally non-existing in .NET.
One of the crucial differences, which is difficult to replicate on .NET, is the MappedBytesBuffer, since it is used to access an isolated portion of a file.
Could anyone help me finding out an alternative to replicate the functions? Thank you a lot.
If you can wait until .net 4.0, this might be useful:
What's New in the BCL in .net 4.0
Alternatively, you could roll your own wrapper for the Win32 apis CreateFileMapping and MapViewOfFile

Categories

Resources