StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » Merges Modules out of date in 1.6.7 install?

Merges Modules out of date in 1.6.7 install?

Aaron Young — Fri, 27 Feb 2009 09:38:41 GMT

Hi,

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

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Fri, 27 Feb 2009 09:38:41 GMT

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

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Fri, 27 Feb 2009 08:35:20 GMT

[quote]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 ?[/quote]

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.

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Thu, 26 Feb 2009 18:47:18 GMT

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

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Thu, 26 Feb 2009 17:34:42 GMT

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?

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Thu, 26 Feb 2009 15:17:02 GMT

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

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Tue, 24 Feb 2009 14:13:57 GMT

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.

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Tue, 24 Feb 2009 13:10:10 GMT

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

Thanks

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Tue, 24 Feb 2009 12:41:25 GMT

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.

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Tue, 24 Feb 2009 12:05:47 GMT

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.

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Tue, 24 Feb 2009 07:31:14 GMT

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.

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Mon, 23 Feb 2009 09:07:26 GMT

Attached is a screenshot of the error when run on my dev PC after installing the MSM modules.

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Mon, 23 Feb 2009 08:38:57 GMT

Is there a stack trace with the "Type not found" exception?

RE: Merges Modules out of date in 1.6.7 install?

Aaron Young — Mon, 23 Feb 2009 08:33:58 GMT

Trent,

Just some more info in case it helps...

I have uninstalled and re-installed the latest beta and checked that the Distribution folder was removed after the uninstall. After the SF beta installs, the SQLSMOMergeModule.msm file has a modified date of 27th January and StrataFrameMergeModule.msm is 16th February.

When I build and run my app in VS everything is okay. I then re-build my Installaware installation (after deleting and adding the merge modules in IA just to be safe). When I run the IA installation routine on my PC, the application doesn't run and throws "type not found" errors from the SF DLLs. This is also true if I try and run my application in VS. To fix it, I do a repair on the SF beta installation and I am back in operation again.

I don't think there is a permission problem as my PC starts with the correct DLLs from the SF beta install. It is only after the IA merge module install that it goes wrong. I have also tested it on a clean PC with the same outcome.

Thanks,

Aaron

RE: Merges Modules out of date in 1.6.7 install?

Trent L. Taylor — Mon, 23 Feb 2009 07:43:41 GMT

Aaron,

When I first read this I tought that we probably forgot to update this. However, the same SMO MSM that we place in the distribution folder is the same that we use as part of our installation. So these should be up to date. The StrataFrame MSM appears to be updated as well, but I will look at this more closely. So I would imagine at this point that one of two things happened:

The MSM files did not get updated on your machine due to files in use or permissions.
The assemblies did not get updated when deployed to your client due to files remaining in the GAC, or permission issues when overwriting existing assemblies (which could also be file in use issues).

I will check again, but I am pretty confident that the correct files are being distributed.