VS2005 Merge Module creating 'Module Retargetable Folder'

[michael_e_obrien]

An issue that I thought was resolved has come back.

I'm trying to include a VS2005 merge module into an installer (currently an uncompressed exe project). When I run the installer, I get the merge module retargetable directory created explicitly:
c:\\Program Files\\New Project\\Module Retargetable Folder\and the assemblies installed into this sub-directory - this is not what I want.

With Installshield, I can set the merge module property to eliminate this issue (yes, I saw it there as well). Is there a work around for this?

Also oddly, the install appeared to be working correctly until this morning - I changed nothing in the merge module (just rebuilt it). Currently, it's the default project with a few project settings and the merge module. I've also tried recreating the entire install with a default InstallAware .Net project with a recreated merge module - with the same results.

I have tried just about everything I can think of, and nothing is working. Please help!

[mberterm]

The first report of this behaviour appears to be documented during the development of Visual Studio 2005. The report indicates that the files contained in a merge module produced by Visual Studio 2005 install to a subdirectory named "Module Retargetable Folder" instead of the intended folder, which by all accounts had been otherwise correctly defined.

This is a change since Visual Studio 2003 and was submitted as a bug during the beta of Visual Studio 2005. This issue was not resolved during the beta program and will be seen in merge modules produced in the release version of the development tool.

Merge Modules: Module installs under "Module Retargetable Folder" instead of intended folder
http://connect.microsoft.com/VisualStud ... kID=105512

The crux of the issue is the difference between the information in the DefaultDir field of the Directory table and the missing '.:' characters of the two merge modules. The addition of these characters indicates that this entry should be handled as a non-root source directory.

Adding the missing '.:' in DefaultDir field of the merge module file, the MSM, should successfully work-around the behaviour.

[michael_e_obrien]

Thanks for the info and the work around.

The only method of editing table fields is using Orca - is that the recommended method? What I'm not sure of, is how to automate this on my build script.

It would be quite handy for InstallAware to offer the ability to set MSM properties <sigh>.

Thanks again

[MichaelNesmith]

You can just edit with Orca once - thereafter, your changes will be "burnt in" to the MSM file, and you can use it in automated builds verbatim without having to re-inject the same edits on each build.