Software Deployment

hi,

From WinXP onwards the winsxs folder is protected.
u cant write anything into this folder.
since the MSXML files are WPR(windows Protected resources) similar to WFP in other versions of windows.
that is teh reason it puts these files in some other location.
even then ur application works.
try that out.
In Vista u can never install in to this folder (the size of this folder in vista is abt 4 GB).
Only a trusted installer can put files into this folder.
Trusted installer is elevated user only when hot fixes apply from microsoft are installing.

Hi Binque,

I am facing exactly the same issue. Did u find any solution for this issue?

Thanks

For msxml you should use the merge module instead.

ORIGINAL: binque
I wanted to post the log-file aswell, but couldnt upload anything here.Use the 'code' tag by clicking the button marked '<%' and post it between the tags.

Ian,

Do you think binque will monitor this thread after ~1,5 years? ;)

LOL...wasn't concentrating. I saw your exchange with Anitha and assumed the thread was current.Anyway, it's not completely out of the bounds of possibility: he/she may have email notification switched on. [pokes tongue out] :)

Hello Anitha.

I don't remember - it's a long time ago, but I got paid to do this so I better had fixed it. :-p
Not much help to you, I'm afraid, except that it is possible. ;-)

Brgds
Marius.

ORIGINAL: VBScab

LOL...wasn't concentrating. I saw your exchange with Anitha and assumed the thread was current.Anyway, it's not completely out of the bounds of possibility: he/she may have email notification switched on. [pokes tongue out] :)


You're correct as always or just lucky on the assumption... did I see Ian making a wild guess? ;)

I have powers beyond human comprehension. Let's leave it at that. LOL

hehe nice Ian

I'm sure using the merge module would "fixed" the WPR/WFP problem.

hi,

including them as merge module will meet ur requirement.
but many oragnisatons will not like merge modules in their package.
i u dont have such constraints u can go ahead.

ORIGINAL: vijaykodali
hi,

From WinXP onwards the winsxs folder is protected.
u cant write anything into this folder.
since the MSXML files are WPR(windows Protected resources) similar to WFP in other versions of windows.
that is teh reason it puts these files in some other location.
even then ur application works.
try that out.
In Vista u can never install in to this folder (the size of this folder in vista is abt 4 GB).
Only a trusted installer can put files into this folder.
Trusted installer is elevated user only when hot fixes apply from microsoft are installing.


So what is the best way to deal with this non ability to write to this area when my package is trying to? Will it break my package if I delete these components? It worked fine on XP but fails in VISTA trying to write to the 'manifests' folder.

Hi binque

Since the release of Windows 2000, Windows has shipped with Windows File Protection (WFP), a mechanism for monitoring and restoring system files that have been renamed, deleted, etc.

The Installer has no mechanism for by-passing WFP and if your package attempts to replace a protected file, the installation may not give the expected result. For the sake of application compatibility, the install does not fail if it is unable to update a WFP file. Instead, an entry is written to the application event log. However, it is important to note that the application may not be using the intended version of the file.

Do not be tempted to work around this by using a custom action or other means. WFP will roll-back any changes you make. You cant fight windows file protection.

However, it could be that there is a .msi in your source that is laying these files down as was the case with my package SAP UI 7.10

Please see the link to a post of mine below
http://www.appdeploy.com/messageboards/printable.asp?m=31883

It is often the case that there is a .msi buried deep within your source file's that is laying these files down. This .msi, if it exists will be produced by microsoft and will have logic built into it to install to a protected area. That was the case with SAP.

This .msi if it exists will be based on different packaging technology similar to the type used to create Service Packs etc. That is why is can install to a WFP protected area.

If it exists install it as a pre-rec and then do your capture afterwards.

The .msi might not be easy to find it i recomend using dependancy walker for this job.

If after checking there is no .msi file in your source, you will simply have to exclude them.

Good Luck

hi,

as i told u earlier. if we delete the files from the application it may work or may not depending on the manifests u are deleting. if we include these files into the application. application will go for self heal every time it is launched.
merge modules will solve ur problem .
we are researching on finding a solution other than merge module

ORIGINAL: vijaykodali

Including them as merge module will meet ur requirement.
but many oragnisatons will not like merge modules in their package.
i u dont have such constraints u can go ahead.



The use of merge module's is standard practice, if an organisation does not like them been used it is due to a basic lack of understanding on there part.

However a mergemodule will not install to a protected area any more than a .msi will. If the files are not been installed by a vendor installer (as discribed in my previous post) just exclude them. I have had dozens of applications wanting to install to these areas. Again just exclude the files.

Areas that fall under windows file protection are designed to be updated by Microsoft update's & service packs not .msi files

ORIGINAL: vijaykodali

f we include these files into the application. application will go for self heal every time it is launched.
merge modules will solve ur problem .
we are researching on finding a solution other than merge module


Not sure how including the files will cause a self heal every time the app is launched. All what will happen is the files will not be installed and an entry will be written to the application event log.

You will get the same result even if the files are found in a merge module.

Again the files will more than likely be in a vendor supplied .msi (microsoft supplied .msi based on different packaging technology) buried within the source. If not just exclude them. Install your app and test it.

It might work just fine.