| Groups | Blog | Home |
dotnet setup : Strange Problem With Setup & Deployment Project
1. Inherited application from developer who unfortunately passed away and thus is not available to answer questions. 2. Currently the application has been maintained on his development system; however, that system is due to be reassigned. Therefore the current task at hand is to get the application built from another system. 3. Copied entire source tree from original system to new system and perform build and compare build output - all match - so far so good. Problem: The problem arises when the setup project is built. The IDE (VS.NET 2003) reports the same information for the build process from both machines. However, upon inspection of the resulting .msi file, using ORCA, I have determined that there are 11 entries missing in the progid and class tables, 1 row missing from the component table, 1 row missing from FeatureComponents, 1 row missing from File, 1 row from MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from the Registry table. How is this possible? I have checked and double checked, copied and recopied, compared and recompared my source tree and project files to the originals and all match. I have no visual sign from the IDE that anything is being done differently; however, the .msi file is not the same and the app will not run properly once installed. I look forward to any ideas anyone may have. Thank you,
It looks to me like you've just lost one file (1 file and 1 component) which
is also an assembly (1 row MsiAssembly, 4 rows of MsiAssemblyName stuff like version, publickeytoken etc) which is probably a .NET class library that exports COM interfaces (class, progid, registry). I think it *should* be pretty straightforward to look at old and new MSIs to identify missing files. Compare the two file tables. -- Phil Wilson [MVP Windows Installer] ---- [quoted text, click to view] "D James" <djng04@yahoo.com> wrote in message news:c9c795d6.0404270349.39aa8bec@posting.google.com... > Background: > > 1. Inherited application from developer who unfortunately passed away > and thus is not available to answer questions. > 2. Currently the application has been maintained on his development > system; however, that system is due to be reassigned. Therefore the > current task at hand is to get the application built from another > system. > 3. Copied entire source tree from original system to new system and > perform build and compare build output - all match - so far so good. > > Problem: > > The problem arises when the setup project is built. The IDE (VS.NET > 2003) reports the same information for the build process from both > machines. However, upon inspection of the resulting .msi file, using > ORCA, I have determined that there are 11 entries missing in the > progid and class tables, 1 row missing from the component table, 1 row > missing from FeatureComponents, 1 row missing from File, 1 row from > MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from the > Registry table. > > How is this possible? I have checked and double checked, copied and > recopied, compared and recompared my source tree and project files to > the originals and all match. I have no visual sign from the IDE that > anything is being done differently; however, the .msi file is not the > same and the app will not run properly once installed. > > I look forward to any ideas anyone may have. > > Thank you, > > Fustrated and Confused
I was able to get the missing file back into the .msi; however, the
overall problem still exists. The progid and class files are still 11 entries short. How does it determine what to put into those tables? If the setup project settings (or for that matter the setup project file itself) are identical shouldn't an identical .msi file be built? I'm curious if there are registry entries, or something else, being read/used that exist on the original system but not on my system. Thanks, D James [quoted text, click to view] "Phil Wilson" <Phil.Wilson@unisys.spamcom> wrote in message news:<epI$s1ILEHA.3324@TK2MSFTNGP10.phx.gbl>...
> It looks to me like you've just lost one file (1 file and 1 component) which > is also an assembly (1 row MsiAssembly, 4 rows of MsiAssemblyName stuff like > version, publickeytoken etc) which is probably a .NET class library that > exports COM interfaces (class, progid, registry). I think it *should* be > pretty straightforward to look at old and new MSIs to identify missing > files. Compare the two file tables. > -- > Phil Wilson [MVP Windows Installer] > ---- > "D James" <djng04@yahoo.com> wrote in message > news:c9c795d6.0404270349.39aa8bec@posting.google.com... > > Background: > > > > 1. Inherited application from developer who unfortunately passed away > > and thus is not available to answer questions. > > 2. Currently the application has been maintained on his development > > system; however, that system is due to be reassigned. Therefore the > > current task at hand is to get the application built from another > > system. > > 3. Copied entire source tree from original system to new system and > > perform build and compare build output - all match - so far so good. > > > > Problem: > > > > The problem arises when the setup project is built. The IDE (VS.NET > > 2003) reports the same information for the build process from both > > machines. However, upon inspection of the resulting .msi file, using > > ORCA, I have determined that there are 11 entries missing in the > > progid and class tables, 1 row missing from the component table, 1 row > > missing from FeatureComponents, 1 row missing from File, 1 row from > > MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from the > > Registry table. > > > > How is this possible? I have checked and double checked, copied and > > recopied, compared and recompared my source tree and project files to > > the originals and all match. I have no visual sign from the IDE that > > anything is being done differently; however, the .msi file is not the > > same and the app will not run properly once installed. > > > > I look forward to any ideas anyone may have. > > > > Thank you, > >
The solution is already under source control and I have tried pulling from source. It is really weird. I have used a compare tool to verify that all project files match. Perform a build, the build logs match, the reported list of files packed match. Everything seems to match. I do still have access to the machine, but I don't know what else to look for or try
----- a b wrote: ---- If it's not too late, can you use the original machine and add the solution to a source control system like SourceSafe, then get it from the other machine? Maybe whatever's missing will get created/retrieved when you do it through Visual Studio instead of just copying the file structure -- Danie [quoted text, click to view] D James wrote
> I was able to get the missing file back into the .msi; however, th > overall problem still exists. The progid and class files are still 1 > entries short. How does it determine what to put into those tables? > If the setup project settings (or for that matter the setup projec > file itself) are identical shouldn't an identical .msi file be built? > I'm curious if there are registry entries, or something else, bein > read/used that exist on the original system but not on my system >> Thanks >> D Jame
If it's not too late, can you use the original machine and add the
solution to a source control system like SourceSafe, then get it from the other machine? Maybe whatever's missing will get created/retrieved when you do it through Visual Studio instead of just copying the file structure. -- Daniel [quoted text, click to view] D James wrote:
> I was able to get the missing file back into the .msi; however, the > overall problem still exists. The progid and class files are still 11 > entries short. How does it determine what to put into those tables? > If the setup project settings (or for that matter the setup project > file itself) are identical shouldn't an identical .msi file be built? > I'm curious if there are registry entries, or something else, being > read/used that exist on the original system but not on my system. > > Thanks, > > D James >
If you're using Orca to look in the original MSI file, those original progid
and class entries have a component reference, and that component has a key file path, a key into the file table. That's how you determine which file the registry entries might be associated with, so there might be registration that's not working (an assembly marked as vsdraCOM, for example). Hopefully you are sure that the original developer didn't add those entries manually with something like Orca. -- Phil Wilson [MVP Windows Installer] ---- [quoted text, click to view] "D James" <djng04@yahoo.com> wrote in message news:c9c795d6.0404280318.1b846957@posting.google.com... > I was able to get the missing file back into the .msi; however, the > overall problem still exists. The progid and class files are still 11 > entries short. How does it determine what to put into those tables? > If the setup project settings (or for that matter the setup project > file itself) are identical shouldn't an identical .msi file be built? > I'm curious if there are registry entries, or something else, being > read/used that exist on the original system but not on my system. > > Thanks, > > D James > > "Phil Wilson" <Phil.Wilson@unisys.spamcom> wrote in message news:<epI$s1ILEHA.3324@TK2MSFTNGP10.phx.gbl>... > > It looks to me like you've just lost one file (1 file and 1 component) which > > is also an assembly (1 row MsiAssembly, 4 rows of MsiAssemblyName stuff like > > version, publickeytoken etc) which is probably a .NET class library that > > exports COM interfaces (class, progid, registry). I think it *should* be > > pretty straightforward to look at old and new MSIs to identify missing > > files. Compare the two file tables. > > -- > > Phil Wilson [MVP Windows Installer] > > ---- > > "D James" <djng04@yahoo.com> wrote in message > > news:c9c795d6.0404270349.39aa8bec@posting.google.com... > > > Background: > > > > > > 1. Inherited application from developer who unfortunately passed away > > > and thus is not available to answer questions. > > > 2. Currently the application has been maintained on his development > > > system; however, that system is due to be reassigned. Therefore the > > > current task at hand is to get the application built from another > > > system. > > > 3. Copied entire source tree from original system to new system and > > > perform build and compare build output - all match - so far so good. > > > > > > Problem: > > > > > > The problem arises when the setup project is built. The IDE (VS.NET > > > 2003) reports the same information for the build process from both > > > machines. However, upon inspection of the resulting .msi file, using > > > ORCA, I have determined that there are 11 entries missing in the > > > progid and class tables, 1 row missing from the component table, 1 row > > > missing from FeatureComponents, 1 row missing from File, 1 row from > > > MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from the > > > Registry table. > > > > > > How is this possible? I have checked and double checked, copied and > > > recopied, compared and recompared my source tree and project files to > > > the originals and all match. I have no visual sign from the IDE that > > > anything is being done differently; however, the .msi file is not the > > > same and the app will not run properly once installed. > > > > > > I look forward to any ideas anyone may have. > > > > > > Thank you, > > > > > > Fustrated and Confused
He definitely didn't use Orca. Regardless, I can rebuild it from his system as many times as I want and it always produces a correct .msi file. Can you give me some insight as to why a registration might fail
----- Phil Wilson wrote: ---- If you're using Orca to look in the original MSI file, those original progi and class entries have a component reference, and that component has a ke file path, a key into the file table. That's how you determine which fil the registry entries might be associated with, so there might b registration that's not working (an assembly marked as vsdraCOM, fo example). Hopefully you are sure that the original developer didn't ad those entries manually with something like Orca -- Phil Wilson [MVP Windows Installer --- "D James" <djng04@yahoo.com> wrote in messag news:c9c795d6.0404280318.1b846957@posting.google.com.. [quoted text, click to view] > I was able to get the missing file back into the .msi; however, th > overall problem still exists. The progid and class files are still 1 > entries short. How does it determine what to put into those tables > If the setup project settings (or for that matter the setup projec > file itself) are identical shouldn't an identical .msi file be built > I'm curious if there are registry entries, or something else, bein > read/used that exist on the original system but not on my system >> Thanks >> D Jame >> "Phil Wilson" <Phil.Wilson@unisys.spamcom> wrote in messag news:<epI$s1ILEHA.3324@TK2MSFTNGP10.phx.gbl>.. >> It looks to me like you've just lost one file (1 file and 1 component whic >> is also an assembly (1 row MsiAssembly, 4 rows of MsiAssemblyName stuf lik >> version, publickeytoken etc) which is probably a .NET class library tha >> exports COM interfaces (class, progid, registry). I think it *should* b >> pretty straightforward to look at old and new MSIs to identify missin >> files. Compare the two file tables >> -- >> Phil Wilson [MVP Windows Installer >> --- >> "D James" <djng04@yahoo.com> wrote in messag >> news:c9c795d6.0404270349.39aa8bec@posting.google.com.. >>> Background >>>>>> 1. Inherited application from developer who unfortunately passed awa >>> and thus is not available to answer questions >>> 2. Currently the application has been maintained on his developmen >>> system; however, that system is due to be reassigned. Therefore th >>> current task at hand is to get the application built from anothe >>> system >>> 3. Copied entire source tree from original system to new system an >>> perform build and compare build output - all match - so far so good >>>>>> Problem >>>>>> The problem arises when the setup project is built. The IDE (VS.NE >>> 2003) reports the same information for the build process from bot >>> machines. However, upon inspection of the resulting .msi file, usin >>> ORCA, I have determined that there are 11 entries missing in th >>> progid and class tables, 1 row missing from the component table, 1 ro >>> missing from FeatureComponents, 1 row missing from File, 1 row fro >>> MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from th >>> Registry table >>>>>> How is this possible? I have checked and double checked, copied an >>> recopied, compared and recompared my source tree and project files t >>> the originals and all match. I have no visual sign from the IDE tha >>> anything is being done differently; however, the .msi file is not th >>> same and the app will not run properly once installed >>>>>> I look forward to any ideas anyone may have >>>>>> Thank you >>>>>> Fustrated and Confuse
If you added the missing file, was it an assembly as I suggested? If so,
what did you set the Register property value to? I'm thinking if you had add the assembly back into the VS project, you'd need to set some registration value. -- Phil Wilson [MVP Windows Installer] ---- [quoted text, click to view] "D James" <djng04@yahoo.com> wrote in message system as many times as I want and it always produces a correct .msi file.news:4B5A2444-7D25-4810-8898-94610F6AC07A@microsoft.com... > He definitely didn't use Orca. Regardless, I can rebuild it from his Can you give me some insight as to why a registration might fail? [quoted text, click to view] > > ----- Phil Wilson wrote: ----- > > If you're using Orca to look in the original MSI file, those original progid > and class entries have a component reference, and that component has a key > file path, a key into the file table. That's how you determine which file > the registry entries might be associated with, so there might be > registration that's not working (an assembly marked as vsdraCOM, for > example). Hopefully you are sure that the original developer didn't add > those entries manually with something like Orca. > -- > Phil Wilson [MVP Windows Installer] > ---- > "D James" <djng04@yahoo.com> wrote in message > news:c9c795d6.0404280318.1b846957@posting.google.com... > > I was able to get the missing file back into the .msi; however, the > > overall problem still exists. The progid and class files are still 11 > > entries short. How does it determine what to put into those tables? > > If the setup project settings (or for that matter the setup project > > file itself) are identical shouldn't an identical .msi file be built? > > I'm curious if there are registry entries, or something else, being > > read/used that exist on the original system but not on my system. > >> Thanks, > >> D James > >> "Phil Wilson" <Phil.Wilson@unisys.spamcom> wrote in message > news:<epI$s1ILEHA.3324@TK2MSFTNGP10.phx.gbl>... > >> It looks to me like you've just lost one file (1 file and 1 component) > which > >> is also an assembly (1 row MsiAssembly, 4 rows of MsiAssemblyName stuff > like > >> version, publickeytoken etc) which is probably a .NET class library that > >> exports COM interfaces (class, progid, registry). I think it *should* be > >> pretty straightforward to look at old and new MSIs to identify missing > >> files. Compare the two file tables. > >> -- > >> Phil Wilson [MVP Windows Installer] > >> ---- > >> "D James" <djng04@yahoo.com> wrote in message > >> news:c9c795d6.0404270349.39aa8bec@posting.google.com... > >>> Background: > >>>>>> 1. Inherited application from developer who unfortunately passed away > >>> and thus is not available to answer questions. > >>> 2. Currently the application has been maintained on his development > >>> system; however, that system is due to be reassigned. Therefore the > >>> current task at hand is to get the application built from another > >>> system. > >>> 3. Copied entire source tree from original system to new system and > >>> perform build and compare build output - all match - so far so good. > >>>>>> Problem: > >>>>>> The problem arises when the setup project is built. The IDE (VS.NET > >>> 2003) reports the same information for the build process from both > >>> machines. However, upon inspection of the resulting .msi file, using > >>> ORCA, I have determined that there are 11 entries missing in the > >>> progid and class tables, 1 row missing from the component table, 1 row > >>> missing from FeatureComponents, 1 row missing from File, 1 row from > >>> MsiAssembly, 4 rows from MsiAssemblyName, and 132 rows from the > >>> Registry table. > >>>>>> How is this possible? I have checked and double checked, copied and > >>> recopied, compared and recompared my source tree and project files to > >>> the originals and all match. I have no visual sign from the IDE that > >>> anything is being done differently; however, the .msi file is not the > >>> same and the app will not run properly once installed. > >>>>>> I look forward to any ideas anyone may have. > >>>>>> Thank you, > >>>>>> Fustrated and Confused > > >
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
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |