Hello,

 

We’ve been using the MSI/MSM tasks that were coded prior to Gert Driesen’s refactoring work for several product releases here at Rockwell Software over the past couple years. When NAnt 8.4 was released, some updating needed to be done to these tasks to make them work with some API changes in NAnt, and in that time Gert took it upon himself to do some reduction of lines of code in the tasks.

 

I’ve had a developer here Mike Stephens evaluate the use of WiX (Microsoft’s XML scripting installation tool) when that snafu was introduced to the fold, and he found that it’s not going to meet our needs. It doesn’t have decent documentation, and doesn’t support the features the MSI/MSM tasks for NAnt include that we need.

 

After reaching this conclusion, I asked Mike to get the latest refactored MSI/MSM tasks and get those integrated into our build scripts here that use NAnt 8.4. Mike found that the simplest MSI install didn’t work and contacted Gert to fix a bug. Since that time we’re running into bug after bug in the new refactored code.

 

I am very concerned about how this refactored code has made its way into the main NAntContrib branch without any formal testing considering the time already spent getting the pre-8.4 code to work, and the impact of this on other users of NAntContrib that are having problems using the new versions. I don’t feel very confident that the new code is thoroughly tested, and though it compiles there are numerous features of the MSI/MSM tasks that don’t appear to have even been even exercised prior to the checkin.

 

I would like to request that we do some work to update the versions of the MSI and MSM tasks based on code before Gert’s refactoring to work with the current CVS build of NAnt (all we need to do is update calls that interface with the new NAnt and are affected by API changes) and a folder “Future” or something similar be created and the refactored MSI/MSM tasks be moved here. Should a time come where the refactored tasks are stable enough to do everything the old code did, we can replace them. But I’m certain that as of now this isn’t the case.

 

If this cannot be done we will have to just use the older tasks here and not be able to contribute back to Sourceforge, which is unfortunate. But Jim Geurts and I spent a lot of time using, fixing the bugs for, and verifying the old versions of the tasks in real product builds here at Rockwell Software and exercised every function of the tasks. Until I see a build that exhausts all the features of the tasks that can run using the new refactored versions, we can’t use them.

 

Let me know what you think we should do.

 

Gert – I hope I’m not insulting you by what I’m saying in this email I know you did a lot of work to refactor the code we originally contributed and I think you did a good design. But just as is with a commercial software product that has customers, open source projects that have been established for a while need to make sure we don’t upset our user base that has been using these tasks and contributing code to them for a while now. If we want to continue using your refactored tasks without rolling back to the new ones until your done, your going to have to move very quickly to test and verify that the new code works and make any bugfixes needed ASAP. If it takes several months to get there when we already had code that worked before but needed some minor updates to be compatible with the new NAnt 8.4 API, that’s unacceptable.

 

Jayme Edwards

Product Architect

Rockwell Software

RSProduction Portal

 

Reply via email to