plication is a beast, and the installer has to tame it. What a
project At least I have a nice view of downtown Portland at night from
the 11th floor of this building.
Thanks,
Troy
On Tue, Sep 30, 2008 at 8:10 PM, Richard <[EMAIL PROTECTED]> wrote:
>
> In article <[EMAIL PROTECTE
I appreciate the feedback. In the short term, I've added the SelfRegCost
attribute to the file tags for the non-.Net COM DLLs, and that seems to work
fine.
As for the DLLs themselves, I have no idea what langauge they were written
in. We're using them within a legacy VB6 app, and wiring in new
fun
Regarding SelfReg, or not I'm not completely sure I drink the Kool-Aid
on this one. So, I understand that SelfRegCost violates transactability
rules (spell checker says transactability is not a word >shrug<) due to MSI
and how it handles that... But what then IS the recommended way to deal wit
ntown Portland at night from
> the 11th floor of this building.
>
> Thanks,
> Troy
>
>
>
> On Tue, Sep 30, 2008 at 8:10 PM, Richard <[EMAIL PROTECTED]> wrote:
>
>>
>> In article <[EMAIL PROTECTED]>,
>>"Troy Howard" <[EMAIL PROT
. I've tried everything I can think of, and
everything I've heard suggested on the 'net.. Is it always this complicated
to register .Net COM DLLs? Did I miss the easy route somehow?
Thanks,
Troy
On Mon, Sep 29, 2008 at 9:29 PM, Troy Howard <[EMAIL PROTECTED]> wrote:
> I
I read a message on here a while back where someone had written an XSL to
fixup the "primary key is duplicated" errors caused by nested registry value
elements like this example:
The XSL would convert these to single line
Hi Jim,
Did you ever figure this out?
I'm in basically the same situation. I have a VB6 application that uss
numerous third party COM DLLs, and some in-house .Net COM DLLs. I've
included all the appropriate bits of WiX code (AFAICT), but the registration
doesn't seem to be effective. Running regs
Well, if you're looking for a simple programming task that will solve your
problem, how about just writing a small command-line app in vb.net that
fixes up the XML that heat generates? That would probably be much more
simple than trying to extend heat..
On Fri, Sep 12, 2008 at 10:31 AM, BOB1981 <
because I think the order
> is what's been messing me up).
>
> 1. Connect to Server B (sql server) using sysadmin (sa user) from Server B.
> 2. Create new database on Server B using user sysadmin from above.
> 3. Grant login rights and dbo role on new databases to the origin
Seems like the workflow is:
1. Connect to Server B (sql server) using an existing sql login (not
windows), that has less than admin level rights (configured where? created
when?).
2. Somehow obtain different credentials from Server B that have
administrative rights on Server B.
3. Connect with new
Well, the value is a pre-processor variable. It doesn't exist outside of VS
(or a commandline MSBuild environment). So, when you build it in Wixedit, it
doesn't have that variable set.
Specifically, this variable is referring to the filename of a
dll/exe/msm/etc from a visual studio project called
b Arnson <[EMAIL PROTECTED]> wrote:
> Troy Howard wrote:
> > Also, since I imagine this will annoy a lot of people, is there any
> reason
> > why it's different in the first place?
>
> When I created WixUI, I started with the MSI SDK samples, not with the
> .vdpr
First, thanks all for helping put me on the right track with merge modules
in my last message. I figured that out and it's exactly what I needed.
My current question revolves around the stock ui in WixUIExtensions.dll and
the image sizes.
Our company currently has a number of installers that were
All,
First -- I'm new to the list, so, nice to meet you.
My question, in a nutshell, is what is the best way to go about dealing with
this situation I have? The situation its, that I've got a bunch of tools
which are related to each other as part of a software platform. They are all
various utili
14 matches
Mail list logo
