[WiX-users] Merge existing MSIs into a single MSI as features

[Troy Howard]

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 utilities, and each one currently has it's own MSI installer. I want
to package a bunch of them up into a single MSI with each install as a
feature in that MSI.

The overall goal is to be able to flexibly deploy the tools in various
groups. The first step is to make one big installer with lots of features,
then in the future make various packages with certain subsets of the tools.

Each tool will be independently updated, and versioned, sometimes needing to
be installed individually, sometimes as part of a package. When installed as
a package, they may need to be updated individually, as part of that
package...

So, that's the problem... If I were starting fresh, writing it from the
ground up in WiX, I know enough about it to include each program's install
as it's own feature, and put it all together in the a big package. I think I
understand enough about fragments that I could keep each "highest level"
fragment (ie, each top level feature/seperate program install), in it's own
fragement file, then have one wxs file that has a the big package, and a wxs
file for each seperate package, then build them all at the same time...

That doesnt' quite seem like what I want to do though.

I'm not completely clear on merge modules and how those work, but I imagine
that's what I want to do here. Would I want to compile each current
installer to a MSP, instead of an MSI, then some how link each MSP in as a
feature in a big package? Can that be done? If so, how do I convert the MSI
to a MSP without completely decompiling it with dark? Would I be better
served to just re-create the installs in WiX (the MSIs were made with either
.Net Setup projects or an old version of InstallShield) as merge module
projects, generating the MSPs up-front? What would a package that used MSPs
as features look like?

Sorry if my message is lengthy and showing my obvious lack of experience
with this matter. I promise to pay attention and learn from your responses,
so that I can get back to work cleaning up our company's installer mess,
instead of sending lengthy emails to mailing-lists.

Thanks,
Troy
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WixUI Banner image sizes

[Troy Howard]

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 built with .Net
Setup Projects. Those installers all use a standard banner bitmap that is
497 x 69 pixels. The WixUI standard banner is 493 x 58. In the WixUI source
code, the dialog banner sizes in the control tags are set to 370 x44, but in
the .Net Setup projects (inspecting with Orca) they are 375 x 52.

I would prefer to be able to continue generating MSIs in .Net Setup Projects
when needed, but also use Wix.

As it see it, I'm left with two options:
1. Maintain two sets of graphics, with slightly different sizes, to be used
in their respective dialogs (ie, keep a banner graphic at 497x69 for .Net
Setup Projects, and another at 493x58 for Wix projects)
2. Download the source for WixUIExtensions.dll, edit all the dialogs to
match the .net setup project sizes, recompile, and reference this customized
dll in all my wix projects.

I prefer not to have to maintain seperate graphics, because, to put it
simply, it will get confusing, and create double the work for the guy who is
generating the graphics (sometimes me, sometimes our in-house designer). I
imagine that even if we were diligent about creating seperately sized ones,
that the developers creating the MSIs might forget which one to use, ending
up with streched or crunched banners anyway... They of course won't notice,
but anyone else in the world would. I will have to be the
setup-banner-graphics-size police from now until the distant future.. etc..

I lean heavily towards the one graphic size for all dialogs option (option
2)...

So, my question is this... Since I'm probably not the only person who has
ever encountered this problem.. Has anyone else done the work already to
modify all the sizes in WixUI to match the .Net Setup projects? If so, would
it be possible for me to get the custom WixUIExtension.dll?

Also, since I imagine this will annoy a lot of people, is there any reason
why it's different in the first place? Is there any interest in updating the
"official" codebase to use the (unchangeable) standard set by the .Net Setup
projects?

Thanks,
Troy
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixUI Banner image sizes

[Troy Howard]

> Unfortunately, that would break the graphics that users already created.

That makes perfect sense.

Perhaps once I finish making a size compatible version of the current UI,
I'll make it available to anyone else who faces this issue.

Thanks,
Troy


On Fri, Sep 5, 2008 at 8:50 AM, Bob 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
> .vdproj UI.
>
> > Is there any interest in updating the
> > "official" codebase to use the (unchangeable) standard set by the .Net
> Setup
> > projects?
> >
>
> Unfortunately, that would break the graphics that users already created.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] custom ui sample question

