Tuesday, September 30, 2008

Tips and Tricks Part 4 - Moving component elements

While it would be great to have drag and drop of things like files and registry entries between components, in the meantime there is a nifty trick to move multiple elements between components.

The basics of the trick is to rename the source component to a temporary name, updating the references of only those elements that you wish to move. Then rename the temp component to its original name, updating no references. This will leave the elements that you wish to move "orphaned" with an invalid component.

Then, rename the target component to the temporary name, updating no relationships. This will leave the target component's elements "orphaned", but the elements that are being moved will now be attached the "temp" component.

The final step is to rename the "temp" component back to its original name (the target component), updating all relationships. This will result in the target component containing its original elements and the "moved" elements.

For example:


SourceCmp TargetCmp
File1 File3
File2 File4
Reg1 Reg3
Reg2 Reg4

Step1:
---> TempCmp TargetCmp
File1 File3
File2 File4
Reg1 Reg3
Reg2 Reg4

Step 2:
SourceCmp <--- TargetCmp
File1 File3
File2 File4
Reg1 Reg3
Reg2 Reg4

Step 3:
SourceCmp TargetCmp <---
File1 File3
File2 File4
Reg1 Reg3
Reg2 Reg4

Step 4:
SourceCmp ---> TargetCmp
File1 File3
File4
File2
Reg1 Reg3
Reg4
Reg2



When only moving a few items in one table, it is probably easier to simply copy and paste the target component's name into the relevant fields. But when moving many entries, especially from disparate tables, this method can be quicker. It is probably easiest done from the Component (F10) or Feature (F11) tree views.

This method applies equally well to any parent child entity where the children reference the parent, such as Dialogs and Controls.

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".