[WiX-users] What exactly is SourceDir?
In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install to directory contained in registry path [SOLVED]
Thanks for your suggestions bob. The answer to most every MSI-related question is check a verbose log. A verbose log on MSI 3.x contains entries for every property change or deletion so you can see when MSI is setting it. I was doing that, but was obviously too tired to make sense of it. When I looked last night, it just wasn't setting the values; only using defaults. Not having a working install sample that I knew to work, it was difficult to know what a good log looked like. First, I try to read in the properties at the top of the file from the registry: Property Id=CEAPPMGRDIR Value=c:\defaultdir\ RegistrySearch Id=CEAPPMGRDIRreg Root=HKLM Type=directory Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE Name=c:\crud\crud\myapp.txt/RegistrySearch /Property The MSI doc is woefully inadequate when it comes to the types of registry searches but I can tell you with high certainty that it won't convert a file path to a directory. It's likely never setting your property, because it doesn't match what you've told it to look for. Starting again fresh today, I've tweaked it piece by piece, and come up with this: Property Id=CEAPPMGR RegistrySearch Id=CEAPPMGRCMD Root=HKLM Type=raw Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Property Id=CEAPPMGRDIR RegistrySearch Id=CEAPPMGRD Root=HKLM Type=file Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Strangely, the raw type reads the whole string (I was expecting extra characters on the front specifying the type of information contained, but on re-reading, I see regular strings aren't decorated), and the file type reads the path portion. If you use directory, nothing is read, as you suggested. Then to install files into the found location, use this fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=CEAPPMGRDIR Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.cab Source=prog.cab DiskId=1 /File File Id=ReleaseTxt Name=release.txt Source=.\release.txt / /Component /Directory /Directory /Directory /Directory as shown before. It took me awhile to realize that you could use other names that were previously set as the ID without specifying a name, as is the case in the use of CEAPPMGRDIR above. This raises a question about SouruceDir, which I've started another topic on. The other thing that puzzled me was the use of the name SourceDir above, which is required. What I don't understand is why the other folders are listed below this in the hierarchy. - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix to register COM+ - similar to regsvcs
You are installing a .NET assembly into GAC, but you are telling the COM+ CA's that it's a native module. Try replacing: ComPlusApplication ... Type=native DllPath=[#ComPlus_dll] With: ComPlusApplication ... Type=.net DllPathFromGAC=yes RegisterInCommit=yes TlbPath=[#MyTypelib] And see if that works. The problem with COM+ is that the DLL needs to be loaded in order to be registered, and anything that goes into GAC is not visible on disc until the commit phase of the install. That is why you are getting the file not found error below. Also you need to provide a typelib for your assembly. This can be extracted using the tlbexp.exe tool of the .NET SDK. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DEVAL SHAH Sent: Saturday, March 24, 2007 1:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using Wix to register COM+ - similar to regsvcs Hello, I have Serviced component which I want to register with Wix. I can register it with regsvcs but not able to do it with Wix. This is my config: Fragment Id='FragmentComPlus' DirectoryRef Id='ComPlusInstallDIR' Component Id=ComPlusDll Guid=some-id File Id=ComPlus_dll Name=Com LongName=COM+ Component DiskId=1 Vital=yes KeyPath=yes Assembly=.net src=SourceDir\abc\complus.dll / File Id='file2' Name='CommonDl' LongName=Common.dll' DiskId='1' Source='SourceDir\abc\Common.dll' Vital='yes'/ pca:ComPlusApplication Id=ComPlusApp Name=COM+ Application pca:ComPlusAssembly Id=ComPlusAssembly1 Type=native DllPath=[#ComPlus_dll] pca:ComPlusComponent Id=ABC.MyServicedComponent CLSID=some-guid / /pca:ComPlusAssembly /pca:ComPlusApplication /Component /DirectoryRef /Fragment This installation fails in between. The log shows following error: ComPlusInstallExecute: ErrorInfo: Name='C:\Program Files\MyComp', ErrorCode='-2146368476', MajorRef='C:\Program Files\MyComp', MinorRef='invalid' ComPlusInstallExecute: Error 0x80110401: Failed to install components ComPlusInstallExecute: Error 0x80110401: Failed to register native assembly ComPlusInstallExecute: Error 0x80110401: Failed to register assembly, key: ComPlusAssembly1 ComPlusInstallExecute: Error 0x80110401: Failed to register assemblies Any idea what is wrong? I want to achieve the same functionality as regsvcs. Thank you in advance Deval - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix for COM+ object
And you have double checked that the CLSID's you are providing for your ComPlusComponent elements are the same provided in you .idl file? You actually only have a single component in each module? Other than that I wonder if there could be anything about your modules being OCX'es but I doubt it. As far as I can remember they are just DLL's with a different extension... You shouldn't need anything besides what you have here as far as I can tell. The [#...] syntax is standard syntax to expand the target path of a file being installed. BTW, you don't need the RemoveFile tags in the below example. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Moni Chow Sent: Friday, March 16, 2007 9:26 AM To: 'Fredrik Grohn'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix for COM+ object Dear Fredrik, Sorry for my late reply. Here is the part of code I have: Directory Id=SystemFolder Name=System Component Id=CrcOcx DiskId=1 Guid=53E478B2-4A6A-458b-A00E-7CE54FC539E5 File Id=CrcOcx Name=CrcOcx LongName=CRC.ocx Source=crc.ocx KeyPath=yes Vital=yes / pca:ComPlusApplication Id=ComCrc Name=CRC COM Application pca:ComPlusAssembly Id=ComCrcAssembly Type=native DllPath=[#CrcOcx] pca:ComPlusComponent Id=ComCrc CLSID=3F11AD23-56FC-11D8-802D-00055D05CDC9 / /pca:ComPlusAssembly /pca:ComPlusApplication RemoveFile Id=RemoveCrc On=uninstall / /Component Component Id=MKFWOcx DiskId=1 Guid=77B72DAF-4583-46c5-AE7E-A4A0922D2E32 File Id=MKFWOcx Name=MKFWOcx LongName=MKFW.ocx Source=MKFW.ocx KeyPath=yes Vital=yes / pca:ComPlusApplication Id=ComMKFW Name=MKFW COM Application pca:ComPlusAssembly Id=ComMKFWAssembly Type=native DllPath=[#MKFWOcx] pca:ComPlusComponent Id=ComMKFW CLSID=74C9AB2E-13C1-40FA-B075-9B4015ED68BE / /pca:ComPlusAssembly /pca:ComPlusApplication RemoveFile Id=RemoveMKFW On=uninstall / /Component Component Id=MSWINSCKOcx DiskId=1 Guid=2900D6B4-02B0-43fe-A119-ED2617B08E3D NeverOverwrite=yes File Id=MSWINSCKOcx Name=MSWINOcx LongName=MSWINSCK.ocx Source=MSWINSCK.ocx KeyPath=yes Vital=yes / pca:ComPlusApplication Id=ComMSWINSCK Name=MSWINSCK COM Application pca:ComPlusAssembly Id=ComMSWINSCKAssembly Type=native DllPath=[#MSWINSCKOcx] pca:ComPlusComponent Id=ComMSWINSCK CLSID=248DD890-BB45-11CF-9ABC-0080C7E7B78D / /pca:ComPlusAssembly /pca:ComPlusApplication RemoveFile Id=RemoveMSWINSCK On=uninstall / /Component /Directory It seems that the installer build a new CLSID in registry which is different from the one specified in the script, so it cannot run the application, having error of Class not registered. Do you know why it happens and how to fix it? Is there any special meaning for the DllPath with symbol # that a specific value should be given? Are there any codes that should be included such that it will unregister the COM+ libraries and then remove it if no other programs use it? Thanks so much for your help! Regards, Moni From: Fredrik Grohn [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 1:12 AM To: 'Moni Chow'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix for COM+ object Nah, I don't think so. Is there anything in the log that indicates that something went wrong? Would you be able to share some of your WiX code? From: Moni Chow [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 3:40 AM To: 'Fredrik Grohn'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix for COM+ object Dear Fredrik, I have the same structure as you do in the code except Assembly=.net. This should not be the root cause right? Regards, Moni From: Fredrik Grohn [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 5:14 AM To: 'Moni Chow'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix for COM+ object Remember that if you DLL is native you currently have to list all components contained in the DLL under the ComPlusApplication tag as ComPlusComponent
Re: [WiX-users] What exactly is SourceDir?
The default value for TARGETDIR [1] is C:\ but tools like VS.NET setup and deployment projects add a type 51 CA (set property from formatted text) to set TARGETDIR to [ProgramFilesFolder][Manufacturer]\[ProductName]. Also TARGETDIR can be specified on the command line to specify where you want the application installed. So Windows Installer defaults TARGETDIR to C:\ (actually ROOTDRIVE property) if TARGETDIR was not specified by a certain point (CostFinalize) in the installation sequence. The WiX convention seems to be to set INSTALLDIR to the above path and leave TARGETDIR at its default. A VS.NET setup and deployment looks something like this in WiX: Directory Id=TARGETDIR Name=SourceDir Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory !-- Sets the TARGETDIR property to a path based on ProductName property-- CustomAction Id=SetTARGETDIR Property=TARGETDIR Value=[ProgramFilesFolder][Manufacturer]\[ProductName] Execute=firstSequence / InstallUISequence !-- Set TARGETDIR if it wasn't set on the command line -- Custom Action=SetTARGETDIR Before=CostFinalizeTARGETDIR=/Custom /InstallUISequence InstallExecuteSequence !-- Set TARGETDIR if it wasn't set on the command line -- Custom Action=SetTARGETDIR Before=CostFinalizeTARGETDIR=/Custom InstallExecuteSequence Here's some references... [1] TARGETDIR docs - http://msdn2.microsoft.com/en-us/library/aa372064.aspx [2] SourceDir docs - http://msdn2.microsoft.com/en-us/library/aa371857.aspx -Original Message- From: [EMAIL PROTECTED] on behalf of Anthony Wieser Sent: Sat 3/24/2007 3:01 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What exactly is SourceDir? In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What exactly is SourceDir?
You might read through this blog series of mine on my old blog: http://blogs.msdn.com/robmen/archive/2006/10/12/deciphering-the-msi-directory-table-part-6-standard-directories.aspx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Saturday, March 24, 2007 12:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What exactly is SourceDir? In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What exactly is SourceDir?
Note exactly accurate. ROOTDRIVE is defaulted to the drive with the most free space on the machine (unless you're doing an admin image... then it's something like the first writeable network drive). As you noted, TARGETDIR is defaulted to ROOTDRIVE. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnette, Bill Sent: Saturday, March 24, 2007 8:04 AM To: Anthony Wieser; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] What exactly is SourceDir? The default value for TARGETDIR [1] is C:\ but tools like VS.NET setup and deployment projects add a type 51 CA (set property from formatted text) to set TARGETDIR to [ProgramFilesFolder][Manufacturer]\[ProductName]. Also TARGETDIR can be specified on the command line to specify where you want the application installed. So Windows Installer defaults TARGETDIR to C:\ (actually ROOTDRIVE property) if TARGETDIR was not specified by a certain point (CostFinalize) in the installation sequence. The WiX convention seems to be to set INSTALLDIR to the above path and leave TARGETDIR at its default. A VS.NET setup and deployment looks something like this in WiX: Directory Id=TARGETDIR Name=SourceDir Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory !-- Sets the TARGETDIR property to a path based on ProductName property-- CustomAction Id=SetTARGETDIR Property=TARGETDIR Value=[ProgramFilesFolder][Manufacturer]\[ProductName] Execute=firstSequence / InstallUISequence !-- Set TARGETDIR if it wasn't set on the command line -- Custom Action=SetTARGETDIR Before=CostFinalizeTARGETDIR=/Custom /InstallUISequence InstallExecuteSequence !-- Set TARGETDIR if it wasn't set on the command line -- Custom Action=SetTARGETDIR Before=CostFinalizeTARGETDIR=/Custom InstallExecuteSequence Here's some references... [1] TARGETDIR docs - http://msdn2.microsoft.com/en-us/library/aa372064.aspx [2] SourceDir docs - http://msdn2.microsoft.com/en-us/library/aa371857.aspx -Original Message- From: [EMAIL PROTECTED] on behalf of Anthony Wieser Sent: Sat 3/24/2007 3:01 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What exactly is SourceDir? In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
The situation is clearly broken and it's up to Microsoft to fix it. John Vottero So, John, why don't you go complain to Microsoft and more specifically the Windows Installer team? I know there are a number of us on the mailing list that work for Microsoft and we really do try to help where possible but you have to understand that quite often customers (especially a group of them) get more attention than internal employees. Complaining here will educate those of us on the WiX toolset (I'm always happy to listen) and I try to roll up the major pain points I get here to the Windows Installer team. However, I still often end up being counted as one voice. If you want change then you need to go to the people that you believe need changing. We've been quite clear here that the goal of the WiX toolset is support everything the Windows Installer supports. Until we get the nod from the Windows Installer that managed code is an okay thing to do we really can't support it in the WiX toolset. Therefore, all we can do with you here is commiserate but that won't fix what you want fixed. - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
The situation is clearly broken and it's up to Microsoft to fix it. John Vottero So, John, why don't you go complain to Microsoft and more specifically the Windows Installer team? I know there are a number of us on the mailing list that work for Microsoft and we really do try to help where possible but you have to understand that quite often customers (especially a group of them) get more attention than internal employees. Ok, what's the best way to send my concerns to the Windows Installer team? I was searching for a way to contact the Windows Installer team and ran across this: http://blogs.msdn.com/heaths/archive/2007/03/14/introducing-windows-inst aller-powershell-extensions.aspx on Heath Stewart's blog. The part that made me laugh was: There is no installation package yet as I explore better alternatives to running installutil.exe or implementing similar functionality for use in an in-process custom action I hope Heath is part of the Windows Installer team! Complaining here will educate those of us on the WiX toolset (I'm always happy to listen) and I try to roll up the major pain points I get here to the Windows Installer team. However, I still often end up being counted as one voice. If you want change then you need to go to the people that you believe need changing. We've been quite clear here that the goal of the WiX toolset is support everything the Windows Installer supports. Until we get the nod from the Windows Installer that managed code is an okay thing to do we really can't support it in the WiX toolset. Therefore, all we can do with you here is commiserate but that won't fix what you want fixed. I understand the situation that WiX is in. - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
John Vottero wrote: The System.Configuration.Installer base class has virtual methods for Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can support Rollbacks? Yes, they *can*. The number that do is vanishingly small. Doing it right is hard, regardless of language. Half the time, they're not even close to necessary: The event log stuff in InstallUtil, for example, just writes registry keys. So you have CAs and managed CAs when a few rows in the Registry table get it for free. I don't know enough about Windows Installer to understand all the implications of managed CAs. What I do know is that there are many groups at Microsoft that are creating managed CAs to support their products and they aren't creating unmanaged CAs and they aren't documenting what their managed CAs actually do so ISV's are left stuck in the middle. We have to reverse engineer the Microsoft managed CAs so we can develop proper installers. The situation is clearly broken and it's up to Microsoft to fix it. Yes and in addition to Rob's suggestion of pinging the MSI team, I'll add: Ping the teams whose stuff you use. Let them know that blindly calling managed code via InstallUtil isn't good enough for you. Teams like the black-box approach because it gives them future flexibility (over, say, documenting the registry entries their IntallUtil CAs write). Tough. Let them know it. Document the stuff and WiX can handle them via extensions and, when necessary, CAs. -- 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
Why not the Windows Installer team blog? http://blogs.msdn.com/windows_installer_team. -Original Message- From: John Vottero [mailto:[EMAIL PROTECTED] Sent: Saturday, March 24, 2007 10:35 AM To: Rob Mensching; Bob Arnson; [EMAIL PROTECTED] Cc: WiX-users Subject: RE: [WiX-users] C# .dll The situation is clearly broken and it's up to Microsoft to fix it. John Vottero So, John, why don't you go complain to Microsoft and more specifically the Windows Installer team? I know there are a number of us on the mailing list that work for Microsoft and we really do try to help where possible but you have to understand that quite often customers (especially a group of them) get more attention than internal employees. Ok, what's the best way to send my concerns to the Windows Installer team? - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
Bob Arnson wrote: John Vottero wrote: The System.Configuration.Installer base class has virtual methods for Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can support Rollbacks? Yes, they can. The number that do is vanishingly small. Doing it right is hard, regardless of language. Half the time, they're not even close to necessary: The event log stuff in InstallUtil, for example, just writes registry keys. So you have CAs and managed CAs when a few rows in the Registry table get it for free. I agree that writing a good CA is hard but, I'll bet it's easier in C# than it is in C. I also agree that eliminating a CA is the best way to make it robust. The PowerShell stuff is also just a bunch of registry entries (I think, it's not documented). I don't know enough about Windows Installer to understand all the implications of managed CAs. What I do know is that there are many groups at Microsoft that are creating managed CAs to support their products and they aren't creating unmanaged CAs and they aren't documenting what their managed CAs actually do so ISV's are left stuck in the middle. We have to reverse engineer the Microsoft managed CAs so we can develop proper installers. The situation is clearly broken and it's up to Microsoft to fix it. Yes and in addition to Rob's suggestion of pinging the MSI team, I'll add: Ping the teams whose stuff you use. Let them know that blindly calling managed code via InstallUtil isn't good enough for you. Teams like the black-box approach because it gives them future flexibility (over, say, documenting the registry entries their IntallUtil CAs write). Tough. Let them know it. Document the stuff and WiX can handle them via extensions and, when necessary, CAs. I always try to register my concerns with the teams producing the managed installers. The PowerShell team has said that they would document what their managed installer does but, I haven't seen the documentation yet. The future flexibility angle is my biggest worry. One of these days, some team is going to completely scramble what their managed installer does and they'll think that they aren't breaking anything. If they really want that future flexibility, they have to put some pressure on the Windows Installer team to support managed Installers. - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registry keys and component rules
This is really more of a Windows Installer question than a WiX questions but, I'm not getting any responses in the msi newsgroup. The component rules make it pretty clear that you can't add or remove a registry key without creating a new component. Do they really mean registry key? Can I add or remove registry *entries* without breaking the component rules? - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
John Vottero wrote: I agree that writing a good CA is hard but, I'll bet it's easier in C# than it is in C. The guts -- whatever the CA actually needs to do -- can be. But that's unlikely to encourage table-driven, state-driven CAs. I also agree that eliminating a CA is the best way to make it robust. Which is why I want to see more teams documenting what they need, rather than just providing black boxes. Even the best-written software product can have crud for black box deployment -- too many folks think it's the job of contractors or interns or newbies to handle that setup stuff. The future flexibility angle is my biggest worry. One of these days, some team is going to completely scramble what their managed installer does and they'll think that they aren't breaking anything. If they really want that future flexibility, they have to put some pressure on the Windows Installer team to support managed Installers. That's providing free band-aids in the box rather than fixing the wound in the first place. What are the chances a team that ignores built-in MSI functionality is going to also write good table/state-driven CAs -- managed or not? Making it easier to ship shoddy CAs doesn't help developers make robust setups. And that's the goal, right? There are levels to robustness: - Built-in MSI functionality (e.g., Registry table). - Common table/state-driven CAs (e.g., WiX's XmlConfig). - Custom table/state-driven CAs (e.g., MSHelp 2.x). - Custom CAs that are state-driven but with embedded data (e.g., most InstallUtil stuff). - Custom CAs that are neither state-driven nor table-driven (e.g., most self-reg). The further down the list, the less likely you have good support for rollback, patching, modify, repair, or even uninstall. The part that's most frustrating is that the higher on the table, the easier it is -- less work to implement and test -- than further down the list. So yes, short answer: I want the MSI team to focus on more important features and product teams to do the right 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry keys and component rules
John Vottero wrote: The component rules make it pretty clear that you can't add or remove a registry key without creating a new component. Do they really mean registry key? Can I add or remove registry *entries* without breaking the component rules? From the MSI perspective, registry keys and registry values are both resources like files. Both keys and values are rows in the Registry table. -- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
IMO, it is very easy to blame it on Windows Installer team without actually knowing/considering the work and requests they get from so many different teams within Microsoft, let alone third parties and without considering/knowing the limitations they face in implementing features (be it business or technical). I am sure they focus on customers' needs. But do we as customers request what we need from Windows Installer team? I think one of the problems is that we are too busy to get the installer done right and to meet our own goals and in doing so when we encounter issues or limitations, not all of us send out feature requests to Windows Installer team, we simply find a workaround using Custom Actions and then forget about it. I am surprised to see that Windows Installer is now 4.0 and if you go through the features added since 1.0 came out (back in 1997?) there are not too many features added in 10 years and 4 product cycles. Probably more bug fixes than features, I might be wrong, but I think if we would have requested more features, we would have gotten a lot better and versatile Windows Installer than what it is today. So part of the blame goes on us (setup developers) as well. The limitations of Windows Installer can be overcome by having custom actions, but custom actions cause more failures than anything else (at least from my experience), so people see custom actions as workarounds. If Windows Installer team ignores feature requests just because they think that customers can write Custom Actions to get what they want, that is wrong. So let's decide that we will always send a feature request to Windows Installer team every time we encounter limitations. In fact we can do what we just did, start a thread (not sure if it is appropriate to do this in wix users list, but should be done somewhere, Windows Installer blog, or some other place)and if people agree then we can send even more requests for the same feature, that will definitely get their attention. For example, in the case of managed custom actions, if we send out 10+ requests from different people/groups for the same feature, how can they ignore so many customers? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Saturday, March 24, 2007 11:54 AM To: Bob Arnson Cc: [EMAIL PROTECTED]; WiX-users Subject: Re: [WiX-users] C# .dll Bob Arnson wrote: John Vottero wrote: The System.Configuration.Installer base class has virtual methods for Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can support Rollbacks? Yes, they can. The number that do is vanishingly small. Doing it right is hard, regardless of language. Half the time, they're not even close to necessary: The event log stuff in InstallUtil, for example, just writes registry keys. So you have CAs and managed CAs when a few rows in the Registry table get it for free. I agree that writing a good CA is hard but, I'll bet it's easier in C# than it is in C. I also agree that eliminating a CA is the best way to make it robust. The PowerShell stuff is also just a bunch of registry entries (I think, it's not documented). I don't know enough about Windows Installer to understand all the implications of managed CAs. What I do know is that there are many groups at Microsoft that are creating managed CAs to support their products and they aren't creating unmanaged CAs and they aren't documenting what their managed CAs actually do so ISV's are left stuck in the middle. We have to reverse engineer the Microsoft managed CAs so we can develop proper installers. The situation is clearly broken and it's up to Microsoft to fix it. Yes and in addition to Rob's suggestion of pinging the MSI team, I'll add: Ping the teams whose stuff you use. Let them know that blindly calling managed code via InstallUtil isn't good enough for you. Teams like the black-box approach because it gives them future flexibility (over, say, documenting the registry entries their IntallUtil CAs write). Tough. Let them know it. Document the stuff and WiX can handle them via extensions and, when necessary, CAs. I always try to register my concerns with the teams producing the managed installers. The PowerShell team has said that they would document what their managed installer does but, I haven't seen the documentation yet. The future flexibility angle is my biggest worry. One of these days, some team is going to completely scramble what their managed installer does and they'll think that they aren't breaking anything. If they really want that future flexibility, they have to put some pressure on the Windows Installer team to support managed Installers. - 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
Re: [WiX-users] C# .dll
What I don't understand is why people are so eager to build managed custom actions in the first place. I don't know for sure, but I don't think there are quite as many threads over at the device driver lists about managed device drivers... The only reason to use managed code from inside a custom action is because you need to configure something that does not have a native configuration interface. But that is really a problem with that product in that case - not with the Windows Installer. The biggest problem with managed custom actions I think is that prior to Vista the CLR is not a native component of the operating system. The second biggest problem I think is that once one version of the CLR has been loaded into a process it permanently pollutes that process and even if it can be unloaded it can never be loaded back in again, making it impossible to load a different version at a later point. It is a complex thing to implement and compared to other things probably not a very high priority. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danish Waheed Sent: Saturday, March 24, 2007 9:15 PM To: 'John Vottero'; 'Bob Arnson' Cc: [EMAIL PROTECTED]; 'WiX-users' Subject: Re: [WiX-users] C# .dll IMO, it is very easy to blame it on Windows Installer team without actually knowing/considering the work and requests they get from so many different teams within Microsoft, let alone third parties and without considering/knowing the limitations they face in implementing features (be it business or technical). I am sure they focus on customers' needs. But do we as customers request what we need from Windows Installer team? I think one of the problems is that we are too busy to get the installer done right and to meet our own goals and in doing so when we encounter issues or limitations, not all of us send out feature requests to Windows Installer team, we simply find a workaround using Custom Actions and then forget about it. I am surprised to see that Windows Installer is now 4.0 and if you go through the features added since 1.0 came out (back in 1997?) there are not too many features added in 10 years and 4 product cycles. Probably more bug fixes than features, I might be wrong, but I think if we would have requested more features, we would have gotten a lot better and versatile Windows Installer than what it is today. So part of the blame goes on us (setup developers) as well. The limitations of Windows Installer can be overcome by having custom actions, but custom actions cause more failures than anything else (at least from my experience), so people see custom actions as workarounds. If Windows Installer team ignores feature requests just because they think that customers can write Custom Actions to get what they want, that is wrong. So let's decide that we will always send a feature request to Windows Installer team every time we encounter limitations. In fact we can do what we just did, start a thread (not sure if it is appropriate to do this in wix users list, but should be done somewhere, Windows Installer blog, or some other place)and if people agree then we can send even more requests for the same feature, that will definitely get their attention. For example, in the case of managed custom actions, if we send out 10+ requests from different people/groups for the same feature, how can they ignore so many customers? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Saturday, March 24, 2007 11:54 AM To: Bob Arnson Cc: [EMAIL PROTECTED]; WiX-users Subject: Re: [WiX-users] C# .dll Bob Arnson wrote: John Vottero wrote: The System.Configuration.Installer base class has virtual methods for Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can support Rollbacks? Yes, they can. The number that do is vanishingly small. Doing it right is hard, regardless of language. Half the time, they're not even close to necessary: The event log stuff in InstallUtil, for example, just writes registry keys. So you have CAs and managed CAs when a few rows in the Registry table get it for free. I agree that writing a good CA is hard but, I'll bet it's easier in C# than it is in C. I also agree that eliminating a CA is the best way to make it robust. The PowerShell stuff is also just a bunch of registry entries (I think, it's not documented). I don't know enough about Windows Installer to understand all the implications of managed CAs. What I do know is that there are many groups at Microsoft that are creating managed CAs to support their products and they aren't creating unmanaged CAs and they aren't documenting what their managed CAs actually do so ISV's are left stuck in the middle. We have to reverse engineer the Microsoft managed CAs so we can develop proper installers. The situation is clearly broken and it's up to Microsoft to fix it. Yes and in addition to Rob's suggestion of
[WiX-users] C# .dll
On Sat, 24 Mar 2007 20:38:16 +, Fredrik Grohn wrote: First to all, please, clear out all the participants from the To: and CC: lines and keep the discussion on the list itself. I guess we all monitor it regularly so it's really not beneficial to receive every posting twice, both directly and from the list. Fredrik, What I dont understand is why people are so eager to build managed custom actions in the first place. That's what bothers me, too. If somebody really wanting to write a managed (or unmanaged) custom action could tell us why he or she needs it in the first place. I completely agree with Richard Foster, me, too: the only real custom action I ever wrote was to check the product key entered by the user. I have a suspicion that the need for custom actions stem from sloppy programming of the application to be installed rather than any real, legitimate need for something WI can't solve. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
On Sat, 24 Mar 2007 20:38:16 +, Fredrik Grohn wrote: First to all, please, clear out all the participants from the To: and CC: lines and keep the discussion on the list itself. I guess we all monitor it regularly so it's really not beneficial to receive every posting twice, both directly and from the list. Fredrik, What I don't understand is why people are so eager to build managed custom actions in the first place. That's what bothers me, too. If somebody really wanting to write a managed (or unmanaged) custom action could tell us why he or she needs it in the first place. I completely agree with Richard Foster, me, too: the only real custom action I ever wrote was to check the product key entered by the user. I have a suspicion that the need for custom actions stem from sloppy programming of the application to be installed rather than any real, legitimate need for something WI can't solve. The ONLY reason that I have for using a managed custom action is that *Microsoft* is telling me to. Last year, I went to an ISV training course presented by Microsoft at Microsoft and the MMC and PowerShell teams both showed us how to create managed Installer based classes to install our MMC and PowerShell snapins. When I asked them about this problem, they didn't seem to understand the issue. More and more managed Installer based classes are being released by Microsoft and in most cases, they aren't documenting what the installers do. - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
That is why I said without knowing/considering J As far as why people need it, it probably make things easier for people using managed code in their product. Since I don't use managed custom actions, I cannot justify it, but I think there are a lot of people out there who would benefit from it. Whether it is feasible or not, that is another question. Questions below are for CLR/Windows team perhaps, If the problem is in loading and unloading CLR, why it was never fixed in three product cycles of CLR and two product cycles of OS (we are talking about almost 10 years of OS work and 6+ years of CLR, right?)? I and perhaps thousands of devs out there don't care for Windows Sidebar in Vista, but would like to see a more stable, powerful, smart, and tightly integrated CLR and Windows Installer in Vista. Considering that Windows Installer, CLR and Windows are from same company and are tied together at OS level now in Vista, would not it make sense to overcome some of these limitations? I think priority is determined by customer and business needs as well technical limitations and I am not saying that support for Managed Custom Actions should or shouldn't be a high priority, but I don't think Windows Installer has evolved as much as it should have been considering its integration with the OS and part of the reason is lack of demand for new features from customers (partially because of Custom Action workarounds). Oh well, I will let Managed Custom Action fans speakJ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fredrik Grohn Sent: Saturday, March 24, 2007 1:38 PM To: Danish Waheed; 'John Vottero'; 'Bob Arnson' Cc: [EMAIL PROTECTED]; 'WiX-users' Subject: Re: [WiX-users] C# .dll What I don't understand is why people are so eager to build managed custom actions in the first place. I don't know for sure, but I don't think there are quite as many threads over at the device driver lists about managed device drivers. The only reason to use managed code from inside a custom action is because you need to configure something that does not have a native configuration interface. But that is really a problem with that product in that case - not with the Windows Installer. The biggest problem with managed custom actions I think is that prior to Vista the CLR is not a native component of the operating system. The second biggest problem I think is that once one version of the CLR has been loaded into a process it permanently pollutes that process and even if it can be unloaded it can never be loaded back in again, making it impossible to load a different version at a later point. It is a complex thing to implement and compared to other things probably not a very high priority. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danish Waheed Sent: Saturday, March 24, 2007 9:15 PM To: 'John Vottero'; 'Bob Arnson' Cc: [EMAIL PROTECTED]; 'WiX-users' Subject: Re: [WiX-users] C# .dll IMO, it is very easy to blame it on Windows Installer team without actually knowing/considering the work and requests they get from so many different teams within Microsoft, let alone third parties and without considering/knowing the limitations they face in implementing features (be it business or technical). I am sure they focus on customers' needs. But do we as customers request what we need from Windows Installer team? I think one of the problems is that we are too busy to get the installer done right and to meet our own goals and in doing so when we encounter issues or limitations, not all of us send out feature requests to Windows Installer team, we simply find a workaround using Custom Actions and then forget about it. I am surprised to see that Windows Installer is now 4.0 and if you go through the features added since 1.0 came out (back in 1997?) there are not too many features added in 10 years and 4 product cycles. Probably more bug fixes than features, I might be wrong, but I think if we would have requested more features, we would have gotten a lot better and versatile Windows Installer than what it is today. So part of the blame goes on us (setup developers) as well. The limitations of Windows Installer can be overcome by having custom actions, but custom actions cause more failures than anything else (at least from my experience), so people see custom actions as workarounds. If Windows Installer team ignores feature requests just because they think that customers can write Custom Actions to get what they want, that is wrong. So let's decide that we will always send a feature request to Windows Installer team every time we encounter limitations. In fact we can do what we just did, start a thread (not sure if it is appropriate to do this in wix users list, but should be done somewhere, Windows Installer blog, or some other place)and if people agree then we can send even more requests for the same feature, that will definitely get their attention. For
Re: [WiX-users] Registry keys and component rules
Do you mean the Name of the Registry element? If so, no you can't remove those either. The full path for a registry key is Root\Key\Name. The only thing you can do is change the value. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Saturday, March 24, 2007 12:28 PM To: WiX-users Subject: [WiX-users] Registry keys and component rules This is really more of a Windows Installer question than a WiX questions but, I'm not getting any responses in the msi newsgroup. The component rules make it pretty clear that you can't add or remove a registry key without creating a new component. Do they really mean registry key? Can I add or remove registry *entries* without breaking the component rules? - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Medhelp 758
- 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
