Hi
I'm packaging an application and it needs to copy msxml4.dll og msxml4r.dll to c:\windows\WinSxS\x86_..... and the .cat and .manifest-files to c:\windows\WinSxS\Manifests.
The problem is that it puts both the Manifest-files and the .dll's to c:\windows. NOT under WinSxS. I've also tried with Merge Modules, but these 6 files refuse.

Do anybody have a clue to help me?

The full path wanted is:
C:\WINDOWS\WinSxS\x86_Microsoft.MSXML2_6bd6b9abf345378f_4.20.9818.0_x-ww_8ff50c5d\msxml4.dll
C:\WINDOWS\WinSxS\x86_Microsoft.MSXML2R_6bd6b9abf345378f_4.1.0.0_x-ww_29c3ad6a\msxml4r.dll
c:\windows\WinSxS\Manifests\x86_Microsoft.MSXML2_6bd6b9abf345378f_4.20.9818.0_x-ww_8ff50c5d.cat
c:\windows\WinSxS\Manifests\x86_Microsoft.MSXML2_6bd6b9abf345378f_4.20.9818.0_x-ww_8ff50c5d.Manifest
c:\windows\WinSxS\Manifests\x86_Microsoft.MSXML2R_6bd6b9abf345378f_4.1.0.0_x-ww_29c3ad6a.cat
c:\windows\WinSxS\Manifests\x86_Microsoft.MSXML2R_6bd6b9abf345378f_4.1.0.0_x-ww_29c3ad6a.Manifest

The path I get is:
C:\WINDOWS\x86_Microsoft.MSXML2_6bd6b9abf345378f_4.20.9818.0_x-ww_8ff50c5d\msxml4.dll
C:\WINDOWS\x86_Microsoft.MSXML2R_6bd6b9abf345378f_4.1.0.0_x-ww_29c3ad6a\msxml4r.dll
etc

Best regards
Binque

I wanted to post the log-file aswell, but couldnt upload anything here.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Hi Binque,

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

Thanks
Answered 09/15/2008 by: anitha_accen
Blue Belt

Please log in to comment
0
For msxml you should use the merge module instead.
Answered 09/15/2008 by: AngelD
Red Belt

Please log in to comment
0
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.
Answered 09/15/2008 by: VBScab
Red Belt

Please log in to comment
0
Ian,

Do you think binque will monitor this thread after ~1,5 years? ;)
Answered 09/15/2008 by: AngelD
Red Belt

Please log in to comment
0
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] :)
Answered 09/15/2008 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 09/16/2008 by: binque
Yellow Belt

Please log in to comment
0
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? ;)
Answered 09/16/2008 by: AngelD
Red Belt

Please log in to comment
0
I have powers beyond human comprehension. Let's leave it at that. LOL
Answered 09/16/2008 by: VBScab
Red Belt

Please log in to comment
0
hehe nice Ian
Answered 09/16/2008 by: AngelD
Red Belt

Please log in to comment
2
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.
Answered 09/18/2008 by: vijaykodali
Senior Yellow Belt

Please log in to comment
0
I'm sure using the merge module would "fixed" the WPR/WFP problem.
Answered 09/18/2008 by: AngelD
Red Belt

Please log in to comment
0
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.
Answered 09/19/2008 by: vijaykodali
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/17/2008 by: Coriolus
Orange Belt

Please log in to comment
0
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
Answered 10/17/2008 by: DLL_HELL
Senior Yellow Belt

Please log in to comment
0
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
Answered 10/18/2008 by: vijaykodali
Senior Yellow Belt

Please log in to comment
0
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
Answered 10/19/2008 by: DLL_HELL
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/19/2008 by: DLL_HELL
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity