Re: [WiX-users] Creating SqlDatabase with/without Windows Authentification
Here my solution:
util:User Id=SQLUser Name=[SQLUSERNAME]
Password=[SQLUSERPASSWORD] /
...
!--database authentification, SQLUSER will be used --
!-- SQLUSERNAME and SQLUSERPASSWORD will be entered in a customized
dialog --
Component Id=CreateDBUser DiskId=1 Guid=YOURGUID
sql:SqlDatabase Id=dbUser Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no User=SQLUser
sql:SqlScript Id=CreateTablesSqlScriptUser ContinueOnError=no
ExecuteOnInstall=yes ExecuteOnReinstall=no Sequence=002
BinaryKey=CreateTablesBin User=SQLUser /
/sql:SqlDatabase
ConditionWIN_AUTH_DB=False/Condition
/Component
!-- Windows authentification, without User attribute --
Component Id=CreateDBWindows DiskId=1 Guid=YOURGUID
sql:SqlDatabase Id=dbWindows Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no
sql:SqlScript Id=CreateTablesSqlScriptWindows
ContinueOnError=no ExecuteOnInstall=yes ExecuteOnReinstall=no
Sequence=002 BinaryKey=CreateTablesBin /
/sql:SqlDatabase
ConditionWIN_AUTH_DB=True/Condition
/Component
...
!-- this script will be used for both above --
Binary Id=CreateTablesBin SourceFile=Create XCB
Tables_Views_StoredProcedures.sql
/Binary
...
!-- the property WIN_AUTH_DB will be set using a radio button
control in the same customized dialog
as username and password --
!-- the property must be global, eg. its name uses capitals only
--
Control Id=SecurityButtons1 Type=RadioButtonGroup X=90
Y=142 Width=197 Height=30 Property=WIN_AUTH_DB
/Control
...
RadioButtonGroup Property=WIN_AUTH_DB
RadioButton Text={\DlgFont8}amp;Integrated Security (Windows
authentification) Value=True X=0 Y=0 Width=206 Height=12 /
RadioButton Text={\DlgFont8}amp;User Name and Password
Value=False X=0 Y=15 Width=206 Height=15 /
/RadioButtonGroup
Dhaval Patel-4 wrote:
I'd be interested in seeing your solution, Peter. Can you post your
solution
on the Wix-users list for future reference? I feel this shouldn't be hard,
but if you already have it, then why reinvent the wheel!
Thanks in advance.
On 3/13/07, pobox77 [EMAIL PROTECTED] wrote:
Thanks Dana,
I've just found the same solution about an hour ago.
Just a note for people having similar problem:
The property used by the radio button and in the condition must be a
global
property
(e.g. the name of it should only have capitals) otherwise it doesn't
work.
Peter
Dana Gutride wrote:
This is not possible within the sql database tag right now. There is a
bug/feature request in for this exact functionality, but as far as I
can
tell, it hasn't been added yet. The only way to do this is to have two
sqldatabase tags in separate components and then add conditions for the
components based on the radio button's property.
Dana
On 3/13/07, pobox77 [EMAIL PROTECTED] wrote:
Sorry, the snippet was wrong formatted.
pobox77 wrote:
Hi,
I would like to create a SqlDatabase either with Username+Password
or
with
Windows authentification. I am using a radio button in a customize
dialog.
If not Windows auth. is selected, the user can enter a username and
a
password.
How should I set the SqlDatabase component to do it? I mean, if
Windows
auth. the User=SQLUser should not be used.
Snippet:
Component Id=CreateDB DiskId=1
Guid=----
sql:SqlDatabase Id=MyDb Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no User=SQLUser
sql:SqlScript Id=CreateTablesSqlScript
ContinueOnError=no
ExecuteOnInstall=yes ExecuteOnReinstall=no Sequence=002
BinaryKey=CreateTablesBin User=SQLUser /
/sql:SqlDatabase
/Component
Feature Id=SqlDb Title=Create Database
Description=Installing
database. Please ensure that the SQL Server is running on the target
server. AllowAdvertise=yes TypicalDefault=install
Display=expand
Level=1
ComponentRef Id=CreateDB /
/Feature
Thanks in advance,
Peter
--
View this message in context:
http://www.nabble.com/Creating-SqlDatabase-with-without-Windows-Authentification-tf3394305.html#a9449474
Sent from the wix-users mailing list archive at Nabble.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.phpp=sourceforgeCID=DEVDEV
Re: [WiX-users] Set All Users desktop
Mike Dimmick wrote: Well, unless running an elevated advertised installation, of course. I’m coming to the conclusion that that’s what per-user installs are for. Which, by the way, are actually quite horrible thing at least in managed environments. Uninstalling, updating and patching have to be made by the user who installed the program (with elevated priviledges, of course.) User could log in, install a program then log out and after that there is no clean way to uninstall the program from machine without the very same user logging back in. And please all remember that ALLUSERS is a public property, so it can and will be easily overridden. It's much more important to make your msi's behave well in all possible installation scenarios than try to fiddle with Desktop Icons, All Users, ALLUSERS etc. to make the installation perfect for local Administrator. Tao of the Windows Installer, Part 5 has good points: http://blogs.msdn.com/windows_installer_team/archive/2006/07/28/681358.aspx -- Mikko Järvinen University of Turku, Computing Centre - 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] : Installing ETW MOF files
Nothing exists today. It's been on the list of things that would be nice to have someone provide to the WiX toolset but no volunteer has done so yet. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Dar Ziv Sent: Thursday, March 15, 2007 10:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: : Installing ETW MOF files From: Ron Dar Ziv Sent: Thursday, March 15, 2007 10:51 PM To: Windows Installer XML Cc: Sukhdeep Sodhi Subject: : Installing ETW MOF files As part of our setup process we have to register ETW events specified in a MOF file, and had a couple of questions about this. 1. Are there any standard actions for registering a mof file using Wix? 2. Is it necessary to delete the events during un-install, especially since it should be fairly benign to have unused events lying around? Please add me to replies as I am not a member of this alias Thanks, Ron D. - 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] Consensus about CRT/MCF merge modules?
Agreed. However, based on early reports I'm not sure that pushing patches into WinSxS is really working due to the complexity that is the CustomActions to work around bugs in WinXP. The ideas behind Fusion are interesting but the complexity of the system has made it difficult to verify and for users to truly understand it. Personally, I prefer a model where a patch to a shared binary has the ability to update that binary everywhere (not that I can get anyone in Microsoft to agree with me, so maybe I'm just confused smile/). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, March 16, 2007 12:56 PM To: Rob Mensching; 'Chris Bardon'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? However, with static linking you have the servicing problem - if there's a security issue in the CRT (not unknown) or in MFC, you will have to rebuild your application to pick up the fix, then rerelease your application. By contrast, if using the WinSxS versions, Microsoft can ship an update directly to end-users (either as an updated assembly with the same version number, but different file version number, or as an additional assembly with a newer version number plus a policy binding). I have to admit looking at how the VS2005 CRT merge modules work and being a bit confused as to why they're configured to do something different on Vista (not just using MsiAssembly/MsiAssemblyName tables) especially as they were released over a year before Vista was. Using a private copy of the DLLs in your application directory is also a possibility but I don't think this is recommended (or even permitted?) for a final distribution. It still has the servicing problem but not the problem of having to rebuild the application or having the large binaries. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 16 March 2007 16:35 To: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? I'm not quite yet ready to make this a recommendation but I'm currently leaning towards statically linking the libraries directly. I'm seeing hints that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some seriously bad repercussions when it comes to patching and some possibly strange behavior on Vista. It's a research project I'm doing slowly... For the WiX toolset, we statically link to the CRT (MFC, haven't done that since I wrote Orca grin/) to minimize our dependencies on the machine. That makes the binaries a bit bigger but it is worth it to not have to worry about Is the WinSxS store updated at X point in time in my install? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, March 16, 2007 9:20 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Consensus about CRT/MCF merge modules? Looking through the archives, there appear to be a couple of ways to include things like the CRT and MFC redistributables in an installer. Some have advocated including the DLLs directly, which seems to go against the concept of having a redistributable MSM to link against. I tried building with the Microsoft CRT msm that comes with VS 2005, and got a long list of warnings from light. Is there a recommended method for dealing with these kinds of dependencies? Chris - 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] Inserting string in REG_MULTI_SZ key
You'll probably need a CustomAction. MULTI_SZ strings are icky. Personally, I'd recommend designing them out of your system as possible. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hovhannes Nurijanyan Sent: Saturday, March 17, 2007 2:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Inserting string in REG_MULTI_SZ key Hi All, I am new to wix, and I am getting some problems. I want to modify a multi string registry value to insert a string right after another string. Something like this: STRING_1 STRING_2 STRING_3 And I want it to be changed to: STRING_1 STRING_2 MY_STRING STRING_3 Is it possible to do using wix's abilities, or I'll have to write a script to parse the string and modify it? Thanks for help, Hovik - 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
What you mean by But making this functionality available would open all kinds of doors for folks like me? From: Dhaval Patel [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 11:15 PM To: Rob Mensching Cc: Levi Wilson; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll I guess, I see your point, Rob. But making this functionality available would open all kinds of doors for folks like me - I get to govern 'what, how, and when' my clients install currently; our company is a 90% MS shop, and most of our server deployments have .NET installed just for that reason alone. Of course, this may mean more issues for you :) On 3/16/07, Rob Mensching [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: More importantly, the Windows Installer doesn't support it today. There are actually neat problems you can introduce by loading the .NET Framework into the Windows Installer process. From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Levi Wilson Sent: Friday, March 16, 2007 10:40 AM To: Dhaval Patel Cc: wix-users@lists.sourceforge.net mailto:wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll I don't know for certain, but my guess would be that there's no guarantee that the .NET Framework has been installed on the client. On 3/16/07, Dhaval Patel [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Will WIX 3.0 be adding the capability to call C# .dll files? If not, WHY? :) - 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.netmailto: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
I haven't blogged it. This one requires more research that my recent avoid COM advertisement entry because I haven't lived it closely. I got enough reports of trickiness with managed CustomActions to just stay away. The root issue comes down to having the wrong version of the .NET Framework loaded. For example, let's say you have a 1.1 CustomAction but need to install a 2.0 Framework assembly to the GAC. My understanding was that the easy/obvious way to use the 1.1 CustomAction caused the 1.1. Framework to be loaded and that caused the 2.0 Framework install to fail later (because the 1.1. Framework won't understand it). Again, the details are fuzzy because I haven't stepped through the debugger on this issue myself. Basically, it comes down to the fact that the Windows Installer team needs to look at what managed CustomActions mean and do the right thing when looking at the complete picture. They know things about the all the different ways the Windows Installer gets invoked that you and I would struggle to think of. For example, what happens if you had a Shell Extension written in managed code then did faulted in an MSI via Extension advertisement? Do all the correct .NET Frameworks get loaded? Are you going to test it? smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Friday, March 16, 2007 11:43 PM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Hi Rob, Would you care to elaborate on this part a bit? If you already blogged it, I apologize. I've followed the evolution of this issue for a while now and I am always curious to learn more about it. To my knowledge, I don't remember you or anyone else discussing any specific issues regarding loaded the CLR into the installer process. I'm definitely of the opinion that these things are best avoided for now due to the lack of support for it at the WI level. On the other hand, I also believe it is just a matter of time before this needs to happen in a fully supported way. Basically, I'm trying to understand what the solution might look like in order to overcome some of the more subtle issues. What's so neat? :) Thanks! Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Levi Wilson [EMAIL PROTECTED]; Dhaval Patel [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Friday, March 16, 2007 12:43 PM Subject: Re: [WiX-users] C# .dll More importantly, the Windows Installer doesn't support it today. There are actually neat problems you can introduce by loading the .NET Framework into the Windows Installer process. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Friday, March 16, 2007 10:40 AM To: Dhaval Patel Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll I don't know for certain, but my guess would be that there's no guarantee that the .NET Framework has been installed on the client. On 3/16/07, Dhaval Patel [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Will WIX 3.0 be adding the capability to call C# .dll files? If not, WHY? :) - 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.netmailto: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 - 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
[WiX-users] 8.3 folder paths
Hi! Now, that WiX 3.0 supports the auto-generation of 8.3-compliant file and folder names, is there any way to retrieve the short names for further usage, e.g. in a RegistryValue statement? Or do I still have to insert a custom action after 'InstallFiles' to get the short path from the file or folder itself? Thanks, Daniel - 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] 8.3 folder paths
You could always just use [!FileId] to get the short name of a file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Kopp Sent: Monday, March 19, 2007 6:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] 8.3 folder paths Hi! Now, that WiX 3.0 supports the auto-generation of 8.3-compliant file and folder names, is there any way to retrieve the short names for further usage, e.g. in a RegistryValue statement? Or do I still have to insert a custom action after 'InstallFiles' to get the short path from the file or folder itself? Thanks, Daniel - 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] Consensus about CRT/MCF merge modules?
Well, for the apps I'm building installers for, we've already decided against static linking, so we need to deploy the DLLs somehow. In the past, we've just included the merge modules using installshield, which I believe deploys the DLLs to the system32 directory, but I've also tested with including a private copy of the DLLs, and this also appears to work. I'm not sure if this is a permitted option though. When installing a merge module, is there a way to specify the module's install directory? For example, if I want to install the CRT MSM from VS 2005, I can put something like this in: Merge Id=crt.B22E6F9A-D396-4F96-84D9-A822C63B9994 Language=1033 DiskId=1 SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm/ Since this is under a directory tag though, I don't know where it'll install the files. The module default should be the system32 directory, shouldn't it? From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 8:44 AM To: Mike Dimmick; Chris Bardon; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Consensus about CRT/MCF merge modules? Agreed. However, based on early reports I'm not sure that pushing patches into WinSxS is really working due to the complexity that is the CustomActions to work around bugs in WinXP. The ideas behind Fusion are interesting but the complexity of the system has made it difficult to verify and for users to truly understand it. Personally, I prefer a model where a patch to a shared binary has the ability to update that binary everywhere (not that I can get anyone in Microsoft to agree with me, so maybe I'm just confused smile/). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, March 16, 2007 12:56 PM To: Rob Mensching; 'Chris Bardon'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? However, with static linking you have the servicing problem - if there's a security issue in the CRT (not unknown) or in MFC, you will have to rebuild your application to pick up the fix, then rerelease your application. By contrast, if using the WinSxS versions, Microsoft can ship an update directly to end-users (either as an updated assembly with the same version number, but different file version number, or as an additional assembly with a newer version number plus a policy binding). I have to admit looking at how the VS2005 CRT merge modules work and being a bit confused as to why they're configured to do something different on Vista (not just using MsiAssembly/MsiAssemblyName tables) especially as they were released over a year before Vista was. Using a private copy of the DLLs in your application directory is also a possibility but I don't think this is recommended (or even permitted?) for a final distribution. It still has the servicing problem but not the problem of having to rebuild the application or having the large binaries. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 16 March 2007 16:35 To: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? I'm not quite yet ready to make this a recommendation but I'm currently leaning towards statically linking the libraries directly. I'm seeing hints that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some seriously bad repercussions when it comes to patching and some possibly strange behavior on Vista. It's a research project I'm doing slowly... For the WiX toolset, we statically link to the CRT (MFC, haven't done that since I wrote Orca grin/) to minimize our dependencies on the machine. That makes the binaries a bit bigger but it is worth it to not have to worry about Is the WinSxS store updated at X point in time in my install? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, March 16, 2007 9:20 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Consensus about CRT/MCF merge modules? Looking through the archives, there appear to be a couple of ways to include things like the CRT and MFC redistributables in an installer. Some have advocated including the DLLs directly, which seems to go against the concept of having a redistributable MSM to link against. I tried building with the Microsoft CRT msm that comes with VS 2005, and got a long list of warnings from light. Is there a recommended method for dealing with these kinds of dependencies? Chris - 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
[WiX-users] Final dialog and WIXUI_INSTALLDIR
Fellow WiX users... I'm using the WIXUI_INSTALLDIR dialog in order to pick a directory during installation. However, I want to add a single dialog to the end of the installation process (something with a checkbox that says 'Start the product now'). Is there a simple way to do this? Does anybody have an example? Thanks! Bob Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html- 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] votive and iisextension
Hi Bob, sorry for the delayed response to your answer, the spam filter grabbed your reply and just now let me have it. I have specified the WixIISExtension like this: Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension; Actually, it was done using WixCop to convert from version 2. Is there some place else I need to specify this extension? I am getting the error (copied below) when trying to build within VS2005. Thanks Shane Sawyer _ From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 17, 2007 10:48 AM To: Sawyer, Shane Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] votive and iisextension Sawyer, Shane wrote: Does Votive support building a wxs file with the iisextension? I am getting an error: The Component element contains an unhandled extension element 'iis:WebVirtualDir'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/IIsExtension http://schemas.microsoft.com/wix/IIsExtension ' namespace has been provided. You need to specify WixIIsExtension to use the IIS authoring and CAs. -- sig://boB http://bobs.org http://bobs.org - The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. - 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] ConfigureIIs skipping virtual directory
I have a situation where ConfigureIIs does not seem to be creating a Virtual Directory that I expect it to. It only happens when I am installing to a SharePoint web site that has another custom application installed to it as well. Can anyone offer any debugging tips on how to see what ConfigureIIs is doing, and why it might not be creating the virtual directory in this case? Thanks! -Tina - 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] Tallow and French
I'm having issues running tallow when files it is mapping have French characters in the path name. Several PDF files have accented A's and E's, which show up file in command line, but are simply gone in the tallow output file. Here are the file names: Tallow: '8 TOUS LES UTILISATEURS - Comment voir les cours et confrences auxquels j'ai assist.pdf' Real Filename: '8 TOUS LES UTILISATEURS - Comment voir les cours et conférences auxquels j'ai assisté.pdf' ...notice the E accent at the end of the real filename does not show up in Tallow. This is a slight problem, since we don't want to have to enforce no French characters in the filenames. Thanks in advance! - 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] uninstall not removing a ODBC DSN
Hi, I am using the following code to create an ODBC DSN, That works fine, however when I do an uninstall of the msi, it does not remove the DSN. Wix v2.0.5012.0 ?xml version=1.0 encoding=utf-8? !-- JMK Template for wix V2 -- Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Product Id=E9CB077F-7E94-491A-9111-69F72D09B354 UpgradeCode=365A4ECE-9620-4780-BCF8-4FE885A09466 Name=Fecas ODBC Connection Language=1033 Version=1.0 Manufacturer=My Co Package Id=2E2EA049-BE49-4C59-AB15-0697C0090A1F Description=Creates System DSN for FECAS on SERVER Comments=Creates System DSN for FECAS on SERVER Manufacturer=My Co InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=Data1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=progfils LongName=ProgramFilesDir Component Id=MainComponent Guid= DiskId=1 ODBCDataSource Id=odbc.fecas Name=fecas Registration=machine DriverName=SQL Server Property Id=Server Value=SERVER / Property Id=Database Value=fecas / Property Id=Description Value=[EMAIL PROTECTED] /ODBCDataSource /Component /Directory /Directory Feature Id=MainFeature Title=TheODBCDSN Level=1 ComponentRef Id=MainComponent / /Feature /Product /Wix Any Help? Mark Knox - 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] Conditional shortcut
Hi, I have to create a short cut to an exe file only if a text box is checked. I don't see a shortcut can have a condition child tag. How can I 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ConfigureIIs skipping virtual directory
Okay, I just figured out that ConfigureIIs is creating the virtual directories, but on the wrong IIS site. Because I installed WSS 3.0 on this machine, I have a Default Web Site site that is configured for port 80, but not running, and a SharePoint - 80 site that is also configure for port 80, and is running. I am thinking that Wix is finding the desired website by port number, and since I have two web sites on the same port, it happens to pick the wrong one. Has anyone else ran into this? Does anyone know of a work around? I'm guessing deleting Default Web Site would work, but I'd rather find a way to work around it without requiring the user to do an extra step. Thanks! -Tina On 3/19/07, Tina Basinger [EMAIL PROTECTED] wrote: I have a situation where ConfigureIIs does not seem to be creating a Virtual Directory that I expect it to. It only happens when I am installing to a SharePoint web site that has another custom application installed to it as well. Can anyone offer any debugging tips on how to see what ConfigureIIs is doing, and why it might not be creating the virtual directory in this case? Thanks! -Tina - 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] Conditional shortcut
Create a component and only have the shortcut in the component. Then set the condition on the Component. Mike Poulson Network Engineer Tableau Software 400 North 34th Street, Suite 200 Seattle, WA 98103 206 633 3400 x.556 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Monday, March 19, 2007 8:43 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Conditional shortcut Hi, I have to create a short cut to an exe file only if a text box is checked. I don't see a shortcut can have a condition child tag. How can I 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall not removing a ODBC DSN
It looks like you created an unmanaged Component (no GUID). That means, the Windows Installer installs your Component (and the stuff in it) and promptly forgets about it. Which means uninstall does nothing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Knox Sent: Monday, March 19, 2007 8:14 AM To: wix-users Subject: [WiX-users] uninstall not removing a ODBC DSN Hi, I am using the following code to create an ODBC DSN, That works fine, however when I do an uninstall of the msi, it does not remove the DSN. Wix v2.0.5012.0 ?xml version=1.0 encoding=utf-8? !-- JMK Template for wix V2 -- Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Product Id=E9CB077F-7E94-491A-9111-69F72D09B354 UpgradeCode=365A4ECE-9620-4780-BCF8-4FE885A09466 Name=Fecas ODBC Connection Language=1033 Version=1.0 Manufacturer=My Co Package Id=2E2EA049-BE49-4C59-AB15-0697C0090A1F Description=Creates System DSN for FECAS on SERVER Comments=Creates System DSN for FECAS on SERVER Manufacturer=My Co InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=Data1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=progfils LongName=ProgramFilesDir Component Id=MainComponent Guid= DiskId=1 ODBCDataSource Id=odbc.fecas Name=fecas Registration=machine DriverName=SQL Server Property Id=Server Value=SERVER / Property Id=Database Value=fecas / Property Id=Description Value=[EMAIL PROTECTED] /ODBCDataSource /Component /Directory /Directory Feature Id=MainFeature Title=TheODBCDSN Level=1 ComponentRef Id=MainComponent / /Feature /Product /Wix Any Help? Mark Knox - 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] ConfigureIIs skipping virtual directory
As I understand it, ConfigureIIS performs its actions on the first website that matches the IP address, Port Number, Host Header (if used). If you imagine it as an array, Default Website is almost always in array position [0] and would receive the action. We add an additional IP address to our servers to overcome this limitation. However, our apps are predominately enterprise / corporate in nature, so it is not a requirement that we are placing upon a customer or partner. David Adams MSN MessengerID: [EMAIL PROTECTED] From: Tina Basinger [EMAIL PROTECTED] To: Wix Group WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] ConfigureIIs skipping virtual directory Date: Mon, 19 Mar 2007 12:42:33 -0400 MIME-Version: 1.0 Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by bay0-mc10-f4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 19 Mar 2007 09:42:46 -0700 Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93])by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid 9203C12722; Mon, 19 Mar 2007 08:42:45 -0800 (PST) Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91]helo=mail.sourceforge.net)by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)id 1HTKwN-0007y0-4ofor WiX-users@lists.sourceforge.net; Mon, 19 Mar 2007 09:42:35 -0700 Received: from an-out-0708.google.com ([209.85.132.244])by mail.sourceforge.net with esmtp (Exim 4.44) id 1HTKwM-0004Lj-Mtfor WiX-users@lists.sourceforge.net; Mon, 19 Mar 2007 09:42:35 -0700 Received: by an-out-0708.google.com with SMTP id d40so2359503andfor WiX-users@lists.sourceforge.net;Mon, 19 Mar 2007 09:42:33 -0700 (PDT) Received: by 10.100.173.19 with SMTP id v19mr3932390ane.1174322553523;Mon, 19 Mar 2007 09:42:33 -0700 (PDT) Received: by 10.100.123.16 with HTTP; Mon, 19 Mar 2007 09:42:33 -0700 (PDT) X-Message-Info: LsUYwwHHNt30i+kezcQJBbZMnWb4kmGgA/1ss2p+YWP2s7Wh3zIjpJDORxVYGpMQ References: [EMAIL PROTECTED] X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems tohttp://sf.net/tracker/?func=addgroup_id=1atid=210.0 RCVD_BY_IP Received by mail server with no name0.1 HTML_30_40 BODY: Message is 30% to 40% HTML0.0 HTML_MESSAGE BODY: HTML included in message X-BeenThere: wix-users@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: General discussion for Windows Installer XML toolset.wix-users.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:[EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=wix-users List-Post: mailto:wix-users@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:[EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 19 Mar 2007 16:42:46.0441 (UTC) FILETIME=[9F7D1190:01C76A45] Okay, I just figured out that ConfigureIIs is creating the virtual directories, but on the wrong IIS site. Because I installed WSS 3.0 on this machine, I have a Default Web Site site that is configured for port 80, but not running, and a SharePoint - 80 site that is also configure for port 80, and is running. I am thinking that Wix is finding the desired website by port number, and since I have two web sites on the same port, it happens to pick the wrong one. Has anyone else ran into this? Does anyone know of a work around? I'm guessing deleting Default Web Site would work, but I'd rather find a way to work around it without requiring the user to do an extra step. Thanks! -Tina On 3/19/07, Tina Basinger [EMAIL PROTECTED] wrote: I have a situation where ConfigureIIs does not seem to be creating a Virtual Directory that I expect it to. It only happens when I am installing to a SharePoint web site that has another custom application installed to it as well. Can anyone offer any debugging tips on how to see what ConfigureIIs is doing, and why it might not be creating the virtual directory in this case? Thanks! -Tina - 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 _ 5.5%* 30 year fixed mortgage rate. Good credit refinance. Up to 5 free quotes - *Terms https://www2.nextag.com/goto.jsp?product=10035url=%2fst.jsptm=ysearch=mortgage_text_links_88_h2a5ds=4056p=5117disc=yvers=910
Re: [WiX-users] Consensus about CRT/MCF merge modules?
Is there some reason you can't get the bootstrapper to run the redist, vcredist_x86.exe? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Monday, March 19, 2007 6:37 AM To: Rob Mensching; Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? Well, for the apps I'm building installers for, we've already decided against static linking, so we need to deploy the DLLs somehow. In the past, we've just included the merge modules using installshield, which I believe deploys the DLLs to the system32 directory, but I've also tested with including a private copy of the DLLs, and this also appears to work. I'm not sure if this is a permitted option though. When installing a merge module, is there a way to specify the module's install directory? For example, if I want to install the CRT MSM from VS 2005, I can put something like this in: Merge Id=crt.B22E6F9A-D396-4F96-84D9-A822C63B9994 Language=1033 DiskId=1 SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm/ Since this is under a directory tag though, I don't know where it'll install the files. The module default should be the system32 directory, shouldn't it? From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 8:44 AM To: Mike Dimmick; Chris Bardon; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Consensus about CRT/MCF merge modules? Agreed. However, based on early reports I'm not sure that pushing patches into WinSxS is really working due to the complexity that is the CustomActions to work around bugs in WinXP. The ideas behind Fusion are interesting but the complexity of the system has made it difficult to verify and for users to truly understand it. Personally, I prefer a model where a patch to a shared binary has the ability to update that binary everywhere (not that I can get anyone in Microsoft to agree with me, so maybe I'm just confused smile/). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, March 16, 2007 12:56 PM To: Rob Mensching; 'Chris Bardon'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? However, with static linking you have the servicing problem - if there's a security issue in the CRT (not unknown) or in MFC, you will have to rebuild your application to pick up the fix, then rerelease your application. By contrast, if using the WinSxS versions, Microsoft can ship an update directly to end-users (either as an updated assembly with the same version number, but different file version number, or as an additional assembly with a newer version number plus a policy binding). I have to admit looking at how the VS2005 CRT merge modules work and being a bit confused as to why they're configured to do something different on Vista (not just using MsiAssembly/MsiAssemblyName tables) especially as they were released over a year before Vista was. Using a private copy of the DLLs in your application directory is also a possibility but I don't think this is recommended (or even permitted?) for a final distribution. It still has the servicing problem but not the problem of having to rebuild the application or having the large binaries. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 16 March 2007 16:35 To: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? I'm not quite yet ready to make this a recommendation but I'm currently leaning towards statically linking the libraries directly. I'm seeing hints that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some seriously bad repercussions when it comes to patching and some possibly strange behavior on Vista. It's a research project I'm doing slowly... For the WiX toolset, we statically link to the CRT (MFC, haven't done that since I wrote Orca grin/) to minimize our dependencies on the machine. That makes the binaries a bit bigger but it is worth it to not have to worry about Is the WinSxS store updated at X point in time in my install? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, March 16, 2007 9:20 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Consensus about CRT/MCF merge modules? Looking through the archives, there appear to be a couple of ways to include things like the CRT and MFC redistributables in an installer. Some have advocated including the DLLs directly, which seems to go against the concept of having a redistributable MSM to link against. I tried building with the Microsoft CRT msm that comes with VS 2005, and got a long list of warnings from light. Is there a recommended method for
Re: [WiX-users] uninstall not removing a ODBC DSN
Rob, Many Thanks, Dont know how I missed that one Mark Rob Mensching wrote: It looks like you created an unmanaged Component (no GUID). That means, the Windows Installer installs your Component (and the stuff in it) and promptly forgets about it. Which means uninstall does nothing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Knox Sent: Monday, March 19, 2007 8:14 AM To: wix-users Subject: [WiX-users] uninstall not removing a ODBC DSN Hi, I am using the following code to create an ODBC DSN, That works fine, however when I do an uninstall of the msi, it does not remove the DSN. Wix v2.0.5012.0 ?xml version=1.0 encoding=utf-8? !-- JMK Template for wix V2 -- Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Product Id=E9CB077F-7E94-491A-9111-69F72D09B354 UpgradeCode=365A4ECE-9620-4780-BCF8-4FE885A09466 Name=Fecas ODBC Connection Language=1033 Version=1.0 Manufacturer=My Co Package Id=2E2EA049-BE49-4C59-AB15-0697C0090A1F Description=Creates System DSN for FECAS on SERVER Comments=Creates System DSN for FECAS on SERVER Manufacturer=My Co InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=Data1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=progfils LongName=ProgramFilesDir Component Id=MainComponent Guid= DiskId=1 ODBCDataSource Id=odbc.fecas Name=fecas Registration=machine DriverName=SQL Server Property Id=Server Value=SERVER / Property Id=Database Value=fecas / Property Id=Description Value=[EMAIL PROTECTED] /ODBCDataSource /Component /Directory /Directory Feature Id=MainFeature Title=TheODBCDSN Level=1 ComponentRef Id=MainComponent / /Feature /Product /Wix Any Help? Mark Knox - 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
Folks like me, meaning people who have minuscule experience programming in VBScript or C++. I pretty much started learning to program in C# back in 2002, graduated last year, and am currently working as a C#/ASP.NET developer. Of course I could embark on a journey to learn C++, but I think the rest of the world is moving to .NET, especially with the advent of C# 3.0 (LINQ), CLR 3.5, etc. I rather spend time on exploring new features of C# 3.0 and CLR 3.5. I am still a WIX newbie by any means - I hope I didn't offend you by saying 'people like me' :) In essence what I was trying to say is that folks who excel in C# will be able to exploit WIX's features to a greater extent. Plus I think if this happens, many developers will start adopting WIX right away. I still have a few colleagues who don't want to use just because they can't pass values read from a WIX User dialog to a C# .dll. One (hypothetical) example most people would put this functionality to use is writing their own custom SQL connection strings using the SqlConnectionStringBuilder. On 3/19/07, Rob Mensching [EMAIL PROTECTED] wrote: I haven't blogged it. This one requires more research that my recent avoid COM advertisement entry because I haven't lived it closely. I got enough reports of trickiness with managed CustomActions to just stay away. The root issue comes down to having the wrong version of the .NET Framework loaded. For example, let's say you have a 1.1 CustomAction but need to install a 2.0 Framework assembly to the GAC. My understanding was that the easy/obvious way to use the 1.1 CustomAction caused the 1.1. Framework to be loaded and that caused the 2.0 Framework install to fail later (because the 1.1. Framework won't understand it). Again, the details are fuzzy because I haven't stepped through the debugger on this issue myself. Basically, it comes down to the fact that the Windows Installer team needs to look at what managed CustomActions mean and do the right thing when looking at the complete picture. They know things about the all the different ways the Windows Installer gets invoked that you and I would struggle to think of. For example, what happens if you had a Shell Extension written in managed code then did faulted in an MSI via Extension advertisement? Do all the correct .NET Frameworks get loaded? Are you going to test it? smile/ -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Friday, March 16, 2007 11:43 PM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Hi Rob, Would you care to elaborate on this part a bit? If you already blogged it, I apologize. I've followed the evolution of this issue for a while now and I am always curious to learn more about it. To my knowledge, I don't remember you or anyone else discussing any specific issues regarding loaded the CLR into the installer process. I'm definitely of the opinion that these things are best avoided for now due to the lack of support for it at the WI level. On the other hand, I also believe it is just a matter of time before this needs to happen in a fully supported way. Basically, I'm trying to understand what the solution might look like in order to overcome some of the more subtle issues. What's so neat? :) Thanks! Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Levi Wilson [EMAIL PROTECTED]; Dhaval Patel [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Friday, March 16, 2007 12:43 PM Subject: Re: [WiX-users] C# .dll More importantly, the Windows Installer doesn't support it today. There are actually neat problems you can introduce by loading the .NET Framework into the Windows Installer process. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Friday, March 16, 2007 10:40 AM To: Dhaval Patel Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll I don't know for certain, but my guess would be that there's no guarantee that the .NET Framework has been installed on the client. On 3/16/07, Dhaval Patel [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Will WIX 3.0 be adding the capability to call C# .dll files? If not, WHY? :) - 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.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash.
Re: [WiX-users] Creating SqlDatabase with/without Windows Authentification
Good stuff! Thanks for sharing.
On 3/19/07, pobox77 [EMAIL PROTECTED] wrote:
Here my solution:
util:User Id=SQLUser Name=[SQLUSERNAME]
Password=[SQLUSERPASSWORD] /
...
!--database authentification, SQLUSER will be used --
!-- SQLUSERNAME and SQLUSERPASSWORD will be entered in a customized
dialog --
Component Id=CreateDBUser DiskId=1 Guid=YOURGUID
sql:SqlDatabase Id=dbUser Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no User=SQLUser
sql:SqlScript Id=CreateTablesSqlScriptUser
ContinueOnError=no
ExecuteOnInstall=yes ExecuteOnReinstall=no Sequence=002
BinaryKey=CreateTablesBin User=SQLUser /
/sql:SqlDatabase
ConditionWIN_AUTH_DB=False/Condition
/Component
!-- Windows authentification, without User attribute --
Component Id=CreateDBWindows DiskId=1 Guid=YOURGUID
sql:SqlDatabase Id=dbWindows Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no
sql:SqlScript Id=CreateTablesSqlScriptWindows
ContinueOnError=no ExecuteOnInstall=yes ExecuteOnReinstall=no
Sequence=002 BinaryKey=CreateTablesBin /
/sql:SqlDatabase
ConditionWIN_AUTH_DB=True/Condition
/Component
...
!-- this script will be used for both above --
Binary Id=CreateTablesBin SourceFile=Create XCB
Tables_Views_StoredProcedures.sql
/Binary
...
!-- the property WIN_AUTH_DB will be set using a radio button
control in the same customized dialog
as username and password --
!-- the property must be global, eg. its name uses capitals
only
--
Control Id=SecurityButtons1 Type=RadioButtonGroup X=90
Y=142 Width=197 Height=30 Property=WIN_AUTH_DB
/Control
...
RadioButtonGroup Property=WIN_AUTH_DB
RadioButton Text={\DlgFont8}amp;Integrated Security (Windows
authentification) Value=True X=0 Y=0 Width=206 Height=12 /
RadioButton Text={\DlgFont8}amp;User Name and Password
Value=False X=0 Y=15 Width=206 Height=15 /
/RadioButtonGroup
Dhaval Patel-4 wrote:
I'd be interested in seeing your solution, Peter. Can you post your
solution
on the Wix-users list for future reference? I feel this shouldn't be
hard,
but if you already have it, then why reinvent the wheel!
Thanks in advance.
On 3/13/07, pobox77 [EMAIL PROTECTED] wrote:
Thanks Dana,
I've just found the same solution about an hour ago.
Just a note for people having similar problem:
The property used by the radio button and in the condition must be a
global
property
(e.g. the name of it should only have capitals) otherwise it doesn't
work.
Peter
Dana Gutride wrote:
This is not possible within the sql database tag right now. There is
a
bug/feature request in for this exact functionality, but as far as I
can
tell, it hasn't been added yet. The only way to do this is to have
two
sqldatabase tags in separate components and then add conditions for
the
components based on the radio button's property.
Dana
On 3/13/07, pobox77 [EMAIL PROTECTED] wrote:
Sorry, the snippet was wrong formatted.
pobox77 wrote:
Hi,
I would like to create a SqlDatabase either with Username+Password
or
with
Windows authentification. I am using a radio button in a customize
dialog.
If not Windows auth. is selected, the user can enter a username
and
a
password.
How should I set the SqlDatabase component to do it? I mean, if
Windows
auth. the User=SQLUser should not be used.
Snippet:
Component Id=CreateDB DiskId=1
Guid=----
sql:SqlDatabase Id=MyDb Server=[SQLSERVER]
Database=[SQLDBNAME] CreateOnInstall=yes
ConfirmOverwrite=yes
DropOnReinstall=no DropOnUninstall=no User=SQLUser
sql:SqlScript Id=CreateTablesSqlScript
ContinueOnError=no
ExecuteOnInstall=yes ExecuteOnReinstall=no Sequence=002
BinaryKey=CreateTablesBin User=SQLUser /
/sql:SqlDatabase
/Component
Feature Id=SqlDb Title=Create Database
Description=Installing
database. Please ensure that the SQL Server is running on the
target
server. AllowAdvertise=yes TypicalDefault=install
Display=expand
Level=1
ComponentRef Id=CreateDB /
/Feature
Thanks in advance,
Peter
--
View this message in context:
http://www.nabble.com/Creating-SqlDatabase-with-without-Windows-Authentification-tf3394305.html#a9449474
Sent from the wix-users mailing list archive at Nabble.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
[WiX-users] movements
We are proud to work with Bank One to help more families and individuals on the path to homeownership, said Rita Hillman, director of Fannie Mae's Michigan Partnership Office. Kondo's music has won him the adulation of his peers. The brain, like jelly, would have drained through the hole and out through a nostril as part of the mummification process, Washington University dentist and anthropologist Charles Hildebolt said. I can only hide it in my heart. Yahoo betrayed my husband and deprived him of freedom, Yu says through a translator, her voice trembling. Fortunately, we've never endured a direct hit, but we always feel better knowing our pets are protected with us. Or is it just overweening arrogance? 8 percent of total applications, increasing from 74. melody.gif Description: GIF image - 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] CustomActions in disabled features
I have 2 merge modules. Dependent of a property I want to include the one or the other merge module. By the moment I have this solved via separate features combined with a condition: Feature Id=ProductFeature Title=Complete Level=1 Feature Id=MergeA Title=MergeA Level=1 Condition Level=0NOT Property=Value/Condition MergeRef Id=... / /Feature ... /Feature In the merge module I have custom actions included. Theses custom actions get executed during install even if the feature (and so the merge module) is disabled. My workaround is to use the feature condition property also for the custom action condition: Custom Action=... After=...NOT Installed AND Property=Value/Custom This works, but it is very boring because I have a lot of custom actions. And I think there must be a more elegant way to solve this issue. But which? - 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
In other words, what's happened (and this is fairly common) is that your company has grabbed a fairly new developer (you) and asked for a setup. One of the requirements for the task should have included experience in C++ if your managers knew anything about MSI setups and custom actions. My reaction to these situations is to point out that building setups is NOT application programming, any more than writing device drivers is, and as a consequence there are some different skills required, one of them being C++ if robust custom actions are expected. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 10:45 AM To: Rob Mensching Cc: Joe Kaplan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Folks like me, meaning people who have minuscule experience programming in VBScript or C++. I pretty much started learning to program in C# back in 2002, graduated last year, and am currently working as a C#/ASP.NET developer. Of course I could embark on a journey to learn C++, but I think the rest of the world is moving to .NET, especially with the advent of C# 3.0 (LINQ), CLR 3.5, etc. I rather spend time on exploring new features of C# 3.0 and CLR 3.5. I am still a WIX newbie by any means - I hope I didn't offend you by saying 'people like me' :) In essence what I was trying to say is that folks who excel in C# will be able to exploit WIX's features to a greater extent. Plus I think if this happens, many developers will start adopting WIX right away. I still have a few colleagues who don't want to use just because they can't pass values read from a WIX User dialog to a C# .dll. One (hypothetical) example most people would put this functionality to use is writing their own custom SQL connection strings using the SqlConnectionStringBuilder. On 3/19/07, Rob Mensching [EMAIL PROTECTED] wrote: I haven't blogged it. This one requires more research that my recent avoid COM advertisement entry because I haven't lived it closely. I got enough reports of trickiness with managed CustomActions to just stay away. The root issue comes down to having the wrong version of the .NET Framework loaded. For example, let's say you have a 1.1 CustomAction but need to install a 2.0 Framework assembly to the GAC. My understanding was that the easy/obvious way to use the 1.1 CustomAction caused the 1.1. Framework to be loaded and that caused the 2.0 Framework install to fail later (because the 1.1. Framework won't understand it). Again, the details are fuzzy because I haven't stepped through the debugger on this issue myself. Basically, it comes down to the fact that the Windows Installer team needs to look at what managed CustomActions mean and do the right thing when looking at the complete picture. They know things about the all the different ways the Windows Installer gets invoked that you and I would struggle to think of. For example, what happens if you had a Shell Extension written in managed code then did faulted in an MSI via Extension advertisement? Do all the correct .NET Frameworks get loaded? Are you going to test it? smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Joe Kaplan Sent: Friday, March 16, 2007 11:43 PM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Hi Rob, Would you care to elaborate on this part a bit? If you already blogged it, I apologize. I've followed the evolution of this issue for a while now and I am always curious to learn more about it. To my knowledge, I don't remember you or anyone else discussing any specific issues regarding loaded the CLR into the installer process. I'm definitely of the opinion that these things are best avoided for now due to the lack of support for it at the WI level. On the other hand, I also believe it is just a matter of time before this needs to happen in a fully supported way. Basically, I'm trying to understand what the solution might look like in order to overcome some of the more subtle issues. What's so neat? :) Thanks! Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Levi Wilson [EMAIL PROTECTED]; Dhaval Patel [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net mailto:wix-users@lists.sourceforge.net Sent: Friday, March 16, 2007 12:43 PM Subject: Re: [WiX-users] C# .dll More importantly, the Windows Installer doesn't support it today. There are actually neat problems you can introduce by loading the .NET Framework
Re: [WiX-users] C# .dll
That pretty much hits it on the head. Richard, I was having a hard time expressing those words. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 19, 2007 11:44 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll One other concern in making custom actions in C# (or anything else) is that as Rob regularly observes, custom actions are very difficult to get right - especially when considering installation failure (rollback) and appropriate uninstall operation. Speaking for myself, I try to avoid them whenever possible. In fact I think the only custom actions I currently have in any of the installations I have generated relate to the verification at installation time of a customer entered license key. Many people seem to look at custom actions as a way to do things that aren't supported by Microsoft Installer itself. While true, it is also often true that there is a reason why Microsoft Installer doesn't currently contain built-in support for that specific action. Regards, Richard --- Original message follows --- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 10:45 AM To: Rob Mensching Cc: Joe Kaplan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Folks like me, meaning people who have minuscule experience programming in VBScript or C++. I pretty much started learning to program in C# back in 2002, graduated last year, and am currently working as a C#/ASP.NET developer. Of course I could embark on a journey to learn C++, but I think the rest of the world is moving to .NET, especially with the advent of C# 3.0 (LINQ), CLR 3.5, etc. I rather spend time on exploring new features of C# 3.0 and CLR 3.5. I am still a WIX newbie by any means - I hope I didn't offend you by saying 'people like me' :) In essence what I was trying to say is that folks who excel in C# will be able to exploit WIX's features to a greater extent. Plus I think if this happens, many developers will start adopting WIX right away. I still have a few colleagues who don't want to use just because they can't pass values read from a WIX User dialog to a C# .dll. One (hypothetical) example most people would put this functionality to use is writing their own custom SQL connection strings using the SqlConnectionStringBuilder. --- Remainder of message history trimmed --- * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - 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] Consensus about CRT/MCF merge modules?
The VC2005 merge modules will install files to: - [WindowsFolder]System32 on Windows 9X and 2000; - The appropriate WinSxS folder on Windows XP, 2003 and Vista. They are not retargetable. The vcredist_x86.exe package will do exactly the same since it's basically just all the merge modules repackaged inside an MSI inside a bootstrapper. -- Mike Dimmick _ From: Chris Bardon [mailto:[EMAIL PROTECTED] Sent: 19 March 2007 13:37 To: Rob Mensching; Mike Dimmick; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Consensus about CRT/MCF merge modules? Well, for the apps I'm building installers for, we've already decided against static linking, so we need to deploy the DLLs somehow. In the past, we've just included the merge modules using installshield, which I believe deploys the DLLs to the system32 directory, but I've also tested with including a private copy of the DLLs, and this also appears to work. I'm not sure if this is a permitted option though. When installing a merge module, is there a way to specify the module's install directory? For example, if I want to install the CRT MSM from VS 2005, I can put something like this in: Merge Id=crt.B22E6F9A-D396-4F96-84D9-A822C63B9994 Language=1033 DiskId=1 SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm/ Since this is under a directory tag though, I don't know where it'll install the files. The module default should be the system32 directory, shouldn't it? _ From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 8:44 AM To: Mike Dimmick; Chris Bardon; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Consensus about CRT/MCF merge modules? Agreed. However, based on early reports I'm not sure that pushing patches into WinSxS is really working due to the complexity that is the CustomActions to work around bugs in WinXP. The ideas behind Fusion are interesting but the complexity of the system has made it difficult to verify and for users to truly understand it. Personally, I prefer a model where a patch to a shared binary has the ability to update that binary everywhere (not that I can get anyone in Microsoft to agree with me, so maybe I'm just confused smile/). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, March 16, 2007 12:56 PM To: Rob Mensching; 'Chris Bardon'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? However, with static linking you have the servicing problem - if there's a security issue in the CRT (not unknown) or in MFC, you will have to rebuild your application to pick up the fix, then rerelease your application. By contrast, if using the WinSxS versions, Microsoft can ship an update directly to end-users (either as an updated assembly with the same version number, but different file version number, or as an additional assembly with a newer version number plus a policy binding). I have to admit looking at how the VS2005 CRT merge modules work and being a bit confused as to why they're configured to do something different on Vista (not just using MsiAssembly/MsiAssemblyName tables) especially as they were released over a year before Vista was. Using a private copy of the DLLs in your application directory is also a possibility but I don't think this is recommended (or even permitted?) for a final distribution. It still has the servicing problem but not the problem of having to rebuild the application or having the large binaries. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 16 March 2007 16:35 To: Chris Bardon; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules? I'm not quite yet ready to make this a recommendation but I'm currently leaning towards statically linking the libraries directly. I'm seeing hints that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some seriously bad repercussions when it comes to patching and some possibly strange behavior on Vista. It's a research project I'm doing slowly. For the WiX toolset, we statically link to the CRT (MFC, haven't done that since I wrote Orca grin/) to minimize our dependencies on the machine. That makes the binaries a bit bigger but it is worth it to not have to worry about Is the WinSxS store updated at X point in time in my install? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Friday, March 16, 2007 9:20 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Consensus about CRT/MCF merge modules? Looking through the archives, there appear to be a couple of ways to include things like the CRT and MFC redistributables in an installer. Some have advocated including the DLLs directly, which seems to go against the concept of having a redistributable MSM to link
Re: [WiX-users] votive and iisextension
Yes, you need to specify it on the candle and light command lines: candle -ext WixIIsExtension .etc. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sawyer, Shane Sent: 19 March 2007 14:19 To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] votive and iisextension Hi Bob, sorry for the delayed response to your answer, the spam filter grabbed your reply and just now let me have it. I have specified the WixIISExtension like this: Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension; Actually, it was done using WixCop to convert from version 2. Is there some place else I need to specify this extension? I am getting the error (copied below) when trying to build within VS2005. Thanks Shane Sawyer _ From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 17, 2007 10:48 AM To: Sawyer, Shane Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] votive and iisextension Sawyer, Shane wrote: Does Votive support building a wxs file with the iisextension? I am getting an error: The Component element contains an unhandled extension element 'iis:WebVirtualDir'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/IIsExtension' namespace has been provided. You need to specify WixIIsExtension to use the IIS authoring and CAs. -- sig://boB http://bobs.org _ The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. - 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
I think one of the reasons why Windows Installer does not have lots of fancy actions is because they are not generally related to installation and hence the support for Custom Actions. You cannot include all the possible actions as there are so many types of software and so many configuration/changes required, that it is better to leave them to the developer to write custom actions for their needs. Now for .NET Custom Actions, I think it will be cool to have support for that, but at the same time, I think vbScript and Jscript are very easy to use and learn compared to C++, in case someone does not want to spend time on C++. Besides, if you know Object Oriented Programming, like C#, learning C++ is not that difficult especially if it is just for Custom Actions. It may take a bit extra time for you to write a DLL in the beginning, but once it is done, adding more functions to it is very easy. There are so many tutorials out there that you can learn from. I am not a C++ programmer by any means and most of my coding has been in C# and Java so I understand where Dhaval is coming from. But I had to write custom actions in C++ as it was not an option at several places I worked at. So if you like being a setup developer for Windows, learning C++ will definitely help you in the longer run. Now one must avoid using Custom Actions unless it is really required and is something that Windows Installer cannot do. But can you avoid it or not depends on the software you are writing setup for, I have seen a lot of products with more than 50 Custom Actions and all of them doing something that Windows Installer cannot do. Once you start working on complex software setup, things get messy very easily and the best way to handle those Custom Actions is to write Custom Action dll in C++. Just my two cents. Thanks Danish Waheed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 19, 2007 11:44 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll One other concern in making custom actions in C# (or anything else) is that as Rob regularly observes, custom actions are very difficult to get right - especially when considering installation failure (rollback) and appropriate uninstall operation. Speaking for myself, I try to avoid them whenever possible. In fact I think the only custom actions I currently have in any of the installations I have generated relate to the verification at installation time of a customer entered license key. Many people seem to look at custom actions as a way to do things that aren't supported by Microsoft Installer itself. While true, it is also often true that there is a reason why Microsoft Installer doesn't currently contain built-in support for that specific action. Regards, Richard --- Original message follows --- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 10:45 AM To: Rob Mensching Cc: Joe Kaplan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Folks like me, meaning people who have minuscule experience programming in VBScript or C++. I pretty much started learning to program in C# back in 2002, graduated last year, and am currently working as a C#/ASP.NET developer. Of course I could embark on a journey to learn C++, but I think the rest of the world is moving to .NET, especially with the advent of C# 3.0 (LINQ), CLR 3.5, etc. I rather spend time on exploring new features of C# 3.0 and CLR 3.5. I am still a WIX newbie by any means - I hope I didn't offend you by saying 'people like me' :) In essence what I was trying to say is that folks who excel in C# will be able to exploit WIX's features to a greater extent. Plus I think if this happens, many developers will start adopting WIX right away. I still have a few colleagues who don't want to use just because they can't pass values read from a WIX User dialog to a C# .dll. One (hypothetical) example most people would put this functionality to use is writing their own custom SQL connection strings using the SqlConnectionStringBuilder. --- Remainder of message history trimmed --- * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.
Re: [WiX-users] C# .dll
And C++ will NEVER die. On 3/19/07, Danish Waheed [EMAIL PROTECTED] wrote: I think one of the reasons why Windows Installer does not have lots of fancy actions is because they are not generally related to installation and hence the support for Custom Actions. You cannot include all the possible actions as there are so many types of software and so many configuration/changes required, that it is better to leave them to the developer to write custom actions for their needs. Now for .NET Custom Actions, I think it will be cool to have support for that, but at the same time, I think vbScript and Jscript are very easy to use and learn compared to C++, in case someone does not want to spend time on C++. Besides, if you know Object Oriented Programming, like C#, learning C++ is not that difficult especially if it is just for Custom Actions. It may take a bit extra time for you to write a DLL in the beginning, but once it is done, adding more functions to it is very easy. There are so many tutorials out there that you can learn from. I am not a C++ programmer by any means and most of my coding has been in C# and Java so I understand where Dhaval is coming from. But I had to write custom actions in C++ as it was not an option at several places I worked at. So if you like being a setup developer for Windows, learning C++ will definitely help you in the longer run. Now one must avoid using Custom Actions unless it is really required and is something that Windows Installer cannot do. But can you avoid it or not depends on the software you are writing setup for, I have seen a lot of products with more than 50 Custom Actions and all of them doing something that Windows Installer cannot do. Once you start working on complex software setup, things get messy very easily and the best way to handle those Custom Actions is to write Custom Action dll in C++. Just my two cents. Thanks Danish Waheed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 19, 2007 11:44 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll One other concern in making custom actions in C# (or anything else) is that as Rob regularly observes, custom actions are very difficult to get right - especially when considering installation failure (rollback) and appropriate uninstall operation. Speaking for myself, I try to avoid them whenever possible. In fact I think the only custom actions I currently have in any of the installations I have generated relate to the verification at installation time of a customer entered license key. Many people seem to look at custom actions as a way to do things that aren't supported by Microsoft Installer itself. While true, it is also often true that there is a reason why Microsoft Installer doesn't currently contain built-in support for that specific action. Regards, Richard --- Original message follows --- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 10:45 AM To: Rob Mensching Cc: Joe Kaplan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Folks like me, meaning people who have minuscule experience programming in VBScript or C++. I pretty much started learning to program in C# back in 2002, graduated last year, and am currently working as a C#/ASP.NET developer. Of course I could embark on a journey to learn C++, but I think the rest of the world is moving to .NET, especially with the advent of C# 3.0 (LINQ), CLR 3.5, etc. I rather spend time on exploring new features of C# 3.0 and CLR 3.5. I am still a WIX newbie by any means - I hope I didn't offend you by saying 'people like me' :) In essence what I was trying to say is that folks who excel in C# will be able to exploit WIX's features to a greater extent. Plus I think if this happens, many developers will start adopting WIX right away. I still have a few colleagues who don't want to use just because they can't pass values read from a WIX User dialog to a C# .dll. One (hypothetical) example most people would put this functionality to use is writing their own custom SQL connection strings using the SqlConnectionStringBuilder. --- Remainder of message history trimmed --- * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any
[WiX-users] Call 3rd party dll from C++ Custom Action
Is it possible to call a third party dll, included in my installer as a binary file only, from a custom action that is in a C++ dll? If that isn't possible is that anyway to access a 3rd party dll from my custom action prior to the installation of files? Thanx Chuck - 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] Intercepting SQL errors and displaying custom error
I can't seem to find this in my version of WiX 2.0.4820.0 From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 2:57 PM To: Don Tasanasanta; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] Intercepting SQL errors and displaying custom error Take a look at wix\src\ext\SqlExtension\wixlib\en-us.wxl. You'll see everything there is overridable. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta Sent: Friday, March 16, 2007 2:13 PM To: Don Tasanasanta; Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom error I'm searching the wixlib's for the sql error strings and only found them in the sca.wixlib None of the tuple's defined in the sql section has localization variables and I haven't found associating fields in the wixui.wixlib Does that mean that the sql errors have not been localized? In which case, does that mean that a wxl file won't do the trick in intercepting sql errors and substituting my own custom errors? From: Don Tasanasanta Sent: Friday, March 16, 2007 1:06 PM To: Don Tasanasanta; Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Intercepting SQL errors and displaying custom error Ok maybe I don't understand .wxl files that well... I found the identifier in the error table, created a .wxl file and used light with a -loc to my wxl file and a reference to my rsp file. When all was said and done I checked the error table but the error identifier I tried to replace wasn't changed. Here is my wxl file: ?xml version='1.0'? WixLocalization xmlns='http://schemas.microsoft.com/wix/2003/01/localization' Codepage='1252' String Id='LANG'1033/String String Id='26201'la la la la la/String /WixLocalization I'm trying to replace the string 26201 in the error table. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta Sent: Thursday, March 15, 2007 5:35 PM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom error I think I understand the use of .wxl files and I've found the sql errors within the sca.wixlib. How do I identify the sql errors within my personal .wxl? Do I simply copy from section type=fragment to /section of the sql errors into my own .wxl, substitute my own error msgs, and then link it? Is it that easy? From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 4:46 PM To: Don Tasanasanta; wix-users@lists.sourceforge.net Subject: RE: Intercepting SQL errors and displaying custom error Yes. Provide a .wxl file for the localization identifiers defined the .wixlib. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta Sent: Wednesday, March 14, 2007 3:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Intercepting SQL errors and displaying custom error Is there a way to intercept SQL install errors and display my own custom error(s)? - 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
Phil: My PM and all the senior engineers who interviewed me, hired me on the basis of my C# skills. I was the one who started packaging my company's deployment packages using WIX - all (and I mean ALL) the folks in my company still use XCopy and batch files. I raised this issue (calling C# .dlls from WIX) because it is something that seems eminent and invigorating. I like learning newer technologies and I ended up learning WIX myself, not because my superiors 'forced it upon me' (they are least interested in such issues anyway :)) or because it was a core requirement. I just like my packages to be deployed in an 'orderly' manner and what better than WIX to do such things!! That being said, I am not complaining that WIX doesn't support .NET .dlls - I am merely raising an issue that will be raised by others as more people start adopting WIX. I have coded in ANSI C (in college, not exaggerating) for a semester, because I was forced to. Personally I felt it was horrible, but then I also believed that I couldn't be a programmer unless I started from the ground up. Of course I could learn C++, and who knows someday I will, but at this point in time I see myself as a hardcore C# enthusiast (of course a newbie as far as my programming skills go!). Anyway, I just wanted to find out the reasons why this can't happen (at least for now), and I think Richard made some good points. I completely overlooked the issue of 'undoing' a custom action, but I was thinking more on the lines of 'if it is doable in C++, it must be a breeze to redo it in C#'. Thanks for all the replies (the issue surely raised a few eyebrows.. hehe). On 3/19/07, Levi Wilson [EMAIL PROTECTED] wrote: And C++ will NEVER die. On 3/19/07, Danish Waheed [EMAIL PROTECTED] wrote: I think one of the reasons why Windows Installer does not have lots of fancy actions is because they are not generally related to installation and hence the support for Custom Actions. You cannot include all the possible actions as there are so many types of software and so many configuration/changes required, that it is better to leave them to the developer to write custom actions for their needs. Now for .NET Custom Actions, I think it will be cool to have support for that, but at the same time, I think vbScript and Jscript are very easy to use and learn compared to C++, in case someone does not want to spend time on C++. Besides, if you know Object Oriented Programming, like C#, learning C++ is not that difficult especially if it is just for Custom Actions. It may take a bit extra time for you to write a DLL in the beginning, but once it is done, adding more functions to it is very easy. There are so many tutorials out there that you can learn from. I am not a C++ programmer by any means and most of my coding has been in C# and Java so I understand where Dhaval is coming from. But I had to write custom actions in C++ as it was not an option at several places I worked at. So if you like being a setup developer for Windows, learning C++ will definitely help you in the longer run. Now one must avoid using Custom Actions unless it is really required and is something that Windows Installer cannot do. But can you avoid it or not depends on the software you are writing setup for, I have seen a lot of products with more than 50 Custom Actions and all of them doing something that Windows Installer cannot do. Once you start working on complex software setup, things get messy very easily and the best way to handle those Custom Actions is to write Custom Action dll in C++. Just my two cents. Thanks Danish Waheed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 19, 2007 11:44 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll One other concern in making custom actions in C# (or anything else) is that as Rob regularly observes, custom actions are very difficult to get right - especially when considering installation failure (rollback) and appropriate uninstall operation. Speaking for myself, I try to avoid them whenever possible. In fact I think the only custom actions I currently have in any of the installations I have generated relate to the verification at installation time of a customer entered license key. Many people seem to look at custom actions as a way to do things that aren't supported by Microsoft Installer itself. While true, it is also often true that there is a reason why Microsoft Installer doesn't currently contain built-in support for that specific action. Regards, Richard --- Original message follows --- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 10:45 AM To: Rob Mensching Cc: Joe Kaplan; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Folks like me, meaning people who have minuscule
Re: [WiX-users] C# .dll
I understand, and it wasn't meant as a criticism. It just seems to be a common story that some developer on the team with some set of skills will be pressed into service as the setup guy with a different skill set requirement. Occasionally people are surprised by that difference. Setup is just copying files, right??? How hard can it be? But you volunteered, so good, and welcome to the setup club. You'll probably run into other areas where setups require a different way of thinking. (One model is that you should write setups as if you're updating the company's payroll database with no backup to correct it if you fnd out you did it wrong when it's all over.) Also, C++ will always be useful, so if you're just starting out I'd certainly recommend you learning it (include managed C++ too) because you'll stand out from all those guys who only have C#. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 4:20 PM To: Levi Wilson Cc: Danish Waheed; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Phil: My PM and all the senior engineers who interviewed me, hired me on the basis of my C# skills. I was the one who started packaging my company's deployment packages using WIX - all (and I mean ALL) the folks in my company still use XCopy and batch files. I raised this issue (calling C# .dlls from WIX) because it is something that seems eminent and invigorating. I like learning newer technologies and I ended up learning WIX myself, not because my superiors 'forced it upon me' (they are least interested in such issues anyway :)) or because it was a core requirement. I just like my packages to be deployed in an 'orderly' manner and what better than WIX to do such things!! That being said, I am not complaining that WIX doesn't support .NET .dlls - I am merely raising an issue that will be raised by others as more people start adopting WIX. I have coded in ANSI C (in college, not exaggerating) for a semester, because I was forced to. Personally I felt it was horrible, but then I also believed that I couldn't be a programmer unless I started from the ground up. Of course I could learn C++, and who knows someday I will, but at this point in time I see myself as a hardcore C# enthusiast (of course a newbie as far as my programming skills go!). Anyway, I just wanted to find out the reasons why this can't happen (at least for now), and I think Richard made some good points. I completely overlooked the issue of 'undoing' a custom action, but I was thinking more on the lines of 'if it is doable in C++, it must be a breeze to redo it in C#'. Thanks for all the replies (the issue surely raised a few eyebrows.. hehe). On 3/19/07, Levi Wilson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: And C++ will NEVER die. On 3/19/07, Danish Waheed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think one of the reasons why Windows Installer does not have lots of fancy actions is because they are not generally related to installation and hence the support for Custom Actions. You cannot include all the possible actions as there are so many types of software and so many configuration/changes required, that it is better to leave them to the developer to write custom actions for their needs. Now for .NET Custom Actions, I think it will be cool to have support for that, but at the same time, I think vbScript and Jscript are very easy to use and learn compared to C++, in case someone does not want to spend time on C++. Besides, if you know Object Oriented Programming, like C#, learning C++ is not that difficult especially if it is just for Custom Actions. It may take a bit extra time for you to write a DLL in the beginning, but once it is done, adding more functions to it is very easy. There are so many tutorials out there that you can learn from. I am not a C++ programmer by any means and most of my coding has been in C# and Java so I understand where Dhaval is coming from. But I had to write custom actions in C++ as it was not an option at several places I worked at. So if you like being a setup developer for Windows, learning C++ will definitely help you in the longer run. Now one must avoid using Custom Actions unless it is really required and is something that Windows Installer cannot do. But can you avoid it or not depends on the software you are writing setup for, I have seen a lot of products with more than 50 Custom Actions and all of
Re: [WiX-users] C# .dll
Thanks for those words of wisdom :) On 3/19/07, Wilson, Phil [EMAIL PROTECTED] wrote: I understand, and it wasn't meant as a criticism. It just seems to be a common story that some developer on the team with some set of skills will be pressed into service as the setup guy with a different skill set requirement. Occasionally people are surprised by that difference. Setup is just copying files, right??? How hard can it be? But you volunteered, so good, and welcome to the setup club. You'll probably run into other areas where setups require a different way of thinking. (One model is that you should write setups as if you're updating the company's payroll database with no backup to correct it if you fnd out you did it wrong when it's all over.) Also, C++ will always be useful, so if you're just starting out I'd certainly recommend you learning it (include managed C++ too) because you'll stand out from all those guys who only have C#. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dhaval Patel Sent: Monday, March 19, 2007 4:20 PM To: Levi Wilson Cc: Danish Waheed; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll Phil: My PM and all the senior engineers who interviewed me, hired me on the basis of my C# skills. I was the one who started packaging my company's deployment packages using WIX - all (and I mean ALL) the folks in my company still use XCopy and batch files. I raised this issue (calling C# .dlls from WIX) because it is something that seems eminent and invigorating. I like learning newer technologies and I ended up learning WIX myself, not because my superiors 'forced it upon me' (they are least interested in such issues anyway :)) or because it was a core requirement. I just like my packages to be deployed in an 'orderly' manner and what better than WIX to do such things!! That being said, I am not complaining that WIX doesn't support .NET .dlls - I am merely raising an issue that will be raised by others as more people start adopting WIX. I have coded in ANSI C (in college, not exaggerating) for a semester, because I was forced to. Personally I felt it was horrible, but then I also believed that I couldn't be a programmer unless I started from the ground up. Of course I could learn C++, and who knows someday I will, but at this point in time I see myself as a hardcore C# enthusiast (of course a newbie as far as my programming skills go!). Anyway, I just wanted to find out the reasons why this can't happen (at least for now), and I think Richard made some good points. I completely overlooked the issue of 'undoing' a custom action, but I was thinking more on the lines of 'if it is doable in C++, it must be a breeze to redo it in C#'. Thanks for all the replies (the issue surely raised a few eyebrows.. hehe). On 3/19/07, Levi Wilson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: And C++ will NEVER die. On 3/19/07, Danish Waheed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think one of the reasons why Windows Installer does not have lots of fancy actions is because they are not generally related to installation and hence the support for Custom Actions. You cannot include all the possible actions as there are so many types of software and so many configuration/changes required, that it is better to leave them to the developer to write custom actions for their needs. Now for .NET Custom Actions, I think it will be cool to have support for that, but at the same time, I think vbScript and Jscript are very easy to use and learn compared to C++, in case someone does not want to spend time on C++. Besides, if you know Object Oriented Programming, like C#, learning C++ is not that difficult especially if it is just for Custom Actions. It may take a bit extra time for you to write a DLL in the beginning, but once it is done, adding more functions to it is very easy. There are so many tutorials out there that you can learn from. I am not a C++ programmer by any means and most of my coding has been in C# and Java so I understand where Dhaval is coming from. But I had to write custom actions in C++ as it was not an option at several places I worked at. So if you like being a setup developer for Windows, learning C++ will definitely help you in the longer run. Now one must avoid using Custom Actions unless it is really required and is something that Windows Installer cannot do. But can you avoid it or not depends on the software you are writing setup for, I have seen a lot of products with more than 50 Custom Actions and all
[WiX-users] How to Specify the Installation Database Summary Title in WiX...
Hi, Can anyone please help me out with how to specify an installation database Summary Title (and other properties there) using WiX source? This title appears in the property dialog box under the Summary tab as shown below: [cid:image001.jpg@01C76A57.FB7C12E0] Regards, Muhammad Asim Ghaznawi attachment: image001.jpg - 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] Should we write the applet to JDK 1.
Figure 1 illustrates an example of the exchange of messages in that configuration. When it does so, the active JRE in the Java control panel changes to match, and things work fine. ComparisonType type, Date date, int. Frank Klaus: Is it possible to start Internet Explorer 6 from the command line with a command switch that determines which Java plugin should be used? Generating an XML Signature This section will show you how to use the API to generate an XML signature over the contents of the PurchaseOrder element that the article introduced earlier. You can verify this by using the JAXP Transformer API to dump the contents of the document to a file, as Code Sample 4 shows. Therefore, other applications such as Java Web Start will be able to read and write to that directory as well. Calvin Cheung: Please refer to the Java Web Start 1. JPEGImageReader class, which made for huge gains in scalability and performance of reading JPEG images. Which search result position gets the most clicks? 0 - Lightbulb's Service Provider - Conclusion - Acknowledgment - References SAML 2. Calvin Cheung: We no longer support the Java Plug-in 1. It can also sign only a portion or a subset of an XML document rather than the entire document. If NameID does not correspond to a user account, the script redirects the browser to the login page (prompt. Recommended resources Get top search engine rankings, more customers and more sales IBP 9. The behavior is implementation-dependent. Excellent Good Fair Poor Comments: Your email address (no reply is possible without an address): Sun Privacy Policy Note: We are not able to respond to all submitted comments. But assuming Oh, gee, I think if I change this, it will go faster is usually counterproductive in Java programming. The abstract RowFilter class has one method that is used for filtering: boolean include(RowFilter. 2 or newer JRE versions. But garbage collectors have greatly improved, and the cost now of allocating an object in the Java language is less expensive than in C by a factor of four or five, according to data I've seen. To be listed on the first result page on Google and other major search engines, optimize the content of your web pages and make sure that your web site has good inbound links. A dialog box can be either modeless or modal. getInstance(JKS); ks. You would replace setUserID() with the function that sets the user name in your application. Marina Sum is a staff writer for Sun Developer Network. Brian GoetzTechnology Evangelist, Sun Microsystems Java SE 6 has a lot of nice performance improvements with many optimizations. Calvin Cheung: Please refer to the Java Web Start 1. Figure 6 shows an example. getEntry (mykey, new KeyStore. Here's a program, FilterTable, that uses a regexFilter to filter table content: import javax. Finally, how much can someone use, exploit or crack my applet (without source code). ] Most companies, including ours, spend a great deal of time trying to turn our brands into household names. Should we write the applet to JDK 1. I'm not saying that the Java compiler is too dumb to translate clever code into the appropriate machine code. parse (new FileInputStream(purchaseOrder. perversely.gif Description: GIF image - 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] Intercepting SQL errors and displaying custom error
Don Tasanasanta wrote: I can't seem to find this in my version of WiX 2.0.4820.0 The CAs weren't made localizable in v2, only in v3. You'd have to rebuild sca.wixlib to replace the strings. -- 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] Call 3rd party dll from C++ Custom Action
Chuck wrote: Is it possible to call a third party dll, included in my installer as a binary file only, from a custom action that is in a C++ dll? No. MSI extracts one file at a time as needed to execute a CA. If that isn't possible is that anyway to access a 3rd party dll from my custom action prior to the installation of files? You can extract it yourself, to a secure location appropriate for the user's rights (e.g., on an admin-ACL'd directory when the user is an admin; otherwise local temp). It's not recommended, as it's difficult to get right. -- 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] How to Specify the Installation Database Summary Title in WiX...
Muhammad Ghaznawi wrote: Can anyone please help me out with how to specify an installation database Summary Title (and other properties there) using WiX source? This title appears in the property dialog box under the Summary tab as shown below: Most of them can be set via attributes on the Package element. The Title can't be set, however, as the doc doesn't say it's user-defined data. -- 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
[WiX-users] Merge Modules and Directory
Hi I have several merge modules which I am placing inside a single MSI. These modules were originally their own MSI, but have converted them to MSM. A couple of these WIX scripts has multiple directory tags. Doing some reading on the MS website (http://msdn2.microsoft.com/en-us/library/aa367787.aspx) one of the first points there states that each merge module must have a single root directory. Using some various values of the directory it never seems to place files which are out of the TARGETDIR in their correct location. It seems this is in keeping with the MS statement above. How do I then have a merge module which might put files in multiple directories? eg, my main installation path and System32 or AppData etc... Also, is it possible to patch these modules/msi? TIA Jason - 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
FWIW, I'm totally with Dhaval on the idea that managed custom actions would be a good thing. It just makes a lot of sense. I think it makes a lot more sense than supporting scripts, which as Rob has pointed out many times, are just asking for trouble if you try to use them. Having C++ as the only viable alternative is very limiting. I also agree with some of the other points raised that CAs in general are hard to write because they require you to design for the compensating transaction programming model and that isn't easy to get right. That doesn't make managed CAs any less appealing though. It just means they aren't a slam dunk, any more than the current supported approaches to writing CAs are. Still, anything that is hard to do in managed code is likely even harder to do well in native C++. The number of skilled C++ developers is likely to be dwarfed by the number of skilled managed code developers. The real issue (as Rob mentioned) is that WI doesn't support it and until the product does, it isn't too appealing to try to support them in WiX. It is very hard to get right for the reasons Rob stated and therefore probably not worth doing at all. The other problem with WiX adding its own support is that the approach would be proprietary to WiX and therefore would not translate to future WI implementations, leaving the current WiX users stranded. The whole thing makes me sad though. :( Joe K. - Original Message - From: Dhaval Patel [EMAIL PROTECTED] To: Wilson, Phil [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Monday, March 19, 2007 7:02 PM Subject: Re: [WiX-users] C# .dll Thanks for those words of wisdom :) - 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
I also agree with Dhaval Patel and with Joe Kaplan's observations. No time soon do I intend to become a C++ elitist. This has always been something that puzzled me, over the last 22 months: that the Windows Installer and .NET are on a slightly different course. I take the point about .NET versions and shell extensions (and I take the word of others that CAs built in .NET would make the WI go wonky), but I would expect that increasing complexity of applications and the OS and platform mix was entirely predictable, and that Clickonce or Xcopy deployment was not going to make any significant change to that. Or have they? It seems to me that there's an increasing interest in WiX for solving some of the complexity problems. Ian Thomas GeoSciSoft - Perth, Australia -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Tuesday, March 20, 2007 2:14 PM To: Dhaval Patel; Wilson, Phil Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll FWIW, I'm totally with Dhaval on the idea that managed custom actions would be a good thing. It just makes a lot of sense. I think it makes a lot more sense than supporting scripts, which as Rob has pointed out many times, are just asking for trouble if you try to use them. Having C++ as the only viable alternative is very limiting. I also agree with some of the other points raised that CAs in general are hard to write because they require you to design for the compensating transaction programming model and that isn't easy to get right. That doesn't make managed CAs any less appealing though. It just means they aren't a slam dunk, any more than the current supported approaches to writing CAs are. Still, anything that is hard to do in managed code is likely even harder to do well in native C++. The number of skilled C++ developers is likely to be dwarfed by the number of skilled managed code developers. The real issue (as Rob mentioned) is that WI doesn't support it and until the product does, it isn't too appealing to try to support them in WiX. It is very hard to get right for the reasons Rob stated and therefore probably not worth doing at all. The other problem with WiX adding its own support is that the approach would be proprietary to WiX and therefore would not translate to future WI implementations, leaving the current WiX users stranded. The whole thing makes me sad though. :( Joe K. - Original Message - From: Dhaval Patel [EMAIL PROTECTED] To: Wilson, Phil [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Monday, March 19, 2007 7:02 PM Subject: Re: [WiX-users] C# .dll Thanks for those words of wisdom :) - 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 19/03/2007 11:49 AM - 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
