Win64 "Program Files", .NET Installer, and Normal shortcuts
David
be installed to "Program Files" and not "Program Files (x86)" when installed
to Win64 (64-bit Itanium Windows 2003)? I am currently using Visual Studio
Installer 1.1 and Orca in a Win32 development environment.
I did not see a Visual Studio Installer 2.0 anywhere and would prefer not to
use the Visual Installer from Visual Studio .NET (though I could if I have
to). If the Visual Studio .NET Installer is the same as Visual Studio
Installer 2.0, can one install and use just the Visual Studio .NET Installer
and not all the rest of Visual Studio .NET?
Is there a way to have the Installer produce a "normal" desktop shortcut,
one that shows the install directory and allows "find target"? I know how to
use Orca successfully to fill in the "Start In" field, by specifying
TARGETDIR in the Shortcuts / WkDir field, but the Properties / "Find Target"
is still unavailable. Apparently Visual Installer .NET allows one to specify
the "Start In" field itself.
Thanks,
David
(Please post any replies to microsoft.public.platformsdk.msi)
Phil Wilson
There's a bit more than that if you've got 64-bit apps though, because you'll need to mark the
installer components as 64-bit, anf maybe worry about the registry too.
I think you would actually be better off with Visual Studio.NET (or VS 2003) to build setup
projects - deployment projects are standard in them both. You can use VS.NET and VS 2003 and Visual
Studio 6.0 on the same sysetm, so you can build deployment projects with the latest VS and still
build code with VS 6.0.
VS.NET and 2003 setup projects have the user's desktop as a destination for a shortcut to a file
you're installing. It's pretty straightforward. I forget what VS 1.1 does. I think the issue you've
got is that those shortcuts are installer shortcuts that are resilient (remove the target and it
will repair it) and don't let you change their contents.
"David" <NOS...@NOSPAM.COM> wrote in message news:HeKpa.3963$ac.3...@twister.austin.rr.com...
David
solution. The overt functional difference I see is that the installer now
gives the user a "Just Me" or "All Users" option and fills in WkDir
to TARGETDIR under shortcuts, which eliminate that subsequent Orca
edit step. I don't see a platform selection option though.
"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:uCGLqVo...@TK2MSFTNGP11.phx.gbl...
>The installer property that points to the 64-bit program files folder is
ProgramFiles64Folder.
>There's a bit more than that if you've got 64-bit apps though, because
you'll need to mark the
>installer components as 64-bit, and maybe worry about the registry too.
I have a simple install with no registry values nor registered extensions,
just files to be copied to a folder and a shortcut added.
I changed the File System, Application Folder Default location to
[ProgramFiles64Folder]\[ProductName] instead of
[ProgramFilesFolder]\[ProductName].
Orca shows that change was reflected in the .MSI under CustomAction.
Action:DIRCA_TARGETDIR
Type:307
Source:TARGETDIR
Target:[ProgramFiles64Folder]\[ProductName]
instead of
Target:[ProgramFilesFolder]\[ProductName]
and the msdn documentation lists the components you mention.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/u
sing_64_bit_windows_installer_packages.asp
It's Page Count Summary = 200
and Template Summary = Intel64
Since I didn't see a way to specify them in VSI .NET, I used Orca and went
to
the Property table listed on the left column and did an "Add Row" where I
added "Page Count Summary"under property and 200 under value (and the
similar action for Template Summary). I assume that's what they mean by
"setting the Page Count Summary Property to the integer 200" and
"Enter 'Intel64' into the platform field of the Template Summary Property."
Maybe not....
Similarly, I used Orca to set the attributes column of every component under
Component to 256, msidbComponentAttributes64bit, instead of 0.
I think that's all I should have to do, but the install on an Itanium
Win64-3790 still defaults to Program Files (x86).
"Phil Wilson" <phil....@unisys.spamcom> wrote in message
>I think you would actually be better off with Visual Studio.NET (or VS
2003) to build setup
>projects - deployment projects are standard in them both. You can use
VS.NET and VS 2003 and Visual
>Studio 6.0 on the same system, so you can build deployment projects with
the latest VS and still
>build code with VS 6.0.
"David" <NOS...@NOSPAM.COM> wrote in message
news:HeKpa.3963$ac.3...@twister.austin.rr.com...
> How does one specify in an MSI file that a native 64-bit application
should
> be installed to "Program Files" and not "Program Files (x86)" when
installed
> to Win64 (64-bit Itanium Windows 2003)? I am currently using Visual Studio
> Installer 1.1 and Orca in a Win32 development environment.
>
>
> Thanks,
> David
>
> (Please post any replies to microsoft.public.platformsdk.msi)
Thanks for the suggestions,
David
Phil Wilson
products from InstallShield, Wise, ActiveInstall, WinInstall and so on that use much more of the
Windows Installer functionality. You should be able to set the 64-bit folder properties manually in
the IDE, but you'd need Orca or a post-processing program to set the 64-bit fields in the components
etc.
--
Phil Wilson [MVP Windows Installer]
"David" <NOS...@NOSPAM.COM> wrote in message news:n5%pa.8732$q02.4...@twister.austin.rr.com...
David
Thanks again for your suggestions and assistance
I might look into those other products but I suspect they would be overkill
since my install needs are really quite simple (except that I need it for
Win64 and they might not do that anyway). One nice thing about VSI.NET
is that I could build my application and the install package in a single
environment and a single step.
Unfortunately, although I followed the Microsoft guidelines from the MSDN,
neither VSI.NET nor VSI 6.0 actually made the install default to "Program
Files" instead of "Program Files (x86)."
"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:OamxtksC...@TK2MSFTNGP11.phx.gbl...
> True, Visual Studio's setup projects aren't fully-featured. It's not
designed to compete with the
> products from InstallShield, Wise, ActiveInstall, WinInstall and so on
that use much more of the
> Windows Installer functionality. You should be able to set the 64-bit
folder properties manually in
> the IDE, but you'd need Orca or a post-processing program to set the
64-bit fields in the components
> etc.
> --
> Phil Wilson [MVP Windows Installer]
With Orca, I saw that the CustomAction field DIRCA_TARGETDIR (with Source
TARGETDIR) was changed to Target [ProgramFiles64Folder] instead of
[ProgramFilesFolder], which seems good. However, the AdminExecuteSequence,
AdminUISequence, InstallExecuteSequence, and InstallUISequence all still had
DIRCA_TARGETDIR: TARGETDIR=""
When I set each of the four to TARGETDIR=[ProgramFiles64Folder], the
installer fails with code 2717.
When I set each of the four to TARGETDIR=ProgramFiles64Folder, the installer
puts c:\ as the default directory.
A debug log of the install with the original TARGETDIR="" in those four
places follows.
It clearly and incorrectly sets Property(C): TARGETDIR = C:\Program Files
(x86)\My XP Test Project Name\
=== Verbose logging started: 4/24/2003 21:14:15 Build type: SHIP UNICODE
2.00.3790.00 Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (D0:E8): Resetting cached policy values
MSI (c) (D0:E8): Machine policy value 'Debug' is 7
MSI (c) (D0:E8): ******* RunEngine:
******* Product: My XP Test Project Name.msi
******* Action:
...
MSI (c) (D0:E8): Doing action: DIRCA_TARGETDIR
Action start 21:14:17: DIRCA_TARGETDIR.
Action ended 21:14:17: DIRCA_TARGETDIR. Return value 1.
MSI (c) (D0:E8): Doing action: DIRCA_NEWPROPERTY1
Action start 21:14:17: DIRCA_NEWPROPERTY1.
Action ended 21:14:17: DIRCA_NEWPROPERTY1. Return value 1.
MSI (c) (D0:E8): Doing action: CostInitialize
Action start 21:14:17: CostInitialize.
Action ended 21:14:18: CostInitialize. Return value 1.
...
MSI (c) (D0:E8): Skipping action: ResumeForm (condition is false)
MSI (c) (D0:E8): Skipping action: MaintenanceForm (condition is false)
MSI (c) (D0:E8): Doing action: CostFinalize
Action start 21:14:18: CostFinalize.
MSI (c) (D0:E8): Note: 1: 2262 2: Patch 3: -2147287038
MSI (c) (D0:E8): Note: 1: 2262 2: Condition 3: -2147287038
MSI (c) (D0:E8): WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute
17 characters in 'C:\Program Files\My XP Test Project Name\' folder path.
(mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (c) (D0:E8): WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute
17 characters in 'C:\Program Files\My XP Test Project Name\' folder path.
(mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (c) (D0:E8): Target path resolution complete. Dumping Directory table...
MSI (c) (D0:E8): Note: target paths subject to change (via custom actions or
browsing)
MSI (c) (D0:E8): Dir (target): Key: TARGETDIR , Object: C:\Program Files
(x86)\My XP Test Project Name\
MSI (c) (D0:E8): Dir (target): Key: NEWPROPERTY1 , Object: C:\Program Files
(x86)\My XP Test Project Name\
MSI (c) (D0:E8): Dir (target): Key: _7EB399BF505A4EF2AEE1A21C8E2FE12E ,
Object: C:\Program Files (x86)\My XP Test Project Name\My XP Test Project
Name\
MSI (c) (D0:E8): Dir (target): Key: DesktopFolder , Object: C:\Documents and
Settings\Administrator\Desktop\
MSI (c) (D0:E8): Dir (target): Key: ProgramMenuFolder , Object: C:\Documents
and Settings\Administrator\Start Menu\Programs\
MSI (c) (D0:E8): Dir (target): Key: _804A20C83F0C4BDE9FE8B5C4A56E093D ,
Object: C:\Program Files (x86)\My XP Test Project Name\myfolder1\
MSI (c) (D0:E8): Dir (target): Key: _3DDB9CF7E47F483FADF889A709FC6329 ,
Object: C:\Program Files (x86)\My XP Test Project Name\myfolder2\
MSI (c) (D0:E8): Note: 1: 2262 2: RemoveFile 3: -2147287038
Action ended 21:14:18: CostFinalize. Return value 1.
...
Property(C): TARGETDIR = C:\Program Files (x86)\My XP Test Project Name\
Property(C): _3DDB9CF7E47F483FADF889A709FC6329 = C:\Program Files (x86)\My
XP Test Project Name\myfolder2\
Property(C): _804A20C83F0C4BDE9FE8B5C4A56E093D = C:\Program Files (x86)\My
XP Test Project Name\myfolder1\
...
Property(C): Page Count Summary = 200
Property(C): Template Summary = Intel64
Property(C): Intel64 = 7
...
Property(C): VersionDatabase = 200
Property(C): VersionMsi = 2.00
Property(C): VersionNT64 = 502
...
Property(C): ProgramFilesFolder = C:\Program Files (x86)\
Property(C): CommonFilesFolder = C:\Program Files (x86)\Common Files\
Property(C): ProgramFiles64Folder = C:\Program Files\
Phil Wilson
ProgramFiles (x86). That's what I think I saw when we installed standard 32 bit MSI setups on a
64-bit system. That's an installer proprty, shouldn't really be affected by the tool used to build
it.
--
Phil Wilson [MVP Windows Installer]
"David" <NOS...@NOSPAM.COM> wrote in message news:s72qa.13023$DX.6...@twister.austin.rr.com...
David
ProgramFiles64Folder is "Program Files" in Win64.
The installer debug path shows it starting in "C:\Program Files."
Maybe the installer thinks it's a 32-bit program and that's why it converts
the path to C:\Program Files (x86)?
I didn't see "WIN64DUALFOLDERS" documented anywhere in the
msdn or google.
> MSI (c) (D0:E8): WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will
substitute
> 17 characters in 'C:\Program Files\My XP Test Project Name\' folder path.
Oh well, installing to the (x86) folder may confuse people but doesn't
have a functional effect.
"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:urogFw0C...@TK2MSFTNGP12.phx.gbl...
> I thought the value of the ProgramFilesFolder property on a 64-bit system
was supposed to be
> ProgramFiles (x86). That's what I think I saw when we installed standard
32 bit MSI setups on a
> 64-bit system. That's an installer proprty, shouldn't really be affected
by the tool used to build
> it.
> --
> Phil Wilson [MVP Windows Installer]
>
> "David" <NOS...@NOSPAM.COM> wrote in message
news:s72qa.13023$DX.6...@twister.austin.rr.com...
Eric Youngdale
Some of these things fall out automatically when you attempt the
validation feature with Orca. I had started by marking the 64-bit
executable components as 64-bit. I was getting validation errors because
the components weren't being installed in directories derived from
ProgramFiles64Folder. The ProgramFiles64Folder is just another entry in the
directory table, so if it isn't present you can simply add it by cloning the
entry for ProgramFilesFolder. The directory table entry by that name does
have 'special' significance, however, and for 64-bit install packages it
seems to be required. If you have no other way of running the validation
suite, Orca can do this for you.
The other thing I ran across was that I needed to set the platform to
Intel64 in the transform summaries property. The quick and dirty way of
changing this is to use Orca, but it would be tiresome to have to do this
each time you build the msi file.
The point about the registry is a good one. Many parts of the registry
are virtualized so that a 32-bit app and a 64-bit app don't see the same
thing. HKLM\Software is one of these. This is probably good - how else
could you have a COM component that is only 64-bit but has no dll for 32-bit
apps. It is possible to create symbolic links in the registry if you would
like the registry settings to be the same for both the 32-bit and 64-bit
applications within your product (which of course assumes that this would be
technically correct for your product).
-Eric
"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:uCGLqVo...@TK2MSFTNGP11.phx.gbl...
David
I finally discovered why the .MSI file kept installing my 64-bit
app to "Program Files (x86)" instead of "Program Files."
Orca's validation tool (which I didn't know until Eric
mentioned it), kept reporting that the template summary
was wrong (ICE80). The Template Summary property is not
set in Orca under the Property field. (That would be far too
easy!) Instead, and this is not documented in the MSDN,
it is set under View, Summary in Orca. The MSDN just says to
set the value, but never says how. A search on Intel64
or "Template Summary" should take one to a page
that documents how to set that value.
OK, knowing how to do it, I see that the MSDN says it can be done
with msiinfo. Even here, it says it can be done, but does it say how?
No.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/a
dding_summary_information.asp
Is there a way in VS.NET to set the template property (e.g.. to Intel64)
so I don't have to use Orca to edit the MSI after using VS.NET?
"Eric Youngdale" <er...@NaOnSdPaAnMte.org> wrote in message
news:#ZAoHZRD...@TK2MSFTNGP12.phx.gbl...
> A few things I can add based upon what I have recently learned.
>
> The other thing I ran across was that I needed to set the platform to
> Intel64 in the transform summaries property. The quick and dirty way of
> changing this is to use Orca, but it would be tiresome to have to do this
> each time you build the msi file.
>
> -Eric
>
> "Phil Wilson" <phil....@unisys.spamcom> wrote in message
> news:uCGLqVo...@TK2MSFTNGP11.phx.gbl...
> > The installer property that points to the 64-bit program files folder is
> ProgramFiles64Folder.
> > There's a bit more than that if you've got 64-bit apps though, because
> you'll need to mark the
> > installer components as 64-bit, and maybe worry about the registry too.
> >
> >
> >
> > "David" <NOS...@NOSPAM.COM> wrote in message
> news:HeKpa.3963$ac.3...@twister.austin.rr.com...
> > > How does one specify in an MSI file that a native 64-bit application
> should
> > > be installed to "Program Files" and not "Program Files (x86)" when
> installed
> > > to Win64 (64-bit Itanium Windows 2003)? I am currently using Visual
> Studio
> > > Installer 1.1 and Orca in a Win32 development environment.
> > >
Eric Youngdale
mainly used so that things like the explorer can get info about the package
without having to open it up. Many of the fields that are being used are
obviously originally intended for some other purpose (page count, word
count, etc).
You can of course write a simple application that calls
MsiSummarySetProperty().
I believe that with msiinfo, you can do:
msiinfo foo.msi -P Intel64;1033
-Eric
"David" <NOS...@NOSPAM.COM> wrote in message
news:8Ojra.31134$ac.16...@twister.austin.rr.com...
David
project in VSI.NET.
Thanks,
David
"Eric Youngdale" <er...@NaOnSdPaAnMte.org> wrote in message
news:OFoMCCxD...@TK2MSFTNGP11.phx.gbl...