In late 2009 we announced the availability of an IDMLlib for .NET in 2010. The current requests for a .NET version are unfortunately not justifying to develop a native .NET implementation. Because we don’t want to disappoint you, we started to investigate a way of converting the Java library into a .NET version. After some modifications to the Java library, we are now able to convert the Java library into a .NET library.
The upside of this approach is, the IDMLlib for .NET is based on the latest Java codebase:
- Same codebase, same bugs. Bugs found and fixed for one version are also fixed for other version
- Simultaneous releases of IDMLlib for Java and .NET
- Yes , that means the .NET version has the same functionality as the upcoming 1.1 Kermit release like:
- IDMS support, IDML modification and write support, IDMS composition, …
Where is light there is shadow, and so this approach has also some downsides, that don’t have any impact on the functionality, but on the usage experience.
At first it is not done by just adding the IDMLlib.dll to your solution. We are using IKVM www.ikvm.net which is a JavaVM based on OpenJDK 6 implemented in .NET – you also have to add some other dlls to set this up.
The second issue is the usage of the library inside your native .NET code, because we converted a Java library into a .NET it still feels like a Java library, not like a native .NET library. This means :
- Namespaces are rather long : de.fhcon.idmllib.api.elements.spread
- We have setters and we have getters, no properties: spread.setSelf(somevalue) instead of spread.Self = somevalue
- Generics are erased, because the JavaVM has no native support for generics like .NET has: List list = spread.getRectanglesList() instead of List<Rectangle> list = spread.getRectangleList()
- On the first invocation of the IDMLlib, the JavaVM is loaded which gives a little start penalty, but afterwards seems just as fast as the Java Version (we have not done any benchmarking, your mileage may vary)
- There will be no .NET specific documentation, only the JavaDoc
But nonetheless, is seems quite stable (no obscure crashes until now) and it does exactly the same thing as the Java library. At this point we don’t know if this will ever become a product, because we don’t have enough information to make a decision here.
So what are our next steps? We have already created a new build configuration on our CI-Server that creates a signed .NET assembly from the nightly Java build.
We are Java developers! We do know how to do things in .NET, but we are far from being on the same level as we are in Java.
So the next logical step beside converting our Java unit tests, is to look for some people with a bit more .NET experience, who are willing to test the .NET library in different environments.
What we are looking for for is:
- IDMLlib in C# and VB.Net projects
- IDMLlib in ASP.Net projects
- IDMLlib in Sharepoint environments
- Overall performance and usability of the IDMLlib for .NET
We really need your feedback here, if you want to see the .NET version happen in 2010. But again, there is no guaranty that this will become a product, if it doesn’t meet our standards of quality and stability.
So if you are willing to provide feedback, don’t hesitate and head over to the contact form. Everybody who has ever contacted us on behalf of the .NET version will be notified automatically, but if you want to be sure, we can’t keep you from registering again ;)
.Net Framework 3.0 is currently the minimum requirement for the IDMLlib for .NET, we have successfully created and deployed a Demoapplication on Windows 7 and Windows XP using .Net Framework 3.0
We strongly recommend using JetBrains Resharper extension for Visual Studio 2005/2008/2010 to handle automatic importing of IDMLlib for .Net classes