Wednesday, September 17, 2008

Is a Managed InstEd Manageable?

For the sake of curiosity, and also to explore the possibility of utilising some of the WPF functionality, I thought I would compile InstEd as a managed (C++/CLI) .NET executable.

The first issue that I encountered was that the default boost regular expression object library (.lib) could not be linked in successfully, due to incompatibilities with compile time options with the lib, and compile time options for building a C++/CLI exe.

So, after creating a new Visual C++ project for the regular expression library, and compiling that under C++/CLI as a dll, I managed to compile my C++/CLI exe utilising that regex dll. This problem may have been resolved in later releases of boost, and it may go away by utilising the tr1/regex library that Microsoft ships with Visual Studio 9.

Bearing in mind that I changed no code, and that InstEd utilises some cutting edge C++ techniques, I was very impressed that the C++/CLI compiler could make a working executable. It's a credit to the compiler team, I think.

However, even with a working executable, there were two significant issues with the resulting executable. Firstly, the executable size went from 1.5MB to 4.5MB. That's a huge increase.

The second issue was that a quick performance check showed a doubling in the time taken to build the relationships for a large file.

While it is not entirely sensible to build a C++/CLI version of a native app for no good reason (i.e. not utilise the .NET framework), it does highlight that significant reworking of the code would be necessary to make it worth building as a managed executable. Most likely, any use of the .NET framework will have to happen in dll's, leaving the main executable completely native.

However, rest assured that for the moment, InstEd will continue to be built with minimum dependencies. Even the C++ runtime is built into the exe to save that "dll hell".

No comments: