Thanks Trent. Just for the record I have stopped using the StrataFrame module and added the files manually. All the problems in this thread have disappeared now although it is good to know the module will be fixed in the next build anyway.

Thanks

No.  These are SMO assemblies and actually I just looked at the MSM module and .NET decided to add those in there on their own.  I have excluded them and so they will not show up in the next build.  But all the same, we never use the StrataFrame merge module.  We always add SF assemblies manually because there are so few.  At any rate, these assemblies will not be in the SF MSM in the next build.

Hi Trent,

I think you are not seeing the problem because your setup only includes the SQLSMOMergeModule.msm module. This problem exists when both SQLSMOMergeModule.msm and StrataFrameMergeModule.msm are added to the same Windows Installer setup. I also believe this has only become an issue since the last beta which added SQL Server 2008 support and I guess resulted in a change to the SQLSMOMergeModule.msm module. I am not totally sure of this but it was only reported to me from the latest beta and we have frequent installations so I should really have heard about it before.

I have tried uploading a ZIP file with a simple setup but it keeps timing out. However, it is not hard to create if you follow these steps.

1. Add a new Setup Project in VS2008.

2. Double click "Microsoft .NET Framework" under "Detected Dependencies". Right click on ".NET Framework" under "Launch Conditions" in the left hand window. Open the Properties Window and change the Version to 2.0.50727.

3. Add SQLSMOMergeModule.msm.

4. Add StrataFrameMergeModule.msm.

5. Build it.

You should find the following results when you run it depending on what is already installed on the PC:-

1. This setup looks like it will fail on any "clean" PC which does not already have either module installed (regardless of whether this was via a merge module, a client application setup or a SF setup). I believe the SQL module is installed first, then the SF module attempts to install Microsoft.SqlServer.Dmf.dll which has already been installed by the SQL module and this throws an error of "Error writing to file: Microsoft.SqlServer.Dmf.dll. Verify that you have access to that directory". Basically, Microsoft.SqlServer.Dmf.dll is in both modules and MSI attempts to install it twice.

2. This setup will run CORRECTLY on a PC which already has the latest SF beta installed. I believe the installation routine simply sees the files are already present and doesn't attempt to install them again. Hence no error. I also believe it will work regardless of how the files were installed, i.e. they could be installed via a client application setup, etc.

I am no MSM expert but I don't believe MSI can install the same file twice during a single installation - at least from different merge modules. There can also be issues relating to the temp storage of files before they are moved into the GAC. As I said I am no MSM expert but I took a look at both merge modules using Microsoft Orca and it's validation process shows many errors and also duplication of DLLs within and across both modules.

It is also worth highlighting that if I split both modules into separate setup routines they will install correctly. This issue relates to both modules being installed from the same setup on a PC that doesn't already have the components installed.

I could drop the StrataFrameMergeModule.msm module and simply add the files manually, but I would like to see if we can get to the bottom of this. Should Microsoft.SqlServer.Dmf.dll, Microsoft.SqlServer.Management.Sdk.Sfc.dll and Microsoft.SqlServer.SqlClrProvider.dll be in StrataFrameMergeModule.msm when they are already in SQLSMOMergeModule.msm ?

Sorry to be a pain but there really is a problem here.

Regards,

Aaron

Aaron,

I have tested this and we are actually distributing this MSM with our medical software and it is working.  Without getting this is some test state it is going to be really hard to tell what is going on.  The problem is that your Windows environment can obviously have an affect on this.  Do you have a virtual machine that you can test on to see if a new install, etc. works?

Hi Trent,

In addition to the problem listed above, I also had reports of problems installing the SQL module on some types of system - (Virtual PCs, Windows Server 2003 and Vista). Not all systems report an error but some do and the error during the installation is:-

"Error writing to file: Microsoft.SqlServer.Dmf.dll. Verify that you have access to that directory".

I think I now get this error as I changed the order the merge modules are listed in InstallAware which I believe governs their installation order.

Interestingly, the setup has installed the SQL files (including the one above) before the error. It looked like the setup was attempting to install the file a second time. I built a simple VS2008 setup project and added the two merge modules. VS2008 reports warnings that several files are duplicated in the modules (screenshot attached).

VS2008 also reports the following files listed in each module. Some SQL files are in the SF module and there appear to be a number of files copied twice in the SQL module. I think my setup routine installs the SQL module first and then throws the error when attempting to install the SF module as the Microsoft.SqlServer.Dmf.dll is present in both.

StrataFrameMergeModule.msm

MicroFour StrataFrame Base.dll
MicroFour StrataFrame Business.dll
MicroFour StrataFrame DBEngine.dll
MicroFour StrataFrame Enterprise Client.dll
MicroFour StrataFrame Enterprise.dll
MicroFour StrataFrame Security.dll
MicroFour StrataFrame UI.dll
Microsoft.SqlServer.Dmf.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.SqlClrProvider.dll

SQLSMOMergeModule.msm

microsoft.sqlserver.batchparser.dll
Microsoft.SqlServer.BatchParserClient.dll
Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.ConnectionInfoExtended.dll
Microsoft.SqlServer.Dmf.Adapters.dll
Microsoft.SqlServer.Dmf.dll
Microsoft.SqlServer.Dmf.dll
Microsoft.SqlServer.DmfSqlClrWrapper.dll
Microsoft.SqlServer.Management.Collector.dll
Microsoft.SqlServer.Management.CollectorEnum.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.PolicyEnum.dll
Microsoft.SqlServer.RegSvrEnum.dll
Microsoft.SqlServer.RegSvrEnum.dll
Microsoft.SqlServer.ServiceBrokerEnum.dll
Microsoft.SqlServer.ServiceBrokerEnum.dll
Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.SmoExtended.dll
Microsoft.SqlServer.SqlClrProvider.dll
Microsoft.SqlServer.SqlEnum.dll
Microsoft.SqlServer.SqlEnum.dll
Microsoft.SqlServer.SqlWmiManagement.dll
Microsoft.SqlServer.SqlWmiManagement.dll
Microsoft.SqlServer.SString.dll
Microsoft.SqlServer.Types.dll
Microsoft.SqlServer.WmiEnum.dll
msxml6r.dll

No, the SQL SMO it deep....a LOT of energy.  It tooks us a while to produce this SMO MSM.  We only do this on the SF assemblies...since there are only a few.

I think that sounds like a good idea. Do you also do this instead of using the SQL MSM?

Thanks

The there is something else in the mix here.  The SF assemblies are most likely your issue.  Instead of using the MSM, is there any reason that you have an adversion to trying to just add the SF assemblies individually and see if it resolves your problem?  This is actually what we do versus using the MSM itself.

Thanks for the update but I am afraid it is still happening. I will be away tomorrow but I may go back to some of the earlier betas when I get back - just to see if it makes a difference.

Thanks.

Well, I found a possible issue with the SQL SMO merge module, but the SF was correct.  I have attached the MSM file that we use within our install.  If this doesn't work then we will have to dig deeper.

This is very literally the exact SQLSMO MSM that we use during our install of SF.