What's inside a package?
-
While I was preparing one of our C# applications to play more nicely with Vista, I came across a quite unexpected behaviour of VS (2003 in our case, didn't check with 2005 yet). In order for the application to demand elevated user rights, I embedded a manifest into the executable by calling a tool (ManifestInjector) during a post-build action. As target file to inject the manifest into I gave
$(TargetPath)and, as I expected, the manifest was injected into...\bin\Release\MyApp.exe. I also have a Setup&Deployment project for this application. In this project I wanted the primary output from the application project to be wrapped into a nice installer package. Because nothing changed in this project, I assumed that the - now manifest-bearing - executable would be included in the setup. I was wrong. Setup was built as usual, I got the output from ManifestInjector telling me that the manifest was included successfully, I tried installing the application under Vista, everything went fine, until I actually ran the application for the first time. There was no dialog requesting admin rights, the app came up just like it did before. Strangely, the executable didn't show the little shield icon you get for applications demanding elevated rights. So I compared the modification date and size of this executable with the one I had in mybin\releasefolder. They were identical. I copied over the executable from thebin\releasefolder and this copy did show the shield icon! :wtf: After a while I found out what was happening: I don't know why the engineers at MS decided to go this way, but actually you get the executable from...\**obj**\Releaseincluded in the msi file when you tell VS you want the primary output. Knowing this it was very easy to fix the problem by embedding the manifest into the...\obj\Release\MyApp.exefile, but if you don't look very carefully it's easy for such a bug to slip through.Regards, mav -- Black holes are the places where God divided by 0...
-
While I was preparing one of our C# applications to play more nicely with Vista, I came across a quite unexpected behaviour of VS (2003 in our case, didn't check with 2005 yet). In order for the application to demand elevated user rights, I embedded a manifest into the executable by calling a tool (ManifestInjector) during a post-build action. As target file to inject the manifest into I gave
$(TargetPath)and, as I expected, the manifest was injected into...\bin\Release\MyApp.exe. I also have a Setup&Deployment project for this application. In this project I wanted the primary output from the application project to be wrapped into a nice installer package. Because nothing changed in this project, I assumed that the - now manifest-bearing - executable would be included in the setup. I was wrong. Setup was built as usual, I got the output from ManifestInjector telling me that the manifest was included successfully, I tried installing the application under Vista, everything went fine, until I actually ran the application for the first time. There was no dialog requesting admin rights, the app came up just like it did before. Strangely, the executable didn't show the little shield icon you get for applications demanding elevated rights. So I compared the modification date and size of this executable with the one I had in mybin\releasefolder. They were identical. I copied over the executable from thebin\releasefolder and this copy did show the shield icon! :wtf: After a while I found out what was happening: I don't know why the engineers at MS decided to go this way, but actually you get the executable from...\**obj**\Releaseincluded in the msi file when you tell VS you want the primary output. Knowing this it was very easy to fix the problem by embedding the manifest into the...\obj\Release\MyApp.exefile, but if you don't look very carefully it's easy for such a bug to slip through.Regards, mav -- Black holes are the places where God divided by 0...
mav.northwind wrote:
Black holes are the places where God divided by 0...
good one! :-D
-
mav.northwind wrote:
Black holes are the places where God divided by 0...
good one! :-D
Super Lloyd wrote:
mav.northwind wrote: Black holes are the places where God divided by 0... good one!
God can't divide by zero, but Chuck Norris can!
-
Super Lloyd wrote:
mav.northwind wrote: Black holes are the places where God divided by 0... good one!
God can't divide by zero, but Chuck Norris can!
Not true - God Divided by zero and Chuck Norris was the result.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
Not true - God Divided by zero and Chuck Norris was the result.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
:laugh:
Regards, Satips.:rose: Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Walk beside me, and just be my friend. - Albert Camus
-
While I was preparing one of our C# applications to play more nicely with Vista, I came across a quite unexpected behaviour of VS (2003 in our case, didn't check with 2005 yet). In order for the application to demand elevated user rights, I embedded a manifest into the executable by calling a tool (ManifestInjector) during a post-build action. As target file to inject the manifest into I gave
$(TargetPath)and, as I expected, the manifest was injected into...\bin\Release\MyApp.exe. I also have a Setup&Deployment project for this application. In this project I wanted the primary output from the application project to be wrapped into a nice installer package. Because nothing changed in this project, I assumed that the - now manifest-bearing - executable would be included in the setup. I was wrong. Setup was built as usual, I got the output from ManifestInjector telling me that the manifest was included successfully, I tried installing the application under Vista, everything went fine, until I actually ran the application for the first time. There was no dialog requesting admin rights, the app came up just like it did before. Strangely, the executable didn't show the little shield icon you get for applications demanding elevated rights. So I compared the modification date and size of this executable with the one I had in mybin\releasefolder. They were identical. I copied over the executable from thebin\releasefolder and this copy did show the shield icon! :wtf: After a while I found out what was happening: I don't know why the engineers at MS decided to go this way, but actually you get the executable from...\**obj**\Releaseincluded in the msi file when you tell VS you want the primary output. Knowing this it was very easy to fix the problem by embedding the manifest into the...\obj\Release\MyApp.exefile, but if you don't look very carefully it's easy for such a bug to slip through.Regards, mav -- Black holes are the places where God divided by 0...
mav.northwind wrote:
Black holes are the places where God divided by 0...
Nice One.
Regards, Satips.:rose: Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Walk beside me, and just be my friend. - Albert Camus