VSTOR is a separate component from the .Net FW. VSTOR 4.0 is dependant on CLR
4.0, but they are not the same package. You would have to have a separate
prereq for those components.
From: rahul.ekb...@sungard.com [rahul.ekb...@sungard.com]
Sent:
be future proof.
Thanks for the suggestions so far.
2010/9/13 Bryan Reich bryan.re...@microsoft.com
https://sourceforge.net/tracker/?func=detailaid=2927773group_id=105970atid=642714
You may have to upgrade to newer bits or break out the second progId into
its constituant registry keys outside
Can you give examples of the specific keys you are attempting to write? Vista
and Win7 created the concept of protected registry nodes that are owned by
Windows and they don't let others mess with them, but for back compat they
swallow the related errors so it only causes silent failures. That
client to give me the list of all hot fixes and I am
going to try one by one. If I found exact hotfix, I will let you know.
Thanks,
Rahul
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Thursday, June 03, 2010 9:12 PM
To: General discussion for Windows Installer
problem, it is disappearing
menu add-in from excel menu bar.
To resolve this I added kb980210 but it not working. So currently I am
struggling to bring the add-in menu on menu bar.
Thanks,
Rahul
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Wednesday, June
and
reference that. It can be a bit confusing if you don't understand how
advertised installations work :)
Hope that helps.
Cheers,
Sascha
On Wed, Jun 2, 2010 at 7:19 AM, Bryan Reich bryan.re...@microsoft.com wrote:
Windows installer caches entries in the Icon table in the installer cache
statement is not available, please read our privacy
statement offline:
C:\Windows\system32\en-US\erofflps.txt
Upto this point we don't have any COM add-in.
If I follow the same steps on XP it works perfectly.
Thanks,
Rahul
From: Bryan Reich [mailto:bryan.re
\EnableLocalMachineVST
O = 1. Option
Why the .vsto (Clickone deployment) not asks me the target dir? It
directly installs in appdata\user\...
Thanks,
Rahul
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Friday, May 28, 2010 2:26 PM
To: General discussion
registry changes suggested in
http://support.microsoft.com/kb/976811/.
Thanks,
Rahul
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Tuesday, June 01, 2010 4:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VSTO excel Add
Windows installer caches entries in the Icon table in the installer cache
location as you see below, so in effect by creating that Icon WIX element, you
think of it as if it were a separate File element from your root exe. In the
past, when I've authored COM registration and tried to do what
A summary of the different behaviors depending on where you schedule
RemoveExistingProducts, and benefits and drawbacks of each in general, can be
found at:
http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx
--
Bryan
-Original Message-
From: Stefan Kuhr
, June 01, 2010 3:03 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] VSTO excel Add in for all users
Ok Thanks. I will wait for your reply.
Thanks,
Rahul
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Tuesday, June 01, 2010 1:25 PM
Which version of Office are you targeting?
If it is Office 2003, it won't work.
If it is Office 2007, HKLM VSTO add-ins were not supported when RTM shipped but
were enabled later via an update (KB976477). Even if you have the update you
have to explicitly enable HKLM registered VSTO add-ins by
This is likely a classic component violation. The component GUID has been
revved but the version independent progID remains the same registry key for the
two components, meaning the uninstall of any one of the components will remove
the key out from underneath the other product since two
In our product, we maintain the component violation and we instruct our users
in such a scenario to run repair on the remaining version if you uninstall from
a side-by-side state. A custom action would also potentially work as you
suggest Kim, if the scenario is important enough to warrant the
My advice would be to use the 32 bit install location, but if you really want
to put it in the 64 bit location, you can author two components, one for the
server and one for the class associated with the server. The server can be
marked as 64 bit. The class component marked as x86. Mark the
It is trying to use the directory as a fallback for your keypath. What you
probably want in this component is for one of the registry keys to be the key
path, then it won't try to use the directory for that.
Something like the following perhaps:
Component Id=foo Guid=MyGUID Directory=NotUsed
Do you know what component(s) install the file in question? If so using
ComponentSearch would likely be a better approach.
--
Bryan
-Original Message-
From: Dane Anderson (Acro Service Corp) [mailto:a-daa...@microsoft.com]
Sent: Thursday, February 18, 2010 2:12 PM
To:
Don't shoot the messanger John. I'm just passing along what I know about the
current situation. Also note that with the 4.0 FW, the CLR changed the way is
registers itself and where you have to look in the registry to determine the
current version, which is why the preexisting detection logic
There is no guarantee that your product would work just fine with CLR 4.0 just
because it works with CLR 2.0 (Framework 3.5).
For CLR 4.0 the CLR has moved into a SxS model whereby 4.0 can be loaded
in-proc SxS 2.0 runtime, and the 5.0 runtime will be loaded into process
alongside the 4.0
I was under the impression that the expression
$(var.MyVar)
a preprocessor evaluation, evaluated at a similar time to ?if ?.
However, some wix that I am compiling suggests this isn't the case.
I'm trying to define a variable as follows:
?if someCondition ?
?define
To help avoid duplication you can also use include files (*.wxi) to define the
registry keys and include it in each component as described below without
having to duplicate the code.
Component Id=C_Registry_x86 Guid=PUT-GUID-HERE
Directory=INSTALLLOCATION Win64=no
?include
Note I don't know if this is your scenario or not, but if you are installing
architecture neutral components like .Net assemblies, and are installing them
into the same location regardless of your package architecture (such as the
GAC), then you should make a single Win64=no component and
work either.
How does one find out what username was assigned to them in the initial
registration process? (I did my registration entirely via the email mechanism).
--
Bryan Reich
--
This SF.Net email is sponsored
Bug 2927773 has been opened to track. Thanks.
-Original Message-
From: Bryan Reich [mailto:bryan.re...@microsoft.com]
Sent: Wednesday, January 06, 2010 10:12 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix bug when converting class/progID set
We did this in one case by using a Condition as follows:
Condition Message=your error messageACTION~lt;gt;ADMIN/Condition
I know that works for advertise. I think there can be similar logic for repair.
--
Bryan
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent:
I am seeing the following:
Previously there was:
Class Id={myGUID} advertise=yes...
ProgId Id=MyProgid1.14 Advertise=yes ... /
ProgId Id=MyOtherProgId.14 Advertise=yes .../
/Class
This was working fine. When installed, the class had entries for the prog ID
that was first in the list of
toolset.
Cc: Bryan Reich
Subject: Re: [WiX-users] Wix bug when converting class/progID set from
advertised=yes to advertised=no?
On 1/6/2010 7:42 PM, Bryan Reich wrote:
What is happening is that WIX, while turning these ProgIds into their
constituent registry keys, does NOT use the heuristic
level deep.)
And unfortunately I need to do the latter because a number of the same-class
associated progIds also have versions and version-independent entries.
--
Bryan
-Original Message-
From: Bryan Reich
Sent: Wednesday, January 06, 2010 7:41 PM
To: 'Bob Arnson'; General discussion
YesNoType.Yes
== firstProgIdForClass.
Do you mind filing a bug?
The work around in WiX v3.0, unfortunately, is to pull the second ProgId out
and set its registry keys using RegistryKey/RegistryValue elements.
On Wed, Jan 6, 2010 at 8:37 PM, Bryan Reich bryan.re...@microsoft.comwrote:
I can confirm
30 matches
Mail list logo
