Hi Mike, Thanks for tracking this down. I fixed the bug and checked the update into cvs. The FeatureComponents table should only be populated for MSI databases, and moving the statement into an else block does that. Also, I fixed another issue that I was seeing, so that merge module components use the null guid by default. The task was dying while trying to populate the MsiAssembly table, for a merge module, with a null value for featureComponents[ComponentName].
Anyway, let me know if you have any other troubles... Jim -----Original Message----- From: Stephens, Michael [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 4:23 PM To: 'James Geurts' Subject: RE: Rollback of refactored MSI/MSM tasks Jim, Maybe you could double check this for me but I believe my problem with the MSM task is due to a bug. I found that anytime that a .dll or .exe file was being loaded in the msm task it was blowing up and I traced it back to the following location and believe that the fix outlined below will solve the problem. InstallerCreationCommand.cs line 2158 It should appear like this: if (modComponentTable != null) { AddModuleComponentVirtual(database, modComponentTable, asmCompName); } else { featureComponentTable.InsertRecord((string)featureComponents[ComponentName], asmCompName); } Before it looked like this: featureComponentTable.InsertRecord((string)featureComponents[ComponentName], asmCompName); if (modComponentTable != null) { AddModuleComponentVirtual(database, modComponentTable, asmCompName); } I don't think that a feature component should be being added in the msm task. I can now build successfully and I believe that it is a valid msm file. Thanks, Mike -----Original Message----- From: Edwards, Jayme Sent: Thursday, April 22, 2004 11:28 AM To: James Geurts Cc: [EMAIL PROTECTED]; Stephens, Michael; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Rollback of refactored MSI/MSM tasks Thanks Jim - if your confident you and Gert can help us through these issues in the next week or so I'm cool with using the new tasks. Maybe we were missing something but it seemed a lot was broken here and the schema had changed significantly. -Jayme -----Original Message----- From: James Geurts [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 11:04 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Rollback of refactored MSI/MSM tasks Hey Jayme, A slight correction is needed. Kraen did the majority of refactoring for the tasks (sorry don't have his email address with me right now). Also, from what I've used/tested so far, the tasks have worked at the same level that they were before. Overall, the changes just removed a lot of repeditive code throughout the two tasks. I haven't gotten a recent nightly build (I'm using one from the middle of February, I think), but I'll try to help you guys through the issues that you come up with. I'd like to have more contributions to the task base, if possible :) A big change that was recently implemented, however, is how files are included in the components. The filesets now act as the typical fileset from NAnt, meaning you do not need to create a mock directory structure anymore. Also.. Mike, I am planning on working through your problem tonight when I get home (around 6pm EST). In the mean time, you might want to have a look at the samples from the wiki: http://nant.sourceforge.net/wiki/index.php/samples%20for%20install%20tasks I know those scripts have built and run properly with the refactored tasks. Jim > 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 > > ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
