Software Deployment

According to PackageCleaner, these are all Windows Protected Files. For Windows 2000 and later, this is going to cause you some definite problems. You could try to relocate the files to the application directory, but either way I think you are looking at more than one package for such a wide range of target operating systems.

This is what PackageCleaner says about Windows Protected Files:

Reasons Not To Include It
By design, files managed by Windows File Protection cannot not be updated by an MSI package.

When You Might Want To Include It
Windows Protected Files may be included in packages that take install them in the application directory and not a shared directory (such as the Windows or System directories). You will not see an error if all your target systems already have the same version installed. In this scenario, Windows Installer does not attempt to update the file.

What Might Happen If You Include It
If an MSI attempts to replace a file managed by Windows File Protection, the MSI package will fail with an error of 31. The installation will roll back any changes made to the system from before the error was encountered.

Additionally, the msvcrt.dll and msvcirt.dll files were reported by PackageCleaner to be a component of MDAC. This is what it had to say about these two files:

Reasons Not To Include It
Installing only some files that make up MDAC can result in an invalid MDAC installation where not all files are at the proper version. Microsoft has made a Merge Module available for MDAC that should be used to ensure a supported combination of MDAC components.

What Might Happen If You Include It
DLL registration errors may be reported by your packages. An incompatible set of MDAC files is unsupported and may cause unknown problems. Other applications reliant on data access components may experience errors.

Not the quick and simple answer I'm sure you were hoping for, but I hope it helps. Read up on Application Isolation- it may help to reduce the number of packages you need to create.

Good luck!

Hi Bob,

Thank you for the detail reply. According to what I have found, installing those dlls in application directory may not work anymore:

http://msdn.microsoft.com/library/d...ure06122003.asp

You mention that msvcrt.dll and msvcirt.dll are part of MDAC. Will MDAC always install these files into System directory for all OS? I ask this because msvcp60.dll is part of Windows 2000 Server but it may not be installed. For example, DLL Help Database shows \support\tools as the relative path for the msvcp60.dll 6.08168.0 version.

I need those dlls because Crystal Reports runtime files have dependency on them. I'm using InstallShield Dev Studio 9. I wonder whether I should use Crystal Reports 8.5 InstallScript Object and the MFC InstallScript Object since these will include those dlls.

Thank you for any help.

Hi Bob,

I forget to ask you whether there is any tools like Package Cleaner but for InstallScript Project.

Thank you.

There is no point in delivering system files for any reason. the exception may be Crystal Runtimes which expects to find its dll files off of the system32 folder.

No, as far as I know PackageCleaner is one of a kind (and I have looked). It works with MSI files as well as with Wise WSI (Wise Windows Installer Project) files.

Didn't see your other post- I do believe that these MDAC files always end up in the system folder. Redirection is hit or miss and it is a rather involved process to understand under what circumstances it will do the trick. While deploying system files is currently a "no no" I would not be surprised if you found that not including them will result in application execution problems for the older operating systems. The problem there is that as shared DLL files you may cause other compatibility issues.

I would definitely recommend different packages for before and after Windows 2000. To be safe (especially where MDAC and shared DLLs are concerned) you would be well advised to create packages for each operating system and then compare the results to determine just how few packages you may be able to get away with.

Best of luck!

Hi MSIMaker,

I agree with you that there is no point to deliver system files if they are always installed and can be referenced by an application. I say this because I notice that MSVCP60.dll may not be installed in Windows 2000 Server.


Thank you for your help,

Peter

Hi Bob,

I'm currently working with MS support regarding this issue. As of now, the recommendation from MS is using msm or installing those dlls into application folder. What do you think about the recommendation?


Thank you for your help,

Peter

I'm currently packaging for an Enterprise with 30,000 users and they laid down some strict rules at the start which we stuck with and have had great success.

1. You cant drop ANY files into System32.
2. You cant drop any O/S System32 files onto the platform in any folder. The app should use the latest system dll's to run. If it can't then we get a dispensation to drop it to the app folder. We dont point any registry entries towards that dll
4. All dll and ocx files installed to the system folder during capture are moved to the applications folder and registry entries removed. We then create a .local file for all exe files the app uses. The app will startup and use its local dll's before looking in the registry for paths to others.
5. We dont use msm files because then you have to constantly monitor the msm versions and regression test as each new msm version is added to the platform.

These rules and methods work for us and might not work perfectly for you.....but at least you now know that there is no 1 right way to do it.

hi pcw66,

I think MSVCP60.dll is dropped mostly by MS-Office XP or IE 6.

