I think the merge modules (SQLSMOMergeModule.msm and StrataFrameMergeModule.msm) supplied in the latest beta, install SF DLLs which are an earlier version than the DLLs installed by the beta itself.

When I run my application against the DLLs installed by the merge modules I get "type not found" style errors which are not there when the application runs against the DLLs installed by the beta installation itself.

If this is the case, any chance of an update?

Thanks,

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?

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

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.

Thanks