[Troy Howard]

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 "MyProject". So, to make
it work in Wixedit, just replace it with the correct filename. For example,
"MyProject.exe", "MyProject.dll", ... etc.


Hope that helps,
Troy


On Sat, Sep 6, 2008 at 4:22 PM, P a u l <[EMAIL PROTECTED]> wrote:

>
> I'm trying Wixedit and it won't build the project due to this error:
>
> error CNDL0150 : Undefined preprocessor variable
> '$(var.MyProject.TargetFileName)'.
>
> The project builds within vs2008 okay, but not in Wixedit (latest version).
> This must be some well known issue? Thanks for any help on this.
>
>
> --
> View this message in context:
> http://n2.nabble.com/custom-ui-sample-question-tp842093p950571.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re mote SQL Authentication

[Troy Howard]

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 credentials to Server B
4. Create/Attach new database to Server B.
5. Grant login rights and dbo role on new databases to the original set of
credentials.

The work flow is flawed though.. It's flawed, because the only way that it
could work would be if the initial lower access account was powerful enough
to gain admin access through the second account Then what is the point
of a second secure admin account in the first place? It's a major security
hole to attempt a solution that would work that way.


What you should do instead is...

1. Ask user to provide admin credentials and server name/instance for
"Server B" during install (or in a less user friendly context, ask for a
whole connection string).
2. Ask user to provide account information for a new login account to be
used by "Machine A". (username, password for sql login, or just
domain\account for windows auth)
3. Connect to Server B with provided existing admin account.
4. Create/Attach database.
5. Create new account for Machine A.
6. Grant login rights and dbo role on new database to the new account.

Does that make sense, or did I miss the point somewhere?

Hope that helps,
Troy




On Tue, Sep 9, 2008 at 2:38 PM, David Reed (SQL)
<[EMAIL PROTECTED]>wrote:

> If the identity running the installation doesn't have sysadmin privileges,
> you're not going to be able to grant anything to yourself... Maybe I'm not
> understanding the workflow that you're trying to achieve. We can take it
> offline if you like.
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of cemiles
> Sent: Tuesday, September 09, 2008 13:32
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Re mote SQL Authentication
>
>
> If anyone has come across this let me know.  I can post my code if so,
> hopefully for a little advice because I'm between a rock and a hard-place.
>
> I need to run my install on a machine (Server A), and need to use sql
> authentication to grab a user w/ sysadmin rights on the remote machine
> (Server B), then use that to create the DB on Server B.  Then on Server B
> I'm trying to grantlogin to the user I'm running the install under on
> Server
> A and change the dbo after that.
>
> I'm pretty much stuck and have tried so many scenarios and after a bunch of
> reading still no solution.  I think the problem resides in my sqlstring
> element.
>
> Any helpers out there?
> --
> View this message in context:
> http://n2.nabble.com/Remote-SQL-Authentication-tp1078503p1078503.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re mote SQL Authentication

[Troy Howard]

Yes, if your end goal is just to install the database and give the user
that's running the installation ownership to it and login rights, then those
three steps would do it (though you're missing the "user enters sa account
credentials, and server/instance name in custom installer dialog"... You of
course, don't want to hardcode them into the installer. ;)

If you make them properties they can be set from the command line for
automated installs.

Thanks,
Troy


On Tue, Sep 9, 2008 at 3:59 PM, cemiles <[EMAIL PROTECTED]> wrote:

>
> I think you're right on the money Troy, and I'll try what you're suggesting
> and spend some time because that sounds like a very good idea.  I'd like to
> try and simplify the steps you outline down to what I've mentioned below...
> if that sounds plausible to you guys (I'm asking, 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 original set of
> credentials from machine A (the user running the install).
>
>
>
> Troy Howard wrote:
> >
> > 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 credentials to Server B
> > 4. Create/Attach new database to Server B.
> > 5. Grant login rights and dbo role on new databases to the original set
> of
> > credentials.
> >
> > The work flow is flawed though.. It's flawed, because the only way that
> it
> > could work would be if the initial lower access account was powerful
> > enough
> > to gain admin access through the second account Then what is the
> point
> > of a second secure admin account in the first place? It's a major
> security
> > hole to attempt a solution that would work that way.
> >
> >
> > What you should do instead is...
> >
> > 1. Ask user to provide admin credentials and server name/instance for
> > "Server B" during install (or in a less user friendly context, ask for a
> > whole connection string).
> > 2. Ask user to provide account information for a new login account to be
> > used by "Machine A". (username, password for sql login, or just
> > domain\account for windows auth)
> > 3. Connect to Server B with provided existing admin account.
> > 4. Create/Attach database.
> > 5. Create new account for Machine A.
> > 6. Grant login rights and dbo role on new database to the new account.
> >
> > Does that make sense, or did I miss the point somewhere?
> >
> > Hope that helps,
> > Troy
> >
> >
> >
> >
> > On Tue, Sep 9, 2008 at 2:38 PM, David Reed (SQL)
> > <[EMAIL PROTECTED]>wrote:
> >
> >> If the identity running the installation doesn't have sysadmin
> >> privileges,
> >> you're not going to be able to grant anything to yourself... Maybe I'm
> >> not
> >> understanding the workflow that you're trying to achieve. We can take it
> >> offline if you like.
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:
> >> [EMAIL PROTECTED] On Behalf Of cemiles
> >> Sent: Tuesday, September 09, 2008 13:32
> >> To: wix-users@lists.sourceforge.net
> >> Subject: [WiX-users] Re mote SQL Authentication
> >>
> >>
> >> If anyone has come across this let me know.  I can post my code if so,
> >> hopefully for a little advice because I'm between a rock and a
> >> hard-place.
> >>
> >> I need to run my install on a machine (Server A), and need to use sql
> >> authentication to grab a user w/ sysadmin rights on the remote machine
> >> (Server B), then use that to create the DB on Server B.  Then on Server
> B
> >> I'm trying to grantlogin to the user I'm running the install under on
> >> Server
> >> A and change the dbo after that.
> >>
> >> I'm pretty much stuck and have tried so many scenarios and after a bunch
> >> of
> >> reading still no solution.  I think the problem resides in my sqlstring
> >> element.
> >>
> >> Any helpe

Re: [WiX-users] Creating using Heat.

[Troy Howard]

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 <[EMAIL PROTECTED]>wrote:

>
> Hi,
>
> i am not a good programmer, can u pls let me know how can i do that i mean
> which language i can use to do that easily for me like:- java script,
> vbscript.
>
> I heard about XML DOM do you think that will be good option, basically
> which
> will be easy to learn and create this custom task i want my build to have.
>
> thanks
> waiting for responce.
>
>
> Rob Mensching-2 wrote:
> >
> > Heat isn't designed to run in a build process today.  You can see lots of
> > discussion about its deficiencies in the archives here.  You could write
> a
> > custom Mutator to extend heat to make it do what you want in this case...
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Creating--%3CComponentGroup-Id%3D%22ComponentGroup2%22%3E-using-Heat.-tp1083059p1085905.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

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 regsvr32 and regasm on the assemblies
after installer gets everything working though.

At this point, I'm thinking I'll have to run a batch file at the end of the
install to call regsvr32/regasm just to the the thing out the door on
schedule.

I'm in the process of migrating from an existing Installshield setup to WiX,
and we did it with a batch file in the IS installer. One of the big things
were were hoping to get out of WiX was to make this happen correctly,
instead of with a "duct tape" batch file.

Does anyone have an insight that I might be missing?

My basic process for getting the WiX code for this was to run heat again the
files, generating a wxs, then edit those wxs fragments to compile correctly.
This involved moving the class/progid/typelib/interface declarations inside
of the file tag, and removing extra registry keys that were in conflict with
those tags (IE. removing tags like
)... etc.


Thanks,
Troy



On Tue, Sep 2, 2008 at 3:05 PM, Evans, Jim <[EMAIL PROTECTED]>wrote:

> I know this isn't the exact forum for this, but I'm really confused and
> don't know where else to turn. I'm in the process of moving our
> installer to an msi-based install using WiX. Our application is fairly
> complex, including .NET assemblies, a client-side application, Windows
> services that run on a server, a web portal, and COM components on the
> server that the service and web portal use. It's these COM components
> that are giving me fits. I've created WiX install elements for the COM
> components (, , , , etc.), and as far
> as I can tell the COM registration is correct. All of the COM registry
> entries are getting created by the installer. However, my COM components
> cannot be used by their consumers after the installation.
>
>
>
> If I use regsvr32 to unregister and reregister the .dll, the COM
> components work properly. These are VB6 dlls in the main, but I don't
> think that has anything to do with it. I've watched what regsvr32 does
> using procmon, and it does look like it's registering my Interface
> information twice, but I can't see how that would affect things. I'm
> going to try a full registry comparison next, but I was wondering if
> anybody here has run into anything like this?
>
>
>
> --Jim Evans
>
> Numara Software, Inc.
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Anyone have XSL for fixing up nested registry values?

[Troy Howard]

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 RegistryValue tags.

Anyone have an XSL or script that does this fixup?

I'm trying not to reinvent the wheel.

Thanks,
Troy
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

So, in my efforts to resolve the .Net COM issues, I've tried out this
process:

1. Generate .reg files with regasm /regFile
2. Convert .reg files to .wxs using tallow (WiX2)
3. Fixup .wxs files using WixCop (WiX3).
4. Fixup those fixed-upped files removing the nested and duplicate registry
entries.
5. Rebuild...

Unfortunately, that's not working either.

After installation, the application that uses these DLLs just hangs when
attempting to call them. Before, when the registration was failing
completely, the application would error out with an "Cannot create ActiveX
object" type of error or "Automation error"... etc.. Now, it just silently
hangs without producing an error, but also without functioning... If I
register the DLLs on the target machine after that install using regasm
manually, everything works just fine.

I'm sort of at a loss on this one. 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 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
> functionality with .Net COM DLLs. The non-.Net stuff is all third party
> things that we've licensed, so I have no source code for that stuff. It's
> quite possible that somehting is happening outside of the norm with them
> guys, since none of them seem to be what I would call "high-quality software
> products".
>
> So, on the the .Net COM Interop registration... any idea why the basic
> output from heat wouldn't be doing the trick? What might it be missing?
> Should I just do a regasm /reg and then convert that to WiX code?
>
> Thanks,
> Troy
>
>
>
> On Mon, Sep 29, 2008 at 9:15 PM, Richard <[EMAIL PROTECTED]> wrote:
>
>>
>> In article <
>> [EMAIL PROTECTED]
>> >,
>> Rob Mensching <[EMAIL PROTECTED]>  writes:
>>
>> > If anyone does figure it out, it'd be good to understand what is going
>> on.
>> > I don't know VB (let alone VB6) and things work great for my C++/ATL
>> based
>> > COM objects.
>>
>> By the time its a COM object, VB6 or C++ it doesn't make any
>> difference.
>>
>> I would run RegMon and FileMon while you hand register the COM object
>> on a system where its never been registered before.  Then check to
>> make sure it isn't doing things inside its DllRegisterServer that its
>> not supposed to be doing (through filemon).  Its only supposed to be
>> setting registry values that deal with COM registration, but sometimes
>> people get lazy and do all sorts of crazy stuff in there.  I don't
>> know if VB6 lets you control that entry point or just does it for you
>> based on the kind of project you made.  At any rate, all that's
>> happening when you register the COM object with Windows Installer is
>> that its handling those registry entries for you.
>>
>> If you duplicate all of the registry entries, then it should work
>> fine.
>>
>> The key is going to be running some sort of utility that can tell you
>> how that component is interacting with the system when its
>> DllRegisterServer entry point is called.  Ultimately you could (ugh)
>> step through the assembly code as it executes to identify the missing
>> piece.
>> --
>> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>>  
>> <http://www.xmission.com/~legalize/book/download/index.html<http://www.xmission.com/%7Elegalize/book/download/index.html>
>> >
>>
>>Legalize Adulthood! <http://blogs.xmission.com/legalize/>
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

Ok, I found a process that works...

First, I had to explicitly add:

  
  
  
  
  
  
  


then for each .net com dll, i ran heat against it to generate a wxs.

I then fixedup those wxs files in the following manner:
1. Wrap the Class/ProgID/etc tags inside the File tag so that class/@server
gets set
2. Update the registry values that referred to mscoree.dll so that they each
have a unique id in the Id attribute.

That combination get me functioning .Net COM DLLs, and now that I fully
understand what's happening, it makes sense. The default sequence doesn't
include the com registration actions that read the class table/etc. So those
have to be added. The heat output doesn't nest the class tags in the file
tag, so server attribute doesn't know what it's target is. The registry
values for mscoree.dll are in conflict with the autogenerated ones made form
the class tag, because they both use autogenerated ids, which are a hash of
componentId, root, key, and name... And so they need to be differentiate by
assigning a unique id.

I'm quite relieved I got it worked out.

Thanks,
Troy



On Tue, Sep 30, 2008 at 9:51 PM, Troy Howard <[EMAIL PROTECTED]> wrote:

> It's both.
>
> The application is written in VB6. It uses COM DLLs written in various
> languages, including C++, VB6, and .NET. The installer needs to be able to
> register all of these things.
>
> The non-.Net COM DLLs seem to be doing alright with the SelfRegCost
> attribute applied, but now the .Net DLLs are having trouble. I've tried
> various ways to get them working.
>
> What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib
> actions. I opened the MSI up in ORCA, and realized that they are not in my
> InstallExecuteSequence table. That makes sense why it wasn't working with
> Class/Progid etc elements in the components. The action was never getting
> called that dealt with those things. I assumed those actions would be
> included, and that I didn't to explicitly add them. I'm going to give it a
> try with the "correct" methodology again, this time with the correct actions
> in the sequence and see if that does the trick. If so, I can get rid of the
> self registration stuff, AND the duct tape batch file full of regasm calls.
>
> Conveniently, re-ghosting the test box and building the installer take
> about the same amount of time.. >sigh<
>
> This application 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 PROTECTED]>,
>>"Troy Howard" <[EMAIL PROTECTED]>  writes:
>>
>> > So, in my efforts to resolve the .Net COM issues, [...]
>>
>> Earlier, this thread was talking about registering a VB6 control.
>>
>> Now you're talking about registering a .NET assembly for COM interop.
>>
>> So which is it?
>>
>> I've registered .NET assemblies for COM interop with no problems by
>> taking the output of /regfile.
>> --
>> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>>  
>> <http://www.xmission.com/~legalize/book/download/index.html<http://www.xmission.com/%7Elegalize/book/download/index.html>
>> >
>>
>>Legalize Adulthood! <http://blogs.xmission.com/legalize/>
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

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 with
the scenario where you have a COM DLL that you didn't write and can't get a
different version of that does some wacky stuff in DllRegisterServer...

How should those DLLs be handled? If we use SelfRegCost, everything works
after a successful install, but at a rollback, or uninstall, there's no way
to undo it. What if there were CAs for RegSvr32/RegAsm, that were built-in
and easy to use, and then you could make sure that was happening correctly,
at the right times? This is similar to the duct-tape batch file solution
(one batch for install, one for uninstall), or bunch of QtExec actions to
those programs with appropriate cmdline params. The main thing seems to be
that they are scheduled at the right time, so that uninstall calls regsvr32
/u.

I understand that modifying system state outside of MSI's system is  a
no-no,  but if you're stuck with a DLL that operates that way, so be it.

Regarding the situation that I just finished with, I would like to have a
deeper understanding of the term "Advertise" that is being used in WiX/MSI
contexts. What does this mean exactly, in relation to COM DLLs?

Rob M mentioned that: "... those actions are only necessary if you are using
the Advertised features of COM registration otherwise it's all just Registry
rows."

I read the blog post he linked to about why advertising is bad, but it lacks
a definition of what advertising is. Does that definition exist somewhere?
With context regarding COM?

Thanks,
Troy



On Thu, Oct 2, 2008 at 1:09 AM, John Hall
<[EMAIL PROTECTED]>wrote:

> Neil wrote:
> > I have tried a
> > few times to remove the unrelated code and never successfully
> > got the component to work or to leave the machine working on
> > uninstall. Have you ever generated the WiX registry code for
> > VB6 COM component? Has anyone?
>
> Neil,
>
> I have. I wrote a custom build task that extracts the registration
> information at build time [1].
>
> The registration entry point is called with some registry redirection in
> place, and then I harvest the created registry entries removing the
> following:
>
>  - CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
>
>  - Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
>   {000204EF---C000-0046}, plus any Interfaces that
>   reference these two type libraries.
>
> This works for me.
>
> regards,
> John
>
>
> [1] I know this is very much frowned upon, but I always create major
> upgrades and don't create patches... YMMV
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

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
functionality with .Net COM DLLs. The non-.Net stuff is all third party
things that we've licensed, so I have no source code for that stuff. It's
quite possible that somehting is happening outside of the norm with them
guys, since none of them seem to be what I would call "high-quality software
products".

So, on the the .Net COM Interop registration... any idea why the basic
output from heat wouldn't be doing the trick? What might it be missing?
Should I just do a regasm /reg and then convert that to WiX code?

Thanks,
Troy


On Mon, Sep 29, 2008 at 9:15 PM, Richard <[EMAIL PROTECTED]> wrote:

>
> In article <
> [EMAIL PROTECTED]
> >,
> Rob Mensching <[EMAIL PROTECTED]>  writes:
>
> > If anyone does figure it out, it'd be good to understand what is going
> on.
> > I don't know VB (let alone VB6) and things work great for my C++/ATL
> based
> > COM objects.
>
> By the time its a COM object, VB6 or C++ it doesn't make any
> difference.
>
> I would run RegMon and FileMon while you hand register the COM object
> on a system where its never been registered before.  Then check to
> make sure it isn't doing things inside its DllRegisterServer that its
> not supposed to be doing (through filemon).  Its only supposed to be
> setting registry values that deal with COM registration, but sometimes
> people get lazy and do all sorts of crazy stuff in there.  I don't
> know if VB6 lets you control that entry point or just does it for you
> based on the kind of project you made.  At any rate, all that's
> happening when you register the COM object with Windows Installer is
> that its handling those registry entries for you.
>
> If you duplicate all of the registry entries, then it should work
> fine.
>
> The key is going to be running some sort of utility that can tell you
> how that component is interacting with the system when its
> DllRegisterServer entry point is called.  Ultimately you could (ugh)
> step through the assembly code as it executes to identify the missing
> piece.
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>  
> 
> >
>
>Legalize Adulthood! 
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] COM registration weirdness

[Troy Howard]

It's both.

The application is written in VB6. It uses COM DLLs written in various
languages, including C++, VB6, and .NET. The installer needs to be able to
register all of these things.

The non-.Net COM DLLs seem to be doing alright with the SelfRegCost
attribute applied, but now the .Net DLLs are having trouble. I've tried
various ways to get them working.

What I'm currently looking at is the RegisterClassInfo/ProgID/TypeLib
actions. I opened the MSI up in ORCA, and realized that they are not in my
InstallExecuteSequence table. That makes sense why it wasn't working with
Class/Progid etc elements in the components. The action was never getting
called that dealt with those things. I assumed those actions would be
included, and that I didn't to explicitly add them. I'm going to give it a
try with the "correct" methodology again, this time with the correct actions
in the sequence and see if that does the trick. If so, I can get rid of the
self registration stuff, AND the duct tape batch file full of regasm calls.

Conveniently, re-ghosting the test box and building the installer take about
the same amount of time.. >sigh<

This application 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 PROTECTED]>,
>"Troy Howard" <[EMAIL PROTECTED]>  writes:
>
> > So, in my efforts to resolve the .Net COM issues, [...]
>
> Earlier, this thread was talking about registering a VB6 control.
>
> Now you're talking about registering a .NET assembly for COM interop.
>
> So which is it?
>
> I've registered .NET assemblies for COM interop with no problems by
> taking the output of /regfile.
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>  
> <http://www.xmission.com/~legalize/book/download/index.html<http://www.xmission.com/%7Elegalize/book/download/index.html>
> >
>
>Legalize Adulthood! <http://blogs.xmission.com/legalize/>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users