Thats most likely why you dont see it on Windows 2000 Server.

pcwc66,

I'd say that MSIMaker provides an excellent example of what everyone should do- have a policy on dealing with the issue and stick to it (as best you can.) I'm not surprised at Microsoft's recommendation: including system files can result in a mix of files that make up a system level installation such as MDAC. The results of having one version of MDAC installed with just one or two newer or older DLLs can cause big problems and be very difficult to identify. Although I see MSIMaker's point in avoiding MSMs because they are yet another thing to track- hotfixes too may change system files and you cannot always be as selective about installing hotfixes.

At least in the case of MDAC, I strongly recommend the MSM. It is basically a custom action performing a silent installation of MDAC. It ensures all the files you have belong with one another. From here you just need to watch what you deploy so as not to break it down the road.

Putting any such files in the application directory seems like a safe approach, but it becomes a complex process when you realize that you must ensure you do not have DLL registration information in the registry that point to these files.

At this point in time, there is no easy solution or obvious decision to make. In a mixed environment such as yours, testing of packages will be even more critical than ever. It is your testing that may well decide how you go about a deployment. My suggestion:

• Deploy the latest MDAC or the MSM for it (same thing)
  
• Recapture your application; remove all system files (MDAC files should no longer be among them)
  
• Test, test, test
  
• If your application has trouble on 9x or NT, recapture the installation on those systems and monitor which files get updated in system- then create a second package that includes these files for these operation systems.
  

I'm sure there could be dozens of other opinions on how to go about it, but what everyone will agree with, is that testing it will be your most critical step.

Best of luck,
Bob

Hi MSMMaker and Bob,

With the changes in Windows 2003 Server and XP SP1 (changes in DLL search order), I'm not sure whether putting dlls in the application directory is a safe approach anymore.

http://msdn.microsoft.com/library/d...ure06122003.asp

For example, if all the dlls needed for an application are installed on the applicatin directory and System directory also contains some of those dlls but different verions, will this cause incompatibility problem?

When you say need to make sure there is no DLL registration informaton in the registry that point to those dlls in the application directory, I guess you mean those self-registering dlls. Can the self-registering process be disabled in InstallShield?


Thank you for your help,

Peter

Peter I'm getting a 404 error on that link....can you repaste it please.

If your dll's are MS supplied and are of a later version than the apps....then the backward compatibility reward steps in....MS reckons that all new MS dll's are fully backward compatible and your app should work fine.....but test it.

Bob,

We deployed MDAC 2.71 using the MS supplied package.....and we also have a liason with MS to help us with things like MSXML versioning and so forth. So some apps do get

But testing testing testing and then do some testing is the motto here. When you are going to release to 30,000 in one hit...then dont look stupid by overlooking anything.

Also hotfixes are one of those things most ppl dont think about......well here is a horror story for you.

We deployed a series of hotfixes because Group security told us we had to and by doing it we broke several key apps used by the business. Again testing should be manditory for EVERYTHING you deploy including hotfixes and app patches.

Hi MSIMAKER,

Sorry about the link. Here is the link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure06122003.asp


Thank you for your help,

Peter

Well that article was certainly worth a read as it really affects this project because we totally rely on our apps searching the app folder first.

God I love Microsoft.....They have given me good employment now for 14 years.....and most likely will continue to do so for the next 20, but would you buy a new car from them :)

Hi MSIMaker,

It is good to know that the article is useful to you.


Peter

Hi All,

I don't think the reference in the article will change the search order for DLL's on applications that have used .LOCAL application isolation.

If you monitor enough with sysinternals filemon you see the operating system in Win2K and XP looking for the .local file and redirecting. Of course this would not apply on 9x systems.

But for win2k and xp installs I do believe that application isolation using .local is the best way to go.

Tom.

Hi Tom,

I'm trying to find out from MS whether the DLL Search Order's change in Windows 2003 and Windows XP SP1 affects .local dll/com redirection or not. I hope I will get an answer. The article does not have too much detail.

Peter

Peter I checked yesterday with our in house MS guy and he said it wont affect us unless we have "hard wired" dll's in place. So basically as long as we stick to our rules...we should be ok.

The only time we will be affected is if App #A needs a.dll and that dll is a system32 dll with registration. If the app refuses to work with the system delivered dll then the new search order will hurt us because the OS dll will be the first one found and wont work. It basically means that old 32bit and all 16bit apps are going to bite the dust hard in the future.

You cant blame MS really because they have to stop supporting legacy rubbish sooner or later and this will speed it up for sure.