Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features?
John Vottero wrote: > Are you saying that it's impossible to create a good Installer based > Installer class? > No. > That's fine with me, who do I start with? I just need some direction > from Microsoft. Right now, I have the PowerShell team saying "use these > Installer based classes to install your Cmdlets" but the Windows > Installer/WiX people are saying "Yuck, don't use that crap!". What am I > supposed to do? > Ask the PowerShell team to do the right thing for their customers and their customers's customers. Worst case, they should document what the installer classes do so anyone can do it, regardless of tool. Better yet, they can provide merge modules, .wixlibs, or WiX extensions for strongly-typed authoring. Best of all, they can work with the WiX team to ship them in the box. Some teams already do some of it, but it's driven by customer demand. If they don't hear from customers that it's an issue, they're going to (logically) do the simplest thing. -- sig://boB http://bobs.org - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Device scan before install
Refer to "How To Force Reenumeration of a Device Tree From an Application" http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q259697 if you want to go for your own custom action. CM_Reenumerate_DevNode: http://msdn.microsoft.com/library/en-us/DevInst_r/hh/DevInst_r/cfgmgrfn_9ed0f83c-4b63-425f-b80b-9be5d69bb43a.xml.asp?frame=true Just one more thing. I have seen most of the custom (non-DIFx) device driver packages are run as immediate actions or external programs. Those actions should be a "deferred custom action" and preferably with no impersonation - which *can* be run in Local System Context. The former is the requirement for custom actions which changes the system. The latter allows normal users to install the package if privileged installation is allowed by the group policy. Regards, Chesong Lee -Original Message- From: Calin Iaru [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 4:42 AM To: Chesong Lee; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Device scan before install Hi Chesong, thanks for the link. From the FAQ: " Does the message cautioning that the hardware is unplugged at the end of the install actually scan for Hardware IDs? Or does this message just assume that the hardware isn't plugged in because a "software first" install has just completed? DIFxApp checks to determine whether or not the hardware is connected. " Not much to handle here. I think I will opt for a custom action. The logs generated by MSIEXEC after the Device Manager detected the hardware as "Other Device" show an extra call: DIFXAPP: INFO: ENTER UpdateDriverForPlugAndPlayDevices... MSI (s) (74!D0) [14:17:28:906]: Closing MSIHANDLE (128) of type 790531 for thread 1488 MSI (s) (74!D0) [14:17:33:703]: Creating MSIHANDLE (129) of type 790531 for thread 1488 DIFXAPP: SUCCESS:RETURN UpdateDriverForPlugAndPlayDevices. Maybe I can find the exact SetupAPI function which does a Hardware Scan before installing - the obvious candidate is the function above, but I need more info. Other driver installers like the Intel Ethernet Controller scan before installing - it uses InstallShield though. Best regards, Calin Chesong Lee wrote: > Take a look at DIFx > (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help > you. > Otherwise, you may have to create your own custom actions to force such > actions using SetupDi APIs. > Consult devcon samples in DDK as a reference. > > Regards, > > Chesong Lee > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru > Sent: Thursday, July 27, 2006 1:37 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Device scan before install > > Hi List, > > given the scenario below, I would like to know how to force a device > scan before installing > a driver: > Device Manager shows "Other Device" detected > The drivers are installed > The drivers are uninstalled > The device entry disappears from Device Manager, but there is no "Other > Device" section > Install the drivers again > A prompt message appears saying > "Please attach your device to this computer any time after the > installation has finished" > Device Manager does not show any entry for the device > > So the problem is that install/uninstall/install driver will not detect > the device on the second > install. > > Best regards, >Calin > > > - > 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
I see. How about just putting the component into Feature1 so that it will run when Feature1 is installed locally? Derek From: Scott Sam [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 5:12 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions I need to write out to a config file what features are being installed, so that the program that update/creates the database knows what database to create/update if any at all. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 6:12 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions What are you trying to do overall? Using feature conditions in a component’s condition is a little awkward – usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: From my understanding, it should right out Feat1 if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features?
John Vottero wrote: This is mostly tool for developer to get the cmdlet working. Release setup should set the registry keys explicitly. See, it's not just WiX crazies! It just sets series of registry keys. We need to document the keys which vendors need to set for registering snapins. I will open a bug for this. Will the PowerShell team create a WiX extension? There is no plan for V1. OK, that's good news. -- sig://boB http://bobs.org - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Device scan before install
Hi Chesong, Is there a way to supress the "New Hardware Wizard" when CM_Reenumerate_DevNode is called? None of the parameters can do it. I guess I have to ask this question in a forum; The Wizard appears in XP, but not in Server 2003. Best regards, Calin Chesong Lee wrote: > Refer to "How To Force Reenumeration of a Device Tree From an Application" > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q259697 > if you want to go for your own custom action. > > CM_Reenumerate_DevNode: > http://msdn.microsoft.com/library/en-us/DevInst_r/hh/DevInst_r/cfgmgrfn_9ed0f83c-4b63-425f-b80b-9be5d69bb43a.xml.asp?frame=true > > Just one more thing. I have seen most of the custom (non-DIFx) device driver > packages are run as immediate actions or external programs. Those actions > should be a "deferred custom action" and preferably with no impersonation - > which *can* be run in Local System Context. The former is the requirement > for custom actions which changes the system. The latter allows normal users > to install the package if privileged installation is allowed by the group > policy. > > Regards, > > Chesong Lee > > -Original Message- > From: Calin Iaru [mailto:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 4:42 AM > To: Chesong Lee; wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Device scan before install > > Hi Chesong, > > thanks for the link. From the FAQ: > " > Does the message cautioning that the hardware is unplugged at the end of > the install actually scan for > Hardware IDs? Or does this message just assume that the hardware isn't > plugged in because a > "software first" install has just completed? > > DIFxApp checks to determine whether or not the hardware is connected. > " > Not much to handle here. > > I think I will opt for a custom action. The logs generated by MSIEXEC > after the > Device Manager detected the hardware as "Other Device" show an extra call: > > DIFXAPP: INFO: ENTER UpdateDriverForPlugAndPlayDevices... > MSI (s) (74!D0) [14:17:28:906]: Closing MSIHANDLE (128) of type 790531 > for thread 1488 > MSI (s) (74!D0) [14:17:33:703]: Creating MSIHANDLE (129) of type 790531 > for thread 1488 > DIFXAPP: SUCCESS:RETURN UpdateDriverForPlugAndPlayDevices. > > Maybe I can find the exact SetupAPI function which does a Hardware Scan > before installing - the > obvious candidate is the function above, but I need more info. > > Other driver installers like the Intel Ethernet Controller scan before > installing - it uses InstallShield though. > > Best regards, > Calin > > Chesong Lee wrote: > >> Take a look at DIFx >> (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help >> you. >> Otherwise, you may have to create your own custom actions to force such >> actions using SetupDi APIs. >> Consult devcon samples in DDK as a reference. >> >> Regards, >> >> Chesong Lee >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru >> Sent: Thursday, July 27, 2006 1:37 PM >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] Device scan before install >> >> Hi List, >> >> given the scenario below, I would like to know how to force a device >> scan before installing >> a driver: >> Device Manager shows "Other Device" detected >> The drivers are installed >> The drivers are uninstalled >> The device entry disappears from Device Manager, but there is no "Other >> Device" section >> Install the drivers again >> A prompt message appears saying >> "Please attach your device to this computer any time after the >> installation has finished" >> Device Manager does not show any entry for the device >> >> So the problem is that install/uninstall/install driver will not detect >> the device on the second >> install. >> >> Best regards, >>Calin >> >> >> - >> 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] shortcut and validation error
I have a shortcut component in my setup package that fails ICE validation because it doesn't "use a registry key under HKCU as its KeyPath". I have the ALLUSERS property set to 1. This will set the ProgramMenuFolder to the "All Users" profile. Why does it still need to have a registry key under HKCU as its KeyPath? What do I need to do other then creating a registry key that won't be used? Thanks, -- Leo - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
Based on the information provided below, you’ll likely want to look into using the WixIIsExtension, WixSQLExtension, and WixUtilExtension (for some additional service configuration and xml manipulation custom actions). You’ll need to decide to use either WiX 2.0 or 3.0. We’re currently only encouraging adoption of 3.0 for groups shipping in 2007 or later. This is because 3.0 is under active development and you’ll avoid the intermediate bugs and schema changes associated with that if you stick with 2.0. If you use WiX 3.0, you’ll get some help with creating the initial installation by using a tool called heat.exe. It can create WiX authoring from type libraries, self-reg dlls, directories, web sites (partial support – no app pools yet), and assembly RegistrationServices. A tool in WiX 2.0 performs similar functions – it’s called tallow.exe. It does not support type libraries or web sites (it was the predecessor to heat). There has been a bit of a debate raging here lately about the Installer classes. WiX and MSI actually have no formal interaction with the installer classes and the WiX team advises against using them because they do not provide a complete rollback experience in the case of installation failures. Full disclosure however: there are some people that prefer them because they are easy, but you’ll often find that going the easy route in setup is a bit more dangerous (as is the case here). Ideally we need to add some additional logic to heat.exe to convert Installer operations into simple Registry and File operations since that is the most robust and declarative installation method possible with MSI. Your plan for the upgrade sounds good. You would likely need some sort of executable “bootstrapper” to save off the config settings, perform the uninstall, and install the new MSI file. Derek From: Rick Glos [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 10:41 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller First off. Thanks for the warm welcome. Second. Thanks for the quick response and ideas by all three of you (Derek, Richard, and Bob). Answers to your questions Derek: I’ve been told we usually release on a quarterly cycle although that isn’t set in stone (I just started working here in Feb ’06 and assisted with the release in Mar 06. Then rolled the Jul ’06 release myself – the complexity and difficulty is what led me to WiX, knowing that there’s got to be a better way than this spaghetti, procedural code.) Our next release is targeted for end of November ‘06. Our product is a help desk/support, task, and issue tracking solution. The Visual Studio solution file actually consists of 14 projects (any code is C# fyi). We install 2 services, 4 libraries, 3 websites and 4 sql server databases (as well as a couple unit test and database projects). We interact with SQL, IIS, and Services. I’ve done some investigation into the System.Configuration.Installer classes and it looked promising. Not sure how that integrates with WiX though (?). Our current installer is basically a custom rolled C# Windows Application that looks like an installer. Using a wizard like interface, it prompts the user for a series of configuration values (virtual directory names, user name, password, sql server name, etc) and then runs an install or upgrade method to do the work. It has to do things like create/upgrade SQL databases, install aspx files, configure IIS (create an app pool, create 3 virtual directories), it also creates a user account (to run the app pool under), joins it to a group, modifies the permissions on some files and folders, installs and starts 2 services, modifies the web.config to store and encrypt connection strings and so on... J [I know you mentioned in your article that you are interested in this stuff]. It doesn’t use installer classes yet although I’m thinking that perhaps it should but I’m not sure I understand how that integrates with the Windows Installer. Sorry this paragraph is so long. Based on what the 3 of you have said, it sounds like perhaps what I should consider for the upgrade is save off the current settings/data (web.config, sql databases, and any custom files they’ve added to the web sites) then perform an uninstall. Then let the windows installer do an install and then restore those settings/data and then they’d be go to go for future upgrades using the windows installer. Does this sound reasonable? Would I be able to do this within the context of the windows installer (msi)? Or would I have our customers run a ‘Setting Saver’ app. Run the uninstall app. Then run the new windows installer (msi) and then run a ‘Setting Restorer’
[WiX-users] Launch Checkbox
Hi All,I'm trying to add a checkbox to the Finish dialog which will let me launch an application conditionallyI've tried adding a checkbox like so: And then having But it doesn't seem to work...I'm sure many people have done this in the past... Please help!?!Thanks,-- Shmarya--- [EMAIL PROTECTED] - http://shmarya.netNUnit rocks! http://nunit.com - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC and call Custom Action
I don't think it's a good idea to put Installer classes in the same assembly that they're installing for. This is one of the reasons. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John HideySent: Wednesday, July 26, 2006 1:51 PMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn’t actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, we’ve recently identified several reasons why we’d like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (it’s not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an “unreal column”. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, we’d like to remove the unreal column concept. This doesn’t mean that metadata can no longer be associated with standard tables – it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with “Wix” There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup – supports ComponentGroup authoring concepts - ComponentGroup – support ComponentGroup authoring concept - Merge – supports merge modules - Actions – supports scheduling for standard and custom actions - SuppressAction – supports suppression of actions - CustomTables – supports custom tables without needing an extension - EnsureTables – supports ensuring a table exists in an MSI file - RowData – contains row information for CustomTables - UI – supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, we’d like to preface all WiX-specific table names with “Wix” similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with “Msi”. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc… These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using elements in the wixobj files and instead switching to unreal “WixComplexReference” tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change – removing custom xml from the wixobj and wixlib files – can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, I’ve called it out here because this change is what prompted us to begin looking at breaking backwar
Re: [WiX-users] WiX and web applications
Tallow (for WiX 2.0) and Heat (for WiX 3.0) are the standard ways of creating WiX authoring based on existing data like directories full of files and such. Note that to do this the "right" way is somewhat non-trivial. The thing about WI is that you shouldn't be changing component GUIDs all the time for files that you've previously installed, so you don't necessarily want to regenerating your authoring from scratch every time. As I recall, Tallow sidesteps this issue by not creating GUIDs for your components and making you do that by hand (or with some sort of script you write). It isn't an easy problem to solve. Another thing you might consider doing is generating the authoring dynamically from the existing source for the initial build and then just tweaking the authoring by hand thereafter. Typically, this isn't too hard to keep on top of if you do it as you go. Other people on this list have created some really sophisticated build systems that do automate this task while keeping track of existing components and such. There is probably a significant investment in time to get something like this, but it might pay off. Perhaps someone else will share their solution. The email archives probably have some pointers as well. Joe K. - Original Message - From: David Keaveny To: wix-users@lists.sourceforge.net Sent: Thursday, July 27, 2006 8:30 PM Subject: [WiX-users] WiX and web applications Is there an equivalent in WiX to Visual Studio 2003's web deployment project? In other words, a simple way of adding all the .ascx, .config, .jpg etc files to my MSI without having to hand-code each individual entry? VS can take the output from a project, and build an MSI from that; I don't see an obvious way to do it in WiX. I've had no problem with WiX for packaging Windows services, since the file counts are relatively low; but my web application contains hundreds of files, and is under constant development, so there must be some way of automating things. Regards, David - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC and call Custom Action
Is there a way to do what I want to do. I would think that this can be done. Many installers do this, but maybe they use a C++ custom action which does the registry for them. Any thoughts? John From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 3:50 AM To: John Hidey Cc: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: Re: [WiX-users] GAC and call Custom Action John Hidey wrote: Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn’t actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? There is no temporary location. Files to be installed into the GAC aren't put down until the install is being committed. -- sig://boBhttp://bobs.org - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] password is incorrectly set during ServiceInstall
I think there is already a Bug or Feature Request tracking this. Yes, it's possible... just hasn't been done yet. -Original Message- From: Chandra Rentachintala [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 10:52 AM To: Chandra Rentachintala; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] password is incorrectly set during ServiceInstall It turned out to be "Local Security Policy" issue than of password. Adding the service user to the "Log on as a service" rights under "Administrative Tools" -> "Local Security policy" /Secutity Settings/Local Policies/User Rights Management" in XP and similar one in 2003 fixed the issue. Apparently setting the logon as user/password thru the services.msc service properties is setting this rights by default, so it was working thru that path. Is it possible to add this as part of the ServiceInstall code in Wix? Thanks to chris leon from wix list for finding this solution. - chandra -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Tuesday, July 11, 2006 10:09 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Yes. It has a $ at the beginning of password. How to overcome this problem as we can't predict what kind of passwords people use at customer locations?. Is there a way to tell wix/msi to take Password string as it is? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Tuesday, July 11, 2006 7:14 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Is there a $ at the start of the password? It occurs to me that if Windows Installer is seeing a $ at the start of the password in square brackets it could be attempting to do substitution for a component path (that's what $ at the start of a name means). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Monday, July 10, 2006 7:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall A dependency issue seems most likely in the circumstances. What happens if you install the service but don't attempt to start it during the installation? Does it start manually from the services applet? If it does you know that the account is fine but something like a dependent Dll or assembly is missing when the service is started. If it doesn'r start at reboot time, this can be a dependency on another service that you haven't configured. As an aside, you should look at MsiHiddenProperties as a way of not exposing passwords in a log! Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, July 07, 2006 6:00 PM To: 'Chandra Rentachintala'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall The error message from StartServices is pretty dismal. The same message is presented for pretty much all reasons. More like than not, you service won't start because some dependency is missing or something else. You should be able to try diagnosing the service start while the dialog box is up... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Friday, July 07, 2006 1:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] password is incorrectly set during ServiceInstall I have my service installed like this and it installs the service correctly, but service is unable to start due to login failure. I traced the logs and the password is correct there. If I set the same password in services.msc, it works fine. ServicePassword has couple of '$' chars in it, if that is of any significance. Anyone hit this issue and found the solution, let me know. Thanks Chandra - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, we’ve recently identified several reasons why we’d like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (it’s not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an “unreal column”. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, we’d like to remove the unreal column concept. This doesn’t mean that metadata can no longer be associated with standard tables – it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with “Wix” There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup – supports ComponentGroup authoring concepts - ComponentGroup – support ComponentGroup authoring concept - Merge – supports merge modules - Actions – supports scheduling for standard and custom actions - SuppressAction – supports suppression of actions - CustomTables – supports custom tables without needing an extension - EnsureTables – supports ensuring a table exists in an MSI file - RowData – contains row information for CustomTables - UI – supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, we’d like to preface all WiX-specific table names with “Wix” similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with “Msi”. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc… These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using elements in the wixobj files and instead switching to unreal “WixComplexReference” tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change – removing custom xml from the wixobj and wixlib files – can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, I’ve called it out here because this change is what prompted us to begin looking at breaking backwar
[WiX-users] ANSI Characters
I'm having a lot of trouble getting an MSI installer to work with file names or folders containing characters like Á or ó. Whenever I attempt to run the .msi it says that ?_propos_du_bouton_d_ic?ne.htm was an invalid file name, but that's not what I even named the file. The file was called Á_propos_du_bouton_d_icóne.htm How do I get my installer to let me use characters like Á or ó with my file names and directory names. I'm using the most recent version of the Wix 2.0 toolset. - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] SelfRegCost on windows 2003 Server
Title: SelfRegCost on windows 2003 Server Greetings all, I'm not sure if this is a bug with WIX, or if the problem is this end. We have a load of self registering dll's, I know, don't start. These babies work fine when installed on XP, the registry entries all appear fine etc. etc. When I run the same installer on 2003 server standard edition the installer fails with a "failed to register blah blah blah.dll" error. Our old Installshield versions manage to self register on 2003 fine... Any offers? Cheers ta, Simon. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
Title: rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, we’ve recently identified several reasons why we’d like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (it’s not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an “unreal column”. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, we’d like to remove the unreal column concept. This doesn’t mean that metadata can no longer be associated with standard tables – it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with “Wix” There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup – supports ComponentGroup authoring concepts - ComponentGroup – support ComponentGroup authoring concept - Merge – supports merge modules - Actions – supports scheduling for standard and custom actions - SuppressAction – supports suppression of actions - CustomTables – supports custom tables without needing an extension - EnsureTables – supports ensuring a table exists in an MSI file - RowData – contains row information for CustomTables - UI – supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, we’d like to preface all WiX-specific table names with “Wix” similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with “Msi”. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc… These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using elements in the wixobj files and instead switching to unreal “WixComplexReference” tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change – removing custom xml from the wixobj and wixlib files – can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, I’ve called it out here because th
Re: [WiX-users] password is incorrectly set during ServiceInstall
It turned out to be "Local Security Policy" issue than of password. Adding the service user to the "Log on as a service" rights under "Administrative Tools" -> "Local Security policy" /Secutity Settings/Local Policies/User Rights Management" in XP and similar one in 2003 fixed the issue. Apparently setting the logon as user/password thru the services.msc service properties is setting this rights by default, so it was working thru that path. Is it possible to add this as part of the ServiceInstall code in Wix? Thanks to chris leon from wix list for finding this solution. - chandra -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Tuesday, July 11, 2006 10:09 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Yes. It has a $ at the beginning of password. How to overcome this problem as we can't predict what kind of passwords people use at customer locations?. Is there a way to tell wix/msi to take Password string as it is? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Tuesday, July 11, 2006 7:14 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Is there a $ at the start of the password? It occurs to me that if Windows Installer is seeing a $ at the start of the password in square brackets it could be attempting to do substitution for a component path (that's what $ at the start of a name means). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Monday, July 10, 2006 7:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall A dependency issue seems most likely in the circumstances. What happens if you install the service but don't attempt to start it during the installation? Does it start manually from the services applet? If it does you know that the account is fine but something like a dependent Dll or assembly is missing when the service is started. If it doesn'r start at reboot time, this can be a dependency on another service that you haven't configured. As an aside, you should look at MsiHiddenProperties as a way of not exposing passwords in a log! Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, July 07, 2006 6:00 PM To: 'Chandra Rentachintala'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall The error message from StartServices is pretty dismal. The same message is presented for pretty much all reasons. More like than not, you service won't start because some dependency is missing or something else. You should be able to try diagnosing the service start while the dialog box is up... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Friday, July 07, 2006 1:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] password is incorrectly set during ServiceInstall I have my service installed like this and it installs the service correctly, but service is unable to start due to login failure. I traced the logs and the password is correct there. If I set the same password in services.msc, it works fine. ServicePassword has couple of '$' chars in it, if that is of any significance. Anyone hit this issue and found the solution, let me know. Thanks Chandra - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make you
[WiX-users] ISAPI Filter installation hangs IIS
Has anyone encountered this? I'm trying to install a single sign on isapi filter, and at the very end of the installation when it says "install to metabase" or something like that, the thing hangs and eventually all resources are eaten up causing the need for a reboot. Is this what was fixed in 3.0.1926.0 ?I've been trying to get 3.0.1926.0 to compile my installer, but keep getting the following error:[exec] Microsoft (R) Windows Installer Xml Linker version 3.0.1926.0 [exec] Copyright (C) Microsoft Corporation 2003. All rights reserved.[exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(70) : error LGHT0102 : The localization variable !(loc.ConfigureIIs ) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(71) : error LGHT0102 : The localization variable !( loc.StartMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(72) : error LGHT0102 : The localization variable !( loc.RollbackMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(73) : error LGHT0102 : The localization variable !( loc.CommitMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(74) : error LGHT0102 : The localization variable !( loc.WriteMetabaseChanges) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(36) : error LGHT0102 : The localization variable !( loc.msierrIISCannotConnect) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(37) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebSite) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(38) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(39) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadVDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(40) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadFilters) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(41) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadMimeMap) is unknown. Please ensure the variable is defined. Any help would be appreciated, thanks.-James - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
First off. Thanks for the warm welcome. Second. Thanks for the quick response and ideas by all three of you (Derek, Richard, and Bob). Answers to your questions Derek: I’ve been told we usually release on a quarterly cycle although that isn’t set in stone (I just started working here in Feb ’06 and assisted with the release in Mar 06. Then rolled the Jul ’06 release myself – the complexity and difficulty is what led me to WiX, knowing that there’s got to be a better way than this spaghetti, procedural code.) Our next release is targeted for end of November ‘06. Our product is a help desk/support, task, and issue tracking solution. The Visual Studio solution file actually consists of 14 projects (any code is C# fyi). We install 2 services, 4 libraries, 3 websites and 4 sql server databases (as well as a couple unit test and database projects). We interact with SQL, IIS, and Services. I’ve done some investigation into the System.Configuration.Installer classes and it looked promising. Not sure how that integrates with WiX though (?). Our current installer is basically a custom rolled C# Windows Application that looks like an installer. Using a wizard like interface, it prompts the user for a series of configuration values (virtual directory names, user name, password, sql server name, etc) and then runs an install or upgrade method to do the work. It has to do things like create/upgrade SQL databases, install aspx files, configure IIS (create an app pool, create 3 virtual directories), it also creates a user account (to run the app pool under), joins it to a group, modifies the permissions on some files and folders, installs and starts 2 services, modifies the web.config to store and encrypt connection strings and so on... J [I know you mentioned in your article that you are interested in this stuff]. It doesn’t use installer classes yet although I’m thinking that perhaps it should but I’m not sure I understand how that integrates with the Windows Installer. Sorry this paragraph is so long. Based on what the 3 of you have said, it sounds like perhaps what I should consider for the upgrade is save off the current settings/data (web.config, sql databases, and any custom files they’ve added to the web sites) then perform an uninstall. Then let the windows installer do an install and then restore those settings/data and then they’d be go to go for future upgrades using the windows installer. Does this sound reasonable? Would I be able to do this within the context of the windows installer (msi)? Or would I have our customers run a ‘Setting Saver’ app. Run the uninstall app. Then run the new windows installer (msi) and then run a ‘Setting Restorer’ app. That seems like a lot of steps but I’m thinking aloud here. Perhaps this could all be handled within the context of the msi. Anyway. Thanks for reading this far if you made it and thanks for the advice. Hope to keep the discussion going. Rick From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:52 PM To: Rick Glos; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller First off, welcome! There’s some information that can help guide our answers for you: When does your product ship? What is your product (just curious)? More specifically, what does it interact with (COM, services, MSMQ, IIS, SQL, etc…)? How does the C# installer install things? Does it use the Installer classes or manually set registry keys and copy files? To answer some of your questions: I’m not sure how the upgrade story would work – it all depends on how you currently handle uninstall and upgrade scenarios. Is there something you’d need to run to perform an uninstall on the previous version (would it be managed code)? Once you get all customers on an MSI deployed setup it should be easy to have them all use the same technology after that point. Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Glos Sent: Thursday, July 27, 2006 12:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller Hello, I’ve spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just r
Re: [WiX-users] [WiX-devs] GAC and call Custom Action
This is actually the primary reason why I started the thread about WiX and support for installation of Windows instrumentation features. I too use Enterprise Library and have suffered with some of these very issues. All EL does is install some event sources, performance counters and WMI schema for instrumentation. In order to do this in WiX, it varies from "not too bad" to . Event logs are really just a set of registry entries and are pretty straightforward. .NET event sources (for the most part) always use the messages dll that comes with the .NET framework, so you don't even need to install a messages dll. You just need to point to the existing one. The rest of the registry stuff is easy. It is actually easy to do a better job than .NET does at creating event sources this way, especially with .NET 1.1, as you get more control over how they are created and behave. Perf counters are harder. WiX has support for perf counters and has some documentation on how to do them. I think we also determined that .NET perf counters can be installed this way. The problem is that the .NET perf counter install mechanism actually dynamically generates some of the files (the .h and .ini), and there isn't a very straightforward way to harvest those that I know of besides installing with the installer classes once and finding the resulting files. It is a little ugly. I had a suggestion for Derek that it would be cool if Heat could reverse engineer a perf counter installer to make it easier to generate the authoring for this stuff. WMI seems to be a bit of a black hole. I've never bothered to reverse engineer those installer classes to see what they actually do, but it does not seem to be very well understood. One other thing that could be done for EL specifically would be to harvest all of the installer classes from the actual EL source (which they give you) and create your own little assembly that just has the installer stuff in it, but gets installed to the file system instead of the GAC. You'd still be using InstallUtil to install the various components, but you at least wouldn't have the GAC problem. Ideally though, you'd just create the appropriate authoring and do it that way. And BTW, a wixlib or merge module for EL would be a nice contribution to the EL community. I think the EL team at Microsoft actually looked at WiX for a while, as I know Peter Provost was posting here and was asking questions (although that could have been for the Smart Client block instead), but it doesn't look like they ever decided to package things as an MSI for whatever reason. Joe K. -Original Message- From: Rob Mensching [mailto: [EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:01 AM To: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right. The problem is that Assemblies going to the GAC aren't committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a "bad thing". My suggestion (which is rarely popular ) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway? From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:36 PM To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John -- John Hidey[EMAIL PROTECTED] -- John Hidey[EMAIL PROTECTED] - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourcefor
[WiX-users] How to set one File for two Components
Hello. I have two Components installed into different directories. And these Components include the same file, so the same file appears in two different directories. I have authored an MSM with two elements under different elements. Those elements include elements with different Id's pointing to the same source file. But I do not like this way. The file is twice copied into the database. How can do it in another, better way? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
I need to write out to a config file what features are being installed, so that the program that update/creates the database knows what database to create/update if any at all. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 6:12 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions What are you trying to do overall? Using feature conditions in a component’s condition is a little awkward – usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: From my understanding, it should right out Feat1 if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Device scan before install
Hi Chesong, thanks for the link. From the FAQ: " Does the message cautioning that the hardware is unplugged at the end of the install actually scan for Hardware IDs? Or does this message just assume that the hardware isn't plugged in because a "software first" install has just completed? DIFxApp checks to determine whether or not the hardware is connected. " Not much to handle here. I think I will opt for a custom action. The logs generated by MSIEXEC after the Device Manager detected the hardware as "Other Device" show an extra call: DIFXAPP: INFO: ENTER UpdateDriverForPlugAndPlayDevices... MSI (s) (74!D0) [14:17:28:906]: Closing MSIHANDLE (128) of type 790531 for thread 1488 MSI (s) (74!D0) [14:17:33:703]: Creating MSIHANDLE (129) of type 790531 for thread 1488 DIFXAPP: SUCCESS:RETURN UpdateDriverForPlugAndPlayDevices. Maybe I can find the exact SetupAPI function which does a Hardware Scan before installing - the obvious candidate is the function above, but I need more info. Other driver installers like the Intel Ethernet Controller scan before installing - it uses InstallShield though. Best regards, Calin Chesong Lee wrote: > Take a look at DIFx > (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help > you. > Otherwise, you may have to create your own custom actions to force such > actions using SetupDi APIs. > Consult devcon samples in DDK as a reference. > > Regards, > > Chesong Lee > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru > Sent: Thursday, July 27, 2006 1:37 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Device scan before install > > Hi List, > > given the scenario below, I would like to know how to force a device > scan before installing > a driver: > Device Manager shows "Other Device" detected > The drivers are installed > The drivers are uninstalled > The device entry disappears from Device Manager, but there is no "Other > Device" section > Install the drivers again > A prompt message appears saying > "Please attach your device to this computer any time after the > installation has finished" > Device Manager does not show any entry for the device > > So the problem is that install/uninstall/install driver will not detect > the device on the second > install. > > Best regards, >Calin > > > - > 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question: Migrating Existing Installer to Windows Installer
When we moved over to MSI we had to deal with existing InstallShield installs. I got round the problem by looking in the registry for the key InstallShield writes under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall using a RegistrySearch. I then used the set property as the condition for a custom error telling the user to uninstall the existing version. This might seem crude, but it does the job and each customer only has to do it once. Rob Rick Glos wrote: > Hello, > > I’ve spent the last two days getting familiar with WiX, the windows > installer, and going through the great tutorial on WiX > (http://www.tramontana.co.hu/wix/). I especially liked the article > posted a year ago > (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) > > that talks about doing the installer during the development cycle and > not at the end of it. We are badly in need of doing this. > > I have a question however. How do we migrate from our current installer > to the Windows Installer for existing customers? > > We just released version 5.0 of our product. Spending 6 weeks updating > our installer (we have a custom C# installer). I can see our *new* > customers instead using a new .msi for later versions (5.5, 6.0, etc). > What do I do about our existing customers when they wish to upgrade? > They’ve never installed originally with a Windows Installer. How do I > get them on the same track? > > > > Thanks for any advice, > > Rick Glos > > > > > - > 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC and call Custom Action
John Hidey wrote: Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn’t actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? There is no temporary location. Files to be installed into the GAC aren't put down until the install is being committed. -- sig://boB http://bobs.org - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
It would take some work to rebuild our wixlibs, but we plan to rebuild them anyway when moving to 3.0 to take advantage of the embedded localization information. So, no problem here without wixlib backwards-compatibility. Regards, Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, July 27, 2006 7:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, we’ve recently identified several reasons why we’d like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (it’s not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an “unreal column”. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, we’d like to remove the unreal column concept. This doesn’t mean that metadata can no longer be associated with standard tables – it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with “Wix” There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup – supports ComponentGroup authoring concepts - ComponentGroup – support ComponentGroup authoring concept - Merge – supports merge modules - Actions – supports scheduling for standard and custom actions - SuppressAction – supports suppression of actions - CustomTables – supports custom tables without needing an extension - EnsureTables – supports ensuring a table exists in an MSI file - RowData – contains row information for CustomTables - UI – supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, we’d like to preface all WiX-specific table names with “Wix” similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with “Msi”. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc… These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
First off, welcome! There’s some information that can help guide our answers for you: When does your product ship? What is your product (just curious)? More specifically, what does it interact with (COM, services, MSMQ, IIS, SQL, etc…)? How does the C# installer install things? Does it use the Installer classes or manually set registry keys and copy files? To answer some of your questions: I’m not sure how the upgrade story would work – it all depends on how you currently handle uninstall and upgrade scenarios. Is there something you’d need to run to perform an uninstall on the previous version (would it be managed code)? Once you get all customers on an MSI deployed setup it should be easy to have them all use the same technology after that point. Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Glos Sent: Thursday, July 27, 2006 12:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller Hello, I’ve spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks updating our installer (we have a custom C# installer). I can see our new customers instead using a new .msi for later versions (5.5, 6.0, etc). What do I do about our existing customers when they wish to upgrade? They’ve never installed originally with a Windows Installer. How do I get them on the same track? Thanks for any advice, Rick Glos - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning
Wixlibs don’t have great documentation, but they are really simple. You can take a look at the usage info for lit and probably figure most of the options out. If you have a scenario where component referencing doesn’t work, I’d like to know because it’s a bug. Can you give me a pointer to the docs which say an extension may be a path? I’d like to get that fixed. Also, why do you need to use a path to load the extension versus just putting the extension dlls next to wix.dll? Thanks, Derek From: Shmarya Rubenstein [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 10:52 PM To: [EMAIL PROTECTED] Cc: John Ludlow; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning Inlining back :) On 7/25/06, Derek Cicerone <[EMAIL PROTECTED]> wrote: inline From: Shmarya Rubenstein [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 25, 2006 10:20 AM To: [EMAIL PROTECTED] Cc: John Ludlow; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning Derek, I hadn't thought of using wixlibs - I'll look into that... How does it work? .wxs are compiled to .wixlib and then can simply be included on a link line? what's the difference between this and .wixobj? Will I still have the same kind of powerful dependency chaining as I have with merge-modules (similar to .net referencing - anything goes except circular references). [DerekC] In WiX 2.0, a wixlib is basically just a concatenation of the xml from several wixobj file. In WiX 3.0, we also allow a wixlib to carry localization strings and full binaries in a cabinet file (making this very similar to a merge module). [Shmarya] Ok... I'll look into this... I assume it's documented in the chm? I know that I had trouble with Component referenceing because you can't reference a single component from multiple features... at least, I couldn't get it to work... [DerekC] You should absolutely be able to reference a single component from multiple features using multiple ComponentRef elements under each feature. In WiX 3.0, it's also possible to create groups of components to be included under a feature by using the ComponentGroup element (this brings you extremely close to what you'd get with a merge module). [Shmarya] I know that I had difficulty with this... kept getting errors about components being referenced from more than one feature... perhaps it was a bug which is now fixed? The reason I'm compiling wix in net2.0 is because I needed to apply a fix to the code which loads extensions (it calls Assembly.Load, when it should conditionally call Assembly.LoadFrom if a path is passed on the -ext cli instead of an assemblyname), and its just easier for me to compile in 2.0... I've also written an internal extension which is 2.0 specific... Other than that, no specific reason ;) [DerekC] I see. Why not just install your extensions next to wix.dll so that the assembly name is enough to find them? Also, if you run wix under .net 2.0, it should be possible to have wix use an extension targeted to .net 2.0. You'll want to be very careful about creating a private fork of the wix sources – it can become difficult to keep up with latest source drops over time as the changes collide. In a group I used to work for, we originally took wix source drops but eventually found that the integration costs of moving to newer versions became so expensive that it was a lot easier to just stop making custom modifications and just ensure all the stuff we wanted was supported by the main toolset (this is where the wix extensions came from actually – a desire to release binaries that still allowed custom authoring). So, if there is a good reason to support loading extensions by path, perhaps it should be supported in the wix toolset directly. [Shmarya] I don't see my work as a fork really... But I completely agree with you... I'd prefer to have my mods implemented in the official binaries. Unfortunately, I'm having trouble getting my employer to allow me to sign the Assignment Agreement... :( Just out of interest, the documentation says that path based loading of extensions is allowed... so the fact that it doesn't work is probably a bug... On 7/25/06, Derek Cicerone <[EMAIL PROTECTED] > wrote: Have you tried using wixlib files and Fragments instead of merge modules for breaking up your authoring into lots of little pieces? I would strongly suggest this solution over lots of merge modules because you will end up with a much smaller msi package (it won't have all the modularization guids), better error messages when problems occur, much faster build times (because you aren't creating tons of cabinets and doing lots of expensive merge operations), and you should be able to support the same scenarios with wixlib files as merge modules. Also, why is it
[WiX-users] GAC and call Custom Action
Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn’t actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Device scan before install
Take a look at DIFx (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help you. Otherwise, you may have to create your own custom actions to force such actions using SetupDi APIs. Consult devcon samples in DDK as a reference. Regards, Chesong Lee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru Sent: Thursday, July 27, 2006 1:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Device scan before install Hi List, given the scenario below, I would like to know how to force a device scan before installing a driver: Device Manager shows "Other Device" detected The drivers are installed The drivers are uninstalled The device entry disappears from Device Manager, but there is no "Other Device" section Install the drivers again A prompt message appears saying "Please attach your device to this computer any time after the installation has finished" Device Manager does not show any entry for the device So the problem is that install/uninstall/install driver will not detect the device on the second install. Best regards, Calin - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about repeat installation of the same MSI
Hello. My installation package consists of MSI-file and set of directory with additional files. Those files are used by type 1 custom action (DLL file stored in a Binary table stream). Since these directory is required, in MSI there is a property that checks for the directory existence (via '') and a custom action that aborts installation if that property is empty. My installation should not have maintainence installation. It should simple install everything as it is first-time installation. When I run installation for the first time on a clear machine every thing works fine. When I repeat same installation on the same machine the custom action that checks for the directory existence property triggers and aborts installations. Learning log I found that MSI-engine after first installation copies my msi into its internal directories and runs this copied msi instead. And this cause a problem since MSI-engine does not copy my additional directory. Is there any way to disable copying? How can make MSI-engine to use my msi but not copied? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX and web applications
Is there an equivalent in WiX to Visual Studio 2003’s web deployment project? In other words, a simple way of adding all the .ascx, .config, .jpg etc files to my MSI without having to hand-code each individual entry? VS can take the output from a project, and build an MSI from that; I don’t see an obvious way to do it in WiX. I’ve had no problem with WiX for packaging Windows services, since the file counts are relatively low; but my web application contains hundreds of files, and is under constant development, so there must be some way of automating things. Regards, David - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
Although I've never looked for it, I can't imagine that there would be any API call that would allow you to disable the WHQL certification warnings programmatically. If it existed, everyone would use it and it would defeat the whole purpose. I have seen one driver that, in their installation instructions, directed the user to temporarily disable the warnings manually. Jim - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Making Use Of Properties In Cutom Actions
I am trying to run a batch file post install. In my Custom Action I specify the location of the batch file using the FileKey attribute. I then want to pass a parameter (file system location) into the batch file, so I use the ExeCommand attribute. When I hard code this parameter, everything works fine, however I really want to use a property value read in from the registry but I cant the Custom Action to use the property which is working fine in other parts of my installer: Key='Software\Exchange FS\Exweb' Name='InstallDir' /> Any Ideas? Can I not use properties in this way in custom actions? - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
What are you trying to do overall? Using feature conditions in a component’s condition is a little awkward – usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: From my understanding, it should right out Feat1 if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets?
WiX 3.0 has a very different method of customizing the dialogs than WiX 2.0 which is so far undocumented. It's (hopefully) much more simple. Basically, just grab a sequence file from the sources that is similar to what you want (like WixUI_Mondo.wxs) and put that in your sources and modify it to only include the dialogs you want. Depending upon the dialog, it might need to the following to get removed: Dialogs added via - just remove the element. Dialogs referred to via a element - change the sequencing of the dialogs so the one you don't want is no longer in there. There are different steps because dialogs are displayed via different methods (its an artifact of how MSI works). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafuse Robert Sent: Wednesday, July 26, 2006 9:21 AM To: 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets? Okay, I'm confused. The section "Customizing dialog sets" at http://wix.sourceforge.net/manual-wix2/WixUI_dialog_library.htm mentions the files CustomDialogSet.build, CustomDialogSet.wxs and TestCustom.wxs but I can not find them in the WiX 2.0 binaries or source package (they don't seem to be in 3.0 either). Am I missing something? _ Bob Rafuse > -Original Message- > From: Rafuse Robert > Sent: Wednesday, July 26, 2006 12:08 PM > To: 'wix-users@lists.sourceforge.net' > Subject: RE: Is there a way to suppress license agreement > dialog in stock dialog sets? > > > Okay, ignore the question... Immediately after I hit Send, I > stumbled across "Customizing dialog sets" in the online docs. > > I ~swear~ I looked for this earlier... I must have mis-typed. > > Sorry to bother. > > _ > Bob Rafuse > > > > > > -Original Message- > > From: Rafuse Robert > > Sent: Wednesday, July 26, 2006 12:04 PM > > To: wix-users@lists.sourceforge.net > > Subject: Is there a way to suppress license agreement dialog > > in stock dialog sets? > > > > > > WiX 2.0.4305.0 > > > > I am creating an .msi that will only be used internally by my > > associatesy. This install does not require a license > > agreement dialog. I was wondering, is it at all possible to > > suppress this dialog while still using the stock WiX dialog sets? > > > > Thanks, > > > > --- > > Bob Rafuse > > > Important Note: This email and any attachment hereto are confidential and may contain trade secrets or may be otherwise protected from disclosure. If you have received it in error you are in notice of this fact. Please notify us immediately by reply email and then delete this email and any attachment from your system. Please understand that you are not allowed to copy this email or any attachment hereto or disclose its contents to any other person. Thank you. --- Important Note: This e-mail message and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient you must not use, copy, disclose or take any action based on this e-mail or any information and attachment contained in the message. If you have received this e-mail in error, please advise the sender immediately by reply e-mail or telephone and delete this message and any attachment from your system. Thank you. - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Controls with Conditions
I'm assuming that this is a lack of understanding on my part and is more of an MSI question than Wix itself. I have a dialog which requires you to enter the Database Name before you can click on Next. I have a condition on the Next Button that makes sure the Database Name is entered. 1 OR AND This works fine but requires the user to tab out of the field before it is enabled. Since the installer may just type in the box and want to click on the Next button it is not enabled. The property doesn't get set until the text field is exited. Is there any way to update the property with every key press? Should I handle this in a message from the next saying 'Please enter a database'? Thanks, _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
There is no public APIs to adjust driver signing policy from the application. Even though there are some hacks for that, it is a tempering for operating systems and highly discouraged. The only right way to achieve your goal is to get WHQL certification. Authenticode signing is also applicable only for Windows 2003 Server or later platforms. Regards, Chesong Lee From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Wednesday, July 26, 2006 6:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Difx, Authenticode and Driver Signing Hi all, I have a driver package which I'm installing using DifX and WiX. For various reasons (Cash, Time, Confidentiality...) I can't submit the driver to WHQL for certification. I would, however, love to get rid of the annoying boxes which are displayed during installation to warn [read: iritate] the user. I read on various WDK/DDK pages that Authenticode signing the drivers should do the trick, but it seems that this is only applicable to Windows Server 2003+, which kinda sucks for my Win2K and XP users... BTW: I only found out that it doesn't work for XP and 2K, after purchasing a Thawte certificate and signing all the drivers - bleh :P. I know that it is possible to ignore these warnings globally by changing a setting on the computer manually. I've also seen installations for drivers which automatically turn driver signing warnings off for the duration of the installation, and turn it back on when they're done. Does anyone know how to acheive this? Better yet, have I made a mistake with my authenticode signing? Thanks, -- Shmarya --- [EMAIL PROTECTED] - http://shmarya.net NUnit rocks! http://nunit.com - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
It's not something your mom'd install... Unless she happens to have a seriously large sum of money and a small corporation burning a hole in her pocket ;)The product is a very specialized system which is installed only by very select customers... It is a mixed software/hardware/firmware system, with both a very large code base and a large number of custom hardware devices. Because these devices are custom built (and their drivers too of course!), and more importantly, because their usage is so heavily restricted and some of them are even confidential, we cannot submit them to WHQL for testing... This means that our poor users, select as they may be, end up having to click "Continue Anyway" anywhere between 20 to 50 (!) times during the installation... Needless to say, this is very frustrating... I haven't got any problem signing my drivers, in fact, I've already purchased an authenticode signature and signed them! But there should be some way to allow such drivers to be installed without all the irritating messageboxes... This functionality seems to be available in Windows Server 2003 (and supposedly in Vista/Longhorn as well), but meanwhile, all of our users are on Win2k and XP boxes... I know that it is possible to hack around the whole driver-signing thing, as I've seen it done before - just not in MSI...At the moment, I've more or less given up on it, and have been forced to add instructions for how to *manually* disable driver signing to my release notes... Please, tell me there's a better solution!?!?Thanks,ShmaryaOn 7/27/06, Rob Mensching < [EMAIL PROTECTED]> wrote:To be perfectly clear, you are trying to bypass a feature that was put in place to protect users. I don't work with drivers and don't really know awhole lot about them, in general, but I don't think you'll get a lot ofsupport trying to hack around the protection. The whole thing sounds pretty sketchy to me.What product are you shipping? It really doesn't sound like something Iwant to install on my machine or have my Mom install.-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of ShmaryaRubensteinSent: Thursday, July 27, 2006 1:59 AM To: Stefan PavlikCc: wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Difx, Authenticode and Driver SigningUnfortunately, WHQL signing is not an option I know its not a good practice, but if there's any way to do it... :)-- Shmarya--- [EMAIL PROTECTED] - http://shmarya.netNUnit rocks! http://nunit.com - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [WiX-devs] GAC and call Custom Action
Rob,We're having issues with our mail server at work here so I don't know if you received this or not so I'm going to send to you again. I moved my email off my work account and only my personal mail so i know the messages get through. Sorry if you received it twice. Below is my answer to your question and also additional questions for you. Thanks for all your help John-Original Message-From: John HideySent: Thursday, July 27, 2006 11:06 AMTo: ' [EMAIL PROTECTED] '; wix-users@lists.sourceforge.net ; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action My custom action in install the Microsoft Enterprise Library into the gac and register all their Instrumentation classes. This is Microsoft code and they have the installers in the code so I assumed it would be easiest to just call them. Let me ask you this. I am not a c++ developer by any means. Can you point me to or give me some guidance on how to do this the right way. I would love to get this done right one time instead of wrong several times. ThanksJohn-Original Message-From: Rob Mensching [mailto: [EMAIL PROTECTED]]Sent: Thursday, July 27, 2006 11:01 AMTo: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right. The problem is that Assemblies going to the GAC aren't committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a "bad thing".My suggestion (which is rarely popular ) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway?From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of John HideySent: Wednesday, July 26, 2006 1:36 PMTo: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom ActionHere is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance.John -- John Hidey[EMAIL PROTECTED] -- John Hidey[EMAIL PROTECTED] - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fwd: FW: [WiX-devs] GAC and call Custom Action
Rob,We're having issues with our mail server at work here so I don't know if you received this or not so I'm going to send to you again. I moved my email off my work account and only my personal mail so i know the messages get through. Sorry if you received it twice. Below is my answer to your question and also additional questions for you. Thanks for all your helpJohn-Original Message-From: John HideySent: Thursday, July 27, 2006 11:06 AMTo: '[EMAIL PROTECTED] '; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action My custom action in install the Microsoft Enterprise Library into the gac and register all their Instrumentation classes. This is Microsoft code and they have the installers in the code so I assumed it would be easiest to just call them. Let me ask you this. I am not a c++ developer by any means. Can you point me to or give me some guidance on how to do this the right way. I would love to get this done right one time instead of wrong several times. ThanksJohn-Original Message-From: Rob Mensching [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 27, 2006 11:01 AMTo: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right. The problem is that Assemblies going to the GAC aren't committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a "bad thing".My suggestion (which is rarely popular ) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway?From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of John HideySent: Wednesday, July 26, 2006 1:36 PMTo: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: [WiX-devs] GAC and call Custom ActionHere is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance.John-- John Hidey[EMAIL PROTECTED] - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] GAC and call Custom Action
Yeah, that scenario just doesnt work right. The problem is that Assemblies going to the GAC arent committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, Ive never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions cant be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing. My suggestion (which is rarely popular ) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:36 PM To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isnt actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
To be perfectly clear, you are trying to bypass a feature that was put in place to protect users. I don't work with drivers and don't really know a whole lot about them, in general, but I don't think you'll get a lot of support trying to hack around the protection. The whole thing sounds pretty sketchy to me. What product are you shipping? It really doesn't sound like something I want to install on my machine or have my Mom install. - From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Thursday, July 27, 2006 1:59 AM To: Stefan Pavlik Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Difx, Authenticode and Driver Signing Unfortunately, WHQL signing is not an option I know its not a good practice, but if there's any way to do it... :) - 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/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
