| Subject: Build Setup and Deployment Project Problems |
| Group: microsoft.public.vstudio.general |
| Date: 7/14/2008 7:28:56 AM |
| From: "emcinerney.nospam@yahoo.com" [Email Address Protection] |
Windows Installer issues building Setup Deployment Project in Visual Studio 2005. Using two machines both with the following software configuration: - Windows XP Pro SP3 - Visual Studio 2005 Professional 8.0.50727.762 (SP.050727-7600) with ENU Service Pack 1 (KB926601) - Microsoft .NET Framework 2.0.50727 SP1 - Windows Installer 3.1.4001.5512 There are two problems that may or may not be related. 1. During installation of the setup via the .msi file the following error occurs: "Error writing to file <filename>. Verify that you have access to that directory" This appears to occur because the same .dll is packaged into a contained .msm multiple times. The workaround is to manually copy the .dll into the GAC (C:\Windows \Assembly)=85I assume that the setup detects the version of the .dll is already installed and then skips the extraction of the .dll(s) from the package into the temp install folder. 2. (This may be the cause of problem 1, I just don=92t have another workaround for this problem yet.) Each time the solution is built the setup deployment project appears to add another instance of one of the .dlls (built by another project in the solution) to the package. Background: We use Visual Build Professional 6.4 to automate our build process. We configure this to increment the versions of our projects; according to the Visual Build documentation, this option causes the solution/ project to be built again: =93After building or rebuilding a project, the original timestamp of the target executable is compared with the timestamp after building. If it has changed, the custom action increments the version and builds the project again (the second build will just recompile the resources and link).=94 In addition to this, we have altered the build process to rebuild the solution again. The reason for this (and please suggest workarounds if you can) is that this solution contains projects with circular references (project references) to each other. The best way I could find to get the version numbers incremented and synchronized was to build the solution again after the version numbers have been incremented=85thus updating the versions being referenced. For instance if we are going to build version 25, when Project A is built it references version 24 of Project B; when Project B is built it will reference the new version 25 of Project A. In order to get version 25 of Project A to reference the new version 25 of Project B we must rebuild the solution (w/o incrementing the version again obviously). So, we wind up with up to 3 instances of some .dlls in the .msm package. Visual Build passes the following command line to Visual Studio to build the solution: "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com" "C: \Work\DataServices.sln" /rebuild "Release|Any CPU" If I run this manually (removing Visual Build from the scenario) I still have the problem... On the build machine this causes the problem (adding duplicate files to the package). On my development machine, this works fine and the Setup only packages a single instance of each .dll. My presumption is that for *some* reason Windows Installer is behaving differently on the build machine than on my development machine, but I don't know why or how to resolve this. I've compared the versions of msi.dll, msiexec.exe, & msihnd.dll, and they're the same on both machines. Ideas anyone? |
| Back |