|
|
You're in the
visual studio .net general
group:"Setup Project" "Detected dependencies" vc_user_atl71_rtl_x86_---.msm versus atl71.dll
visual studio .net general:
Hi all,
two PCs: both of them have Visual Studio 7.1.3088 .NET Framework 1.14322 SP1 but PC1 has: Microsoft Visual Basic .NET 69586-335-0000007-18364 Microsoft Visual C# .NET 69586-335-0000007-18364 Microsoft Visual C++ .NET 69586-335-0000007-18364 Microsoft Visual J# .NET 69586-335-0000007-18364 Crystal Reports for Visual Studio .NET AAP50-GS00000-U7000RN while PC2 has: Microsoft Visual Basic .NET 69586-335-0000007-18687 Microsoft Visual C# .NET 69586-335-0000007-18687 Microsoft Visual C++ .NET 69586-335-0000007-18687 Microsoft Visual J# .NET 69586-335-0000007-18687 Crystal Reports for Visual Studio .NET AAP50-GS00000-U7000RN Microsoft Application Center Test The same "Setup Project" (vdproj) has one of the "Detected Dependencies" set to atl71.dll on PC1 while it is set to vc_user_atl71_rtl_x86_---.msm on PC2. What is the meaning of this difference? Is this difference (that is an annoying difference because the vdproj is under CVS repository and got changed from machien to machine...) due to the different version of C++ .NET that is 69586-335-0000007-18364 on PC1 and 69586-335-0000007-18687 on PC2? How to solve this problem? Thanks in advance. Alessandro.
Alessandro, what is happening her is that on one machine the setup project
is finding an MSM that matches the file it wants to add. On the other machine it is not so it adds the actual file. There are two reasons why it will not find the file on PC1, the file (msm) is not on the machine or the path to file is not included in the search path for the setup project. Easiest solution add the file from PC2 to PC1 in its search path, default location [program files]\common files\merge modules. I hope this helps. Todd Derksen -------------------- Visual Basic Deployment Test Team This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- [quoted text, click to view] >From: uvts_cvs@yahoo.com
>Newsgroups: microsoft.public.vsnet.general >Subject: "Setup Project" "Detected dependencies" vc_user_atl71_rtl_x86_---.msm versus atl71.dll > >Hi all, >two PCs: >both of them have Visual Studio 7.1.3088 .NET Framework 1.14322 SP1 > >but PC1 has: > >Microsoft Visual Basic .NET 69586-335-0000007-18364 >Microsoft Visual C# .NET 69586-335-0000007-18364 >Microsoft Visual C++ .NET 69586-335-0000007-18364 >Microsoft Visual J# .NET 69586-335-0000007-18364 >Crystal Reports for Visual Studio .NET AAP50-GS00000-U7000RN > >while PC2 has: > >Microsoft Visual Basic .NET 69586-335-0000007-18687 >Microsoft Visual C# .NET 69586-335-0000007-18687 >Microsoft Visual C++ .NET 69586-335-0000007-18687 >Microsoft Visual J# .NET 69586-335-0000007-18687 >Crystal Reports for Visual Studio .NET AAP50-GS00000-U7000RN >Microsoft Application Center Test > >The same "Setup Project" (vdproj) has one of the "Detected >Dependencies" set to atl71.dll on PC1 while it is set to >vc_user_atl71_rtl_x86_---.msm on PC2. > >What is the meaning of this difference? > >Is this difference (that is an annoying difference because the vdproj >is under CVS repository and got changed from machien to machine...) due >to the different version of C++ .NET that is 69586-335-0000007-18364 on >PC1 and 69586-335-0000007-18687 on PC2? > >How to solve this problem? > >Thanks in advance. >Alessandro. > >
[quoted text, click to view] Todd Derksen [MSFT] wrote: > Alessandro, what is happening her is that on one machine the setup project > is finding an MSM that matches the file it wants to add. On the other > machine it is not so it adds the actual file. > There are two reasons why it will not find the file on PC1, the file (msm) > is not on the machine or the path to file is not included in the search > path for the setup project. > Easiest solution add the file from PC2 to PC1 in its search path, default > location [program files]\common files\merge modules. Thank you very much. Actually in PC1 [program files]\common files\merge modules is missing, but why is it missing? Is it missing because different version of Microsoft Visual C++ .NET are installed in PC1, PC2? Is it missing because in PC1 "Microsoft Application Center Test" is missing? Best Regards, Alessandro.
Alessandro
If I understand this situation correctly, the entire merge module folder is missing from one of the machines. I do not know why that would happen, have there been other installs\uninstalls on the machine? Does copying over the entire merge module folder and verifying it is on the path for setup projects solve your problem? Thanks Todd Derksen -------------------- Visual Basic Deployment Test Team This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- [quoted text, click to view] >From: uvts_cvs@yahoo.com
>Newsgroups: microsoft.public.vsnet.general >Subject: Re: "Setup Project" "Detected dependencies" vc_user_atl71_rtl_x86_---.msm versus atl71.dll > >Todd Derksen [MSFT] wrote: >> Alessandro, what is happening her is that on one machine the setup >project >> is finding an MSM that matches the file it wants to add. On the >other >> machine it is not so it adds the actual file. >> There are two reasons why it will not find the file on PC1, the file >(msm) >> is not on the machine or the path to file is not included in the >search >> path for the setup project. >> Easiest solution add the file from PC2 to PC1 in its search path, >default >> location [program files]\common files\merge modules. > >Thank you very much. > >Actually in PC1 [program files]\common files\merge modules is missing, >but why is it missing? >Is it missing because different version of Microsoft Visual C++ .NET >are installed in PC1, PC2? >Is it missing because in PC1 "Microsoft Application Center Test" is >missing? > >Best Regards, >Alessandro. > >
[quoted text, click to view]
Todd Derksen [MSFT] wrote: > Alessandro > If I understand this situation correctly, the entire merge module folder is > missing from one of the machines. > I do not know why that would happen, have there been other > installs\uninstalls on the machine? Todd, first of all thank you very much for your attention. o.s. of PC1 is xp in italian so I have "C:\Programmi\File comuni\Merge Modules" rather than "C:\Program Files\Common Files\Merge Modules", now in "C:\Programmi\File comuni\Merge Modules" PC1 actually has some *.msm files but vc_user_atl71_rtl_x86_---.msm is missing. [quoted text, click to view] > Does copying over the entire merge module folder and verifying it is on the > path for setup projects solve your problem? > maybe it solves the problem but I would like to know a slightly different thing: I think the situation is now clearer: since PC1 hasn't C:\Programmi\File comuni\Merge Modules\vc_user_atl71_rtl_x86_---.msm but has c:\windows\system32\atl71.dll the detected dependecies reports the latter. On the other hand PC1 has both C:\Programmi\File comuni\Merge Modules\vc_user_atl71_rtl_x86_---.msm and c:\windows\system32\atl71.dll but maybe visual studio is set to search first in C:\Programmi\File comuni\Merge Modules\: how can I change from visual studio the setting in order it searches first in c:\windows\system32, or maybe avoiding at all the search in C:\Programmi\File comuni\Merge Modules? Best regards, Alessandro.
Alessandro,
The way it works is it checks all of the Merge Modules on the search path for the file that is being added. It will always choose a merge module if there is one available. If you want VS to not find the Merge Module open the SearchPath Dialog in the properties grid of the setup project by clicking the "..." button. Then uncheck the include standard search paths checkbox. Your project should no longer find MSMs. On the other hand I would suggest including MSMs rather then actual files. With an MSM there is more control over a file being deployed. It gives the opportunity for the file or group of files to include specific instructions to the MSI being created. Todd Derksen -------------------- Visual Basic Deployment Test Team This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- [quoted text, click to view] >From: uvts_cvs@yahoo.com
>Newsgroups: microsoft.public.vsnet.general >Subject: Re: "Setup Project" "Detected dependencies" vc_user_atl71_rtl_x86_---.msm versus atl71.dll >Date: 9 Mar 2005 05:04:05 -0800 > >Todd Derksen [MSFT] wrote: >> Alessandro >> If I understand this situation correctly, the entire merge module >folder is >> missing from one of the machines. >> I do not know why that would happen, have there been other >> installs\uninstalls on the machine? > >Todd, first of all thank you very much for your attention. >o.s. of PC1 is xp in italian so I have "C:\Programmi\File comuni\Merge >Modules" rather than "C:\Program Files\Common Files\Merge Modules", now >in "C:\Programmi\File comuni\Merge Modules" PC1 actually has some *.msm >files but vc_user_atl71_rtl_x86_---.msm is missing. > >> Does copying over the entire merge module folder and verifying it is >on the >> path for setup projects solve your problem? >> > >maybe it solves the problem but I would like to know a slightly >different thing: > >I think the situation is now clearer: > >since PC1 hasn't C:\Programmi\File comuni\Merge >Modules\vc_user_atl71_rtl_x86_---.msm but has >c:\windows\system32\atl71.dll the detected dependecies reports the >latter. > >On the other hand PC1 has both C:\Programmi\File comuni\Merge >Modules\vc_user_atl71_rtl_x86_---.msm and c:\windows\system32\atl71.dll >but maybe visual studio is set to search first in C:\Programmi\File >comuni\Merge Modules\: how can I change from visual studio the setting >in order it searches first in c:\windows\system32, or maybe avoiding at >all the search in C:\Programmi\File comuni\Merge Modules? > >Best regards, >Alessandro. > >
Todd, thank you for your reply.
[quoted text, click to view] Todd Derksen [MSFT] wrote: > Alessandro, > The way it works is it checks all of the Merge Modules on the search path > for the file that is being added. It will always choose a merge module if > there is one available. If you want VS to not find the Merge Module open > the SearchPath Dialog in the properties grid of the setup project by > clicking the "..." button. Then uncheck the include standard search paths > checkbox. Your project should no longer find MSMs. OK, I tried successfully the above. [quoted text, click to view] > On the other hand I would suggest including MSMs rather then actual files. > With an MSM there is more control over a file being deployed. It gives the > opportunity for the file or group of files to include specific instructions > to the MSI being created. the above opportunity it isn't so clear to me, may you give me some links to web pages documenting it? thank you again, Alessandro.
Alessandro, a merge module is basically a setup project that is made to be
added to another setup project. rather then just adding a file, it can do custom configuration that the file may need, include any nessecary EULA's, specify where the file should be installed to and include any files it may reference. In the case of atl71.dll I am not sure if a EULA is required, but including the merge module allows it to go to a shared location rather then automatically next to your file as direct references do. You can read about Merge Modules here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/m erge_module_database.asp Todd Derksen -------------------- Visual Basic Deployment Test Team This posting is provided "AS IS" with no warranties, and confers no rights.\ -------------------- [quoted text, click to view] >From: uvts_cvs@yahoo.com
>Newsgroups: microsoft.public.vsnet.general >Subject: Re: "Setup Project" "Detected dependencies" vc_user_atl71_rtl_x86_---.msm versus atl71.dll >Date: 14 Mar 2005 04:34:02 -0800 > >Todd, thank you for your reply. > >Todd Derksen [MSFT] wrote: >> Alessandro, >> The way it works is it checks all of the Merge Modules on the search >path >> for the file that is being added. It will always choose a merge >module if >> there is one available. If you want VS to not find the Merge Module >open >> the SearchPath Dialog in the properties grid of the setup project by >> clicking the "..." button. Then uncheck the include standard search >paths >> checkbox. Your project should no longer find MSMs. > >OK, I tried successfully the above. > >> On the other hand I would suggest including MSMs rather then actual >files. >> With an MSM there is more control over a file being deployed. It >gives the >> opportunity for the file or group of files to include specific >instructions >> to the MSI being created. > >the above opportunity it isn't so clear to me, may you give me some >links to web pages documenting it? > >thank you again, >Alessandro. > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |