Re: [WiX-users] COM registration weirdness
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.htmlhttp://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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
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.htmlhttp://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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
Ok, I found a process that works... First, I had to explicitly add: InstallExecuteSequence UnregisterClassInfo Sequence=2700 / UnregisterProgIdInfo Sequence=2900/ UnregisterTypeLibraries Sequence=2300/ RegisterClassInfo Sequence='4600' / RegisterProgIdInfo Sequence='4800' / RegisterTypeLibraries Sequence='5500' / /InstallExecuteSequence 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.htmlhttp://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=100url=/ ___ 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=100url=/ ___ 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?
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: RegistryKey Root=HKCR Key=Foo RegistryValue Type=string Value= / RegistryValue Value=Bar Type=string / /RegistryKey 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
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.htmlhttp://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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM registration weirdness
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
RegistryValue Root=HKCR
Key=CLSID\{082EE6CC-A371-37A6-BF8A-090D9BD50A10}\InprocServer32
Value=mscoree.dll Type=string Action=write /)... 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 (Typelib, Class, ProgId, Interface, 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=100url=/
___
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=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Re mote SQL Authentication
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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Re mote SQL Authentication
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 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=100url=/ ___ 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
Re: [WiX-users] custom ui sample question
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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WixUI Banner image sizes
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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Merge existing MSIs into a single MSI as features
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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
