You are installing a .NET assembly into GAC, but you are telling the COM+ CA's
that it's a native module.
Try replacing:
With:
And see if that works.
The problem with COM+ is that the DLL needs to be loaded in order to be
registered, and anything that goes into GAC is not vi
And you have double checked that the CLSID's you are providing for your
elements are the same provided in you .idl file? You
actually only have a single component in each module?
Other than that I wonder if there could be anything about your modules being
OCX'es but I doubt it. As far as I can
The default value for TARGETDIR [1] is C:\ but tools like VS.NET setup and
deployment projects add a type 51 CA (set property from formatted text) to set
TARGETDIR to [ProgramFilesFolder][Manufacturer]\[ProductName]. Also TARGETDIR
can be specified on the command line to specify where you want
>
> DEÁK JAHN, Gábor wrote:
> > Anyway, it's not a WiX limitation but a Windows Installer limitation,
> so until WI can call a managed DLL, there is nothing WiX can do about
> it. Much the same way as with Unicode. We're here starting to run on
> the fourth Windows platform with full Unicode suppo
You might read through this blog series of mine on my old blog:
http://blogs.msdn.com/robmen/archive/2006/10/12/deciphering-the-msi-directory-table-part-6-standard-directories.aspx
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser
Sent: Satu
Note exactly accurate. ROOTDRIVE is defaulted to the drive with the most free
space on the machine (unless you're doing an admin image... then it's something
like the first writeable network drive).
As you noted, TARGETDIR is defaulted to ROOTDRIVE.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROT
> The situation is clearly broken and it's up to Microsoft to fix it.
>
> John Vottero
So, John, why don't you go complain to Microsoft and more specifically the
Windows Installer team? I know there are a number of us on the mailing list
that work for Microsoft and we really do try to help wher
> > The situation is clearly broken and it's up to Microsoft to fix it.
> >
> > John Vottero
>
> So, John, why don't you go complain to Microsoft and more specifically
> the Windows Installer team? I know there are a number of us on the
> mailing list that work for Microsoft and we really do try
John Vottero wrote:
The System.Configuration.Installer base class has virtual methods for Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can support Rollbacks?
Yes, they *can*. The number that do is vanishingly small. Doing it right
is hard, regardless of language. H
Why not the Windows Installer team blog?
http://blogs.msdn.com/windows_installer_team.
-Original Message-
From: John Vottero [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 24, 2007 10:35 AM
To: Rob Mensching; Bob Arnson; [EMAIL PROTECTED]
Cc: WiX-users
Subject: RE: [WiX-users] C# .dll
Bob Arnson wrote:
John Vottero wrote:
The System.Configuration.Installer base class has virtual methods for
Install, Uninstall, Commit and Rollback. Doesn't that mean that that it
can support Rollbacks?
Yes, they can. The number that do is vanishingly small. Doing it right
is hard, r
This is really more of a Windows Installer question than a WiX questions
but, I'm not getting any responses in the msi newsgroup.
The component rules make it pretty clear that you can't add or remove a
"registry key" without creating a new component. Do they really mean
"registry key"? Can I add
John Vottero wrote:
I agree that writing a good CA is hard but, I'll bet it's easier in C#
than it is in C.
The guts -- whatever the CA actually needs to do -- can be. But that's
unlikely to encourage table-driven, state-driven CAs.
I also agree that eliminating a CA is the best way to
John Vottero wrote:
> The component rules make it pretty clear that you can't add or remove a
> "registry key" without creating a new component. Do they really mean
> "registry key"? Can I add or remove registry *entries* without breaking
> the component rules?
>
From the MSI perspective, re
IMO, it is very easy to blame it on Windows Installer team without actually
knowing/considering the work and requests they get from so many different
teams within Microsoft, let alone third parties and without
considering/knowing the limitations they face in implementing features (be
it business or
What I don't understand is why people are so eager to build managed custom
actions in the first place. I don't know for sure, but I don't think there are
quite as many threads over at the device driver lists about managed device
drivers... The only reason to use managed code from inside a custom
On Sat, 24 Mar 2007 20:38:16 +, Fredrik Grohn wrote:
First to all, please, clear out all the participants from the To: and CC: lines
and keep the discussion on the list itself. I guess we all monitor it regularly
so it's really not beneficial to receive every posting twice, both directly and
>
> On Sat, 24 Mar 2007 20:38:16 +, Fredrik Grohn wrote:
>
> First to all, please, clear out all the participants from the To: and
> CC: lines and keep the discussion on the list itself. I guess we all
> monitor it regularly so it's really not beneficial to receive every
> posting twice, both
That is why I said "without knowing/considering" J
As far as why people need it, it probably make things easier for people
using managed code in their product. Since I don't use managed custom
actions, I cannot justify it, but I think there are a lot of people out
there who would benefit from
Do you mean the "Name" of the Registry element? If so, no you can't remove
those either. The "full path" for a registry key is "Root\Key\Name". The only
thing you can do is change the value.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero
The main reason being individuals like me (newer developers) who more or
less started programming in C#; that was primarily the reason why I started
this thread anyway. Folks like Phil Wilson proposed the idea of learning
C++, and that had a meaningful end.
But more or less, more and more people
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/
22 matches
Mail list logo
