Hello Rob,
Thanks for the reply.
We have our Wix project in the same solution as the application and just
create the msi when the solution is built by Visual Studio. We are not doing
anything in Wix with the command line, everything is done via Visual Studio.
I do not think it is possible to s
Hello raj,
Thanks for your response. We are just beginning to use Wix and do everything
within Visual Studio. Our wix project is included within the application
solution, so the msi is created when the solution is built.
Can the code you were kind enough to share be used or adapted within the
Vis
Util RegistrySearch has an attribute Winb64 that seems to be no by default.
If this is set to Yes, Would it mean it would look in the 32bit registry
on 32bit OS and 64bit registry on 64bit OS ?
The reason I am seeking some clarification is become some other attributes
like these seem to be have d
Hi
I just tried this simple project. Basically I just manually edited the
wixproj and simply added OutputName override in the debug configuration.
Now when I open this project and build the debug configuration the output
is simplemsidebug.msi and in release the output is simplemsi.msi
-Raj
htt
The Win64 attribute defaults to 'yes' or 'no' based on the value you pass
to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. If it
is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a 32-bit
machine (because there is no 64-bit).
Bootstrapper is completely separate and
Yeah, changing the TargetName should just be a matter of editing the
.wixproj to include another MSBuild property. This is really about MSBuild
though functionality, not the WiX toolset.
On Fri, Apr 5, 2013 at 4:54 AM, j2associates wrote:
> Hello Rob,
>
> Thanks for the reply.
>
> We have our W
Thanks Rob.. I just wanted to clarify it because the documentation seems
out of date.
*RegistrySearch documentation says*
Instructs the search to look in the 64-bit registry when the value is
'yes'. When the value is 'no', the search looks in the 32-bit registry. The
default value depends on the
Sorry, my bad. I didn't realize you were talking about the
util:RegistrySearch. My answer was about the MSI based RegistrySearch.
Using util:RegistrySearch is explicit. If you say Win64='yes' then the
search is 64-bit and vice versa. You can ignore the fact that the Burn
engine is 32-bit. It matter
But what you said about
if I set Win64='yes'
It will do 64bit search on 64bit OS
and on 32bit OS it will do 32bit search and not fail.
is still true for Util:RegistrySearch like it is for MSI RegistrySearch
I suppose I could test this out myself but I just wanted to know if this is
documented be
I think that's reasonable. If you could test it out and file a bug saying,
"This is what I discovered, it would be ideal if the documentation defined
the expected behavior for util:RegistrySearch Win64." I'll get the right
thing to happen on the other side.
On Fri, Apr 5, 2013 at 7:40 AM, ptr w
Also note that unless you change the default behavior, then
'$(TargetName)' == '$(OutputName)'
So, I would change the OutputName property to whatever name you need.
--
Edwin
On Fri, Apr 5, 2013 at 5:54 AM, Rob Mensching wrote:
> Yeah, changing the TargetName should just be a matter of editi
Right, my bad. OutputName over TargetName not the other way around.
On Fri, Apr 5, 2013 at 8:07 AM, Edwin Castro wrote:
> Also note that unless you change the default behavior, then
>
> '$(TargetName)' == '$(OutputName)'
>
> So, I would change the OutputName property to whatever name you need.
hey all
I have a computer on which a msi installs and uninstall correctly. But
when done through the bootstrapper it complains that a higher version is
already installed.
The only thing is the bootstrapper is marked as version 4.1.95.8879 and the
msi is marked as version 4.1.8421. I am not sure
Please ignore this email. I somehow cut pasted the same upgrade code to two
different msi's in the bootstrapper
Thanks
Raj
On Fri, Apr 5, 2013 at 5:29 PM, ptr wrote:
> hey all
>
> I have a computer on which a msi installs and uninstall correctly. But
> when done through the bootstrapper it co
Hi Christian,
I have run into exactly the same situation (the patching successfully
completed, but the ARP entry not being updated). Did you ever find a
solution to the problem?
Best regards,
Mattias
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.co
15 matches
Mail list logo