date:20080221

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Simon Topley

Thanks Mike,

Plenty to run with there. Correct me if I'm wrong but it still seems the
upshot is that non admins will not be allowed to make changes in these
restricted directories? We are not so worried about multiple user
switching as these files are generally only used for our customers to
play with. They do sometimes evolve into production systems but even in
this case our software can handle multiple user as we have a check in /
out policy internal to the software which prevents concurrency issues. A
common app folder would still be preferred but I am unable to find one.

I wonder how many users in the world have admin rights, certainly in the
past a lot of people just curb all the access restrictions and make
users admins. I'm not sure I've ever used any of the shades of grey
privilege accounts, why make life hard for yourself. There in lays the
difference between doing the right thing and doing the easy thing, maybe
that's why communism failed.

Simon

-Original Message-
From: Mike Dimmick [mailto:[EMAIL PROTECTED] 
Sent: 21 February 2008 23:57
To: Simon Topley; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Vista, C Root, Hello world, Windows 3.1

For some reason a lot of developers are having trouble with
understanding UAC. UAC isn't just the prompt, it's a bunch of features
designed to ensure only those things that need to run with high
privilege do so, that other programs can't interfere with the
high-privileged programs, and some additional features to try to help
work around the changes for legacy programs.

The best thing to do for any new code is not to be considered a legacy
program. To do this, your programs - all of them - need a manifest
describing their privilege requirements. The way to do this is described
at http://msdn2.microsoft.com/en-us/library/bb756929.aspx. 99.9% of
programs should be marked 'asInvoker', the remaining 0.1% which are
actually used to administer your system marked as
'requireAdministrator', and anything that would require
'highestAvailable' should be split into a regular program that can run
with normal privileges and a small bit that must run with administrative
privileges, to configure those settings.

You could, of course, simply set 'requireAdministrator' on everything
and annoy your users every time they run the program with a UAC prompt.
But it's against the spirit of trying to get everything running with the
lowest privileges possible, so that if a remote code execution bug (at
worst) is found and exploited, it can only trash the user's profile, not
the whole system.

Windows NT has always had a security system, it's just that most people
didn't use it because it was too much bother, largely because
applications expected to be able to write anywhere and failed in unusual
ways if they couldn't. I used to use Windows XP as a standard user - I
still do at work - and it can be a lot of pain. Vista UAC makes it much
easier to run with low privileges most of the time and only invoke
higher privileges when you need them.

You're definitely on the right lines with moving files that all users
need to write to the Common Application Files folder, but you should
question whether all users on the same machine really need to write to
the same file or registry key. There really is no harm in having
separate configurations for each user, and it may surprise users if a
setting changes because a different user changed it. You could get into
really odd scenarios with Fast User Switching or Terminal Services, if
settings can change under a running copy of the program.

Modifying a file written by Windows Installer can have a surprising
effect - it may not be overwritten when you install an upgrade,
depending on when you schedule RemoveExistingProducts (I think).
Modifying a key can be similar - there is no versioning involved,
registry key updates always overwrite. I would recommend treating
whatever is installed as immutable except by the next version of the
installer.

--
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Topley
Sent: 19 February 2008 15:51
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Where do I begin...

First off I suppose I should say hello, it's been ages since I posted as
our lovingly tailored installers have been carefree for sometime now.

Here is my problem... Vista.


The information contained in this e-mail is likely to be confidential and
may be legally privileged. It is intended only for the addressee. If you
have received this message in error please notify the sender immediately at
the above address. The disclosure, copying or distribution of this message
or its contents without the prior approval of Wallingford Software is
strictly prohibited. Wallingford Software is not liable for
unauthorised disclosures nor for subsequent actions or omissions in reliance
upon them.

Registered in the UK, company no: 02288719
Wa

Re: [WiX-users] Setting Estimated Size and Version

2008-02-21 Thread Rob Mensching

1. ARPSIZE is set magically by ARP. There is no real way to control it. 
Raymond Chen (Master of all things Shell) had a fun blog entry about how 
ARP calculated the size it displayed there. The fact that it took him a 
couple paragraphs is telling.

2. AFAIK, the ARP Version is controlled by the Product/@Version 
(ProductVersion in MSI speak).

PS: In case you didn't know, ARP is the Shell team's fault not the 
Windows Installer team's fault.

Ahn Ahn Liu wrote:
>
> I was wondering if it was possible to set the size and version that 
> shows up for a given program in ARP when I set ARPSYSTEMCOMPONENT to 
> 1. For size, it seems like setting ARPSIZE or EstimatedSize has no 
> effect. I’m also unsure how to set the Version. Does anybody have an idea?
>
> Thanks!
>
> 
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> 
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry permissions messed up after installing package

2008-02-21 Thread Arild Bakken

>> Hi,

>> I'm authoring an installer package that need to register a couple of DLLs in 
>> the registry (traditionally done by regsvr32). I used heat.exe to generate 
>> the
>>  
>> After installing the package:
>>   Administrator (Full control - not inherited) (the user, not the group)
>>   System (Full control - not inherited)
>>   Administrators (Full control - not inherited)
>>   RESTRICTED (Read - not inherited)

> Ok, I figured this one out. It's not a WiX issue, but this is how Windows 
> installer does it when you install a package that is "Just for me" as opposed 
> to "Everyone". I assume it is OK, it just looked very strange to me.

> By adding the ALLUSERS property and setting the value to 2 (meaning install 
> and make available to everyone) it works as expected. The thing is that I had 
> no UI so I completely forgot about that setting.


And some additional info in case others are wondering how this works.

ALLUSERS should be set to 1 to enforce per-machine installation. The value 2 
will attempt a per-machine installation and revert to per-user if the 
installing user does not have the privileges to perform per-machine 
installation (except on Vista where it will fail instead of revert if the 
installing user fails to provide proper credentials to the UAC).

And regarding the registry and permissions, when doing a per-user installation 
the registry keys are written to HKCU\Software\Classes and the HKCR key 
reflects the merged version from HKLM\Software\Classes and 
HKCU\Software\Classes. That's why the permissions looked strange, but they were 
of course only for _my_ user and not for everyone.


Arild
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry permissions messed up after installing package

2008-02-21 Thread Arild Bakken

> Hi,

> I'm authoring an installer package that need to register a couple of DLLs in 
> the registry (traditionally done by regsvr32). I used heat.exe to generate the
>  
> After installing the package:
>   Administrator (Full control - not inherited) (the user, not the group)
>   System (Full control - not inherited)
>   Administrators (Full control - not inherited)
>   RESTRICTED (Read - not inherited)

Ok, I figured this one out. It's not a WiX issue, but this is how Windows 
installer does it when you install a package that is "Just for me" as opposed 
to "Everyone". I assume it is OK, it just looked very strange to me.

By adding the ALLUSERS property and setting the value to 2 (meaning install and 
make available to everyone) it works as expected. The thing is that I had no UI 
so I completely forgot about that setting.


Regards,

Arild
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Setting Estimated Size and Version

2008-02-21 Thread Ahn Ahn Liu

I was wondering if it was possible to set the size and version that shows up 
for a given program in ARP when I set ARPSYSTEMCOMPONENT to 1.  For size, it 
seems like setting ARPSIZE or EstimatedSize has no effect.  I'm also unsure how 
to set the Version.  Does anybody have an idea?

Thanks!

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Name of the msi with in the install file

2008-02-21 Thread vishnum


Hello:

And where does OriginalDatabase property gets set (As in after/before which
event).


Thanks,
Vishnu
-- 
View this message in context: 
http://www.nabble.com/Name-of-the-msi-with-in-the-install-file-tp15583249p15627797.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread si

Hi Richard,

>  These all seem like very reasonable feature requests for WiX as an
>  extension/adjunct to the existing XmlConfig actions.

Agreed. We'd prefer not have to code this ourselves and worry about
custom actions.

>  I'm assuming that the XmlTidy action is only because when WiX edits an
>  XML file, it does unwanted things to the whitespace in the XML file?

Correct. On installs it can create elements without adding a CRLF to
the parent element. On uninstalls it doesn't remove CRLF from deleted
elements. So I end up using Visual Studio "Format Document" command
(Ctrl+E, D) quite often when testing. This fixes the first problem
(for testing, not for deployment) but not the later.

>  I'd treat that more as a bug to XmlConfig/XmlFile.

Agreed, although I posted to this list recently about this - subject
heading "Xml Beautifier" - and it didn't elicit much response so I
didn't bother filing an issue. Perhaps it was poorly written.

>  What about this: would you be happy with a tool that took two XML
>  files, a "before" and "after" version, and processed the differences
>  to generate the appropriate XmlConfig/XmlFile nodes?

Yes, that's an excellent idea!

The "before" file wouldn't have to be the whole configuration file,
just the elements and attributes needed for the xpath queries.

>  That could be part of your build process so that ongoing iterative
>  changes could be incorporated automatically.

Sounds good, and thanks for your input. Shall I go ahead and create a
feature request for this tool?

cheers
si

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread Richard

In article <[EMAIL PROTECTED]>,
si <[EMAIL PROTECTED]>  writes:

> What I'd like is something as simple as the XmlPoke and XmlPeek tasks
> that are found in NAnt. [...]
> We'd also like an XmlBulkAdd action i.e.
> adding well-formed elements and attributes instead of having to treat
> each element value or attribute invidually.  With those actions I
> could get my wxs file mentioned above down to less than 100 lines,
> making it easier to develop, understand, test and maintain.
> 
> We'd also write an XmlTidy action [...]

These all seem like very reasonable feature requests for WiX as an
extension/adjunct to the existing XmlConfig actions.

I'm assuming that the XmlTidy action is only because when WiX edits an
XML file, it does unwanted things to the whitespace in the XML file?

I'd treat that more as a bug to XmlConfig/XmlFile.

What about this: would you be happy with a tool that took two XML
files, a "before" and "after" version, and processed the differences
to generate the appropriate XmlConfig/XmlFile nodes?

That could be part of your build process so that ongoing iterative
changes could be incorporated automatically.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download

Legalize Adulthood! 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Failing gracefully from ServiceControl?

2008-02-21 Thread KStuart

I haven't been using windows installer/wix very long so am a little confused,
from what I can see the default behaviour of the install sequence is to
process all files before attempting to start any services, therefore if your
product includes dependent assemblies they will already have processed
before the StartServices action, in fact starting services is close to the 
last action in the install sequence, of course you can always move it
further back.

If you're installing several services are you sure you don't have any
inter-service dependencies you're not taking care of?

You can always check if the dependencies are already installed and skip
trying to start the service if they are not, but like I said, if your
product is installing those assemblies anyhow it shouldn't be an issue.

Geoff Finger-2 wrote:
> 
> I've got several services I'm trying to install. If I add
> "Start='install'" to the ServiceControl element then it will try to
> start them, but it will almost always fail with a 1920 error. I'm
> pretty sure this is because some of the services are dependent on
> side-by-side assemblies that are being installed at the same time and
> so won't be available until the install actually finishes.
> 
> However is there a way to make it so that it will attempt to start the
> services but _not_ force a rollback if it fails? There are at least
> some circumstances where the assemblies might already have been
> installed by another package and it would be nice to at least make the
> attempt. There doesn't seem to be any "Vital" attribute for the
> ServiceControl element that I can set to "no." There is a "Vital" for
> ServiceInstall, but I can't set that to "no" even if it would fix the
> above problem, because it _is_ vital that they at least install
> properly, even if they don't start right away, and the same goes for
> "ErrorControl" in the ServiceInstall element as well I think.
> 
> As an added bonus, if the above can be done is there also a way to do
> the service start step silently? We're expecting it to fail most of
> the time so there's no need to pop up an error message about it if it
> does.
> 
> Thanks!
> 
> And here's the code I've got in case it matters:
> 
>  DisplayName="$(loc.IDS_SERVER) $(var.MAJORVER).$(var.MINORVER)"
> Description="$(loc.IDS_SERVER_SERVICE)
> $(var.MAJORVER).$(var.MINORVER)" Name="ServerService"
> ErrorControl="normal" Start="auto" Type="ownProcess" Vital="yes">
>   
> 
> 
>  Start="install" Stop="uninstall" Remove="uninstall" />
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Failing-gracefully-from-ServiceControl--tp15624384p15626152.html
Sent from the wix-users mailing list archive at Nabble.com.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: Conditional Custom Actions

2008-02-21 Thread Alexander Shevchuk

What about maintenance mode?
If you want to run it on install only, add condition to your custom action:


  Not Installed




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sina Hakami
Sent: Thursday, February 21, 2008 5:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Conditional Custom Actions

Hi
I'm totally new to MSI and WIX, and I want the MSI to run an executable
(.EXE file) during the installation process, but not when the application is
being uninstalled. So I used a custom action, and put it inside
InstallExecuteSequence, but I don't know what should I do to prevent it from
running during uninstall. This is the general format of my WXS file.




















-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FW: Conditional Custom Actions

2008-02-21 Thread Sina Hakami

Hi
I'm totally new to MSI and WIX, and I want the MSI to run an executable
(.EXE file) during the installation process, but not when the application is
being uninstalled. So I used a custom action, and put it inside
InstallExecuteSequence, but I don't know what should I do to prevent it from
running during uninstall. This is the general format of my WXS file.




















-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread Christopher Painter

I read earlier that someone said that the MSI team issued a `requirement` to
not use managed code. Also to say it's a best practice to not use managed
code is a stretch of the truth also. The future of Windows development is
managed code and I've found very successful ways to incorporate it into my
installs. Anyone who tells me otherwise simply isn't thinking outside of the
box or just likes the torture of writing raw C++ Win32 code.

si <[EMAIL PROTECTED]> wrote:
Hi Bob,

I don't want to get into a religious argument over this, and Dana, yes
I have read about the potential problems, I'm just looking for avenues
to explore to get our development team on the right path. We use C#
for almost everything else, so it's natural for us to want to use this
language if at all possible, especially since Votive works so well in
Visual Studio.

> How would C# make it easier to support uninstall, repair, rollback,
> upgrades, and patching?

I'm not a WiX or windows installer expert, but for what we want to do
with the managed actions; uninstall and rollback would be probably
treated the same i.e. leave everything as it was, likewise for
upgrades and patches. Not sure about repair.

I was actually talking more about leveraging our existing tools for
debugging (e.g. log4net) as well as the tools that ship with .NET i.e.
the Base Class Libraries.

> What are some examples of grunt work?

Sure. One example is our companies custom security and data extensions
for Microsoft Reporting Services. Because this is an existing
product, we can't just overwrite the xml configuration files that
exist with our own versions.

To take the RSSrvPolicy.config as an example, I have nearly 1,000
lines of XmlConfig code in the wxs file related to just 22 xml
elements! This is one of six configuration files we have to modify.
To be fair it's the largest but they all take time to develop and more
importantly, because the idiosyncrasies of XmlConfig are difficult to
develop and debug.

Even Microsoft's own developers have problems with this:
http://blogs.msdn.com/gisenberg/archive/2007/10/09/wix-v3-and-xmlconfig-xmlfile-troubleshooting.aspx

What I'd like is something as simple as the XmlPoke and XmlPeek tasks
that are found in NAnt. We'd also like an XmlBulkAdd action i.e.
adding well-formed elements and attributes instead of having to treat
each element value or attribute invidually. With those actions I
could get my wxs file mentioned above down to less than 100 lines,
making it easier to develop, understand, test and maintain.

We'd also write an XmlTidy action - a few lines of C# thanks to the
BCL - so that the xml files are left in a clean state after being
touched, as anyone who has spent time with XmlFile and XmlConfig
knows, they get messy quickly. Yes, no problem for a parser, but a
pain for humans.

If it's true that a Microsoft supported WiX variant will be in the
next version of Visual Studio, expect a lot more of these sort of
requests from other .NET developers in the not-to-distant future :)

cheers
si
--
It's a wild world that we live in, you step to the vibe like a new
found religion, take your position, compile your vision, futurism,
algorithm has risen up! pfm - the western

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] defining one property before another

2008-02-21 Thread KStuart

Looking at the install log (msiexec /lvx install.log /i installer.msi) is a
good starting point for working things like this out, you can easily see
which actions fire when and what task(s) each action is performing, so with
that in mind an install log will show that searches (registry or directory)
are triggered during the AppSearch action, therefore...

... should do the trick.

Don Tasanasanta (Volt) wrote:
> 
> I know there has to be a trick to this but...
> 
> How do you ensure that one property is defined before another property is
> defined?
> 
> I have a property that reads a value from the registry
> 
> And a second property that defines a directory based on the registry
> property
> 
> I want to make sure the reg property is defined before defining the
> directory property or else my directory will point to the wrong place.
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defining-one-property-before-another-tp15625171p15625458.html
Sent from the wix-users mailing list archive at Nabble.com.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] defining one property before another

2008-02-21 Thread Alexander Shevchuk

I am assuming you're using custom action Type 51 to set the second property's 
value.  Just schedule it after the AppSearch standard action.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta 
(Volt)
Sent: Thursday, February 21, 2008 4:54 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] defining one property before another

I know there has to be a trick to this but...

How do you ensure that one property is defined before another property is 
defined?

I have a property that reads a value from the registry

And a second property that defines a directory based on the registry property

I want to make sure the reg property is defined before defining the directory 
property or else my directory will point to the wrong place.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread si

Hi Bob,

> How would C# make it easier to support uninstall, repair, rollback,
> upgrades, and patching?

I was actually talking more about leveraging our existing tools for
debugging (e.g. log4net) as well as the tools that ship with .NET i.e.
the Base Class Libraries.

> What are some examples of grunt work?

Even Microsoft's own developers have problems with this:
http://blogs.msdn.com/gisenberg/archive/2007/10/09/wix-v3-and-xmlconfig-xmlfile-troubleshooting.aspx

cheers
si
--
It's a wild world that we live in, you step to the vibe like a new
found religion, take your position, compile your vision, futurism,
algorithm has risen up!pfm - the western

[WiX-users] Light... could spare me some time!

2008-02-21 Thread Aurélien DEROUINEAU

I build packages with two media components:

 







 

And here is a sample Component/File couplet that I use:

 







 

 

The problem is that when building the project, the FIL files are put in the
right folder (\files), however Windows Installer looks for them inside
the root folder and not the files subfolder, which is rather frustrating:
Ive been trying to hack around with it but no luck came out. Hopefully you
can show me the light.

 

 

Also, another annoyance: FIL files amount for a few gigabytes, and it seems
that light tries to copy them to my files subfolder each time I compile,
even though no changes have been made to these files! Is there a way to
restrain light from copying them every time to save compilation time?

 

Thanks a bunch.

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] defining one property before another

2008-02-21 Thread Don Tasanasanta (Volt)

I know there has to be a trick to this but...

How do you ensure that one property is defined before another property is 
defined?

I have a property that reads a value from the registry

And a second property that defines a directory based on the registry property

I want to make sure the reg property is defined before defining the directory 
property or else my directory will point to the wrong place.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Failing gracefully from ServiceControl?

2008-02-21 Thread Geoff Finger

I've got several services I'm trying to install. If I add
"Start='install'" to the ServiceControl element then it will try to
start them, but it will almost always fail with a 1920 error. I'm
pretty sure this is because some of the services are dependent on
side-by-side assemblies that are being installed at the same time and
so won't be available until the install actually finishes.

However is there a way to make it so that it will attempt to start the
services but _not_ force a rollback if it fails? There are at least
some circumstances where the assemblies might already have been
installed by another package and it would be nice to at least make the
attempt. There doesn't seem to be any "Vital" attribute for the
ServiceControl element that I can set to "no." There is a "Vital" for
ServiceInstall, but I can't set that to "no" even if it would fix the
above problem, because it _is_ vital that they at least install
properly, even if they don't start right away, and the same goes for
"ErrorControl" in the ServiceInstall element as well I think.

As an added bonus, if the above can be done is there also a way to do
the service start step silently? We're expecting it to fail most of
the time so there's no need to pop up an error message about it if it
does.

Thanks!

And here's the code I've got in case it matters:







-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop

2008-02-21 Thread Paul McLaughlin

Google cached it:

 

http://209.85.173.104/search?q=cache:9Hg8CQyYJXkJ:robmensching.com/blog/arch
ive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx+How
+to+create+an+uninstall+shortcut+and+pass+all+the

&hl=en&ct=clnk&cd=1&gl=us

 

-Paul

 

From: Dan Hoeger [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 21, 2008 12:41 PM
To: Bob Arnson; Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Help with ICE38 and KeyPath installing to a folder
on the Desktop

 

I can't connect to Rob's Blog archive for some reason and he's Out of the
office right now.

 

I'm running into this same error and need to resolve this ASAP.

 

Does anyone have the text?

 

Thanks,

 

Dan

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, January 23, 2008 9:54 PM
To: Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder
on the Desktop

 

Paul McLaughlin wrote: 

test.wxs(18) : error LGHT0204 : ICE38: Component idTestProgram installs to
user profile.

It must use a registry key under HKCU as its KeyPath, not a file.

 

 

 

I tried learning what KeyPath means, but I can't find anything that really
talks about it in the WiX help file.  Many topics refer to it, but I can't
find what ICE38 is and why I need a registry key, and I still don't know
what a KeyPath means.


WiX doesn't do much on documenting MSI concepts; for those, you want/need
the MSI SDK. KeyPath is a column in the Component table:
http://msdn2.microsoft.com/en-us/library/aa368007(VS.85).aspx.

See
http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-s
hortcut-and-pass-all-the.aspx for the oddities of ICEs and resources
installed into the user profile. 

-- 
sig://boB
http://joyofsetup.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Mike Dimmick

For some reason a lot of developers are having trouble with understanding
UAC. UAC isn't just the prompt, it's a bunch of features designed to ensure
only those things that need to run with high privilege do so, that other
programs can't interfere with the high-privileged programs, and some
additional features to try to help work around the changes for legacy
programs.

The best thing to do for any new code is not to be considered a legacy
program. To do this, your programs - all of them - need a manifest
describing their privilege requirements. The way to do this is described at
http://msdn2.microsoft.com/en-us/library/bb756929.aspx. 99.9% of programs
should be marked 'asInvoker', the remaining 0.1% which are actually used to
administer your system marked as 'requireAdministrator', and anything that
would require 'highestAvailable' should be split into a regular program that
can run with normal privileges and a small bit that must run with
administrative privileges, to configure those settings.

You could, of course, simply set 'requireAdministrator' on everything and
annoy your users every time they run the program with a UAC prompt. But it's
against the spirit of trying to get everything running with the lowest
privileges possible, so that if a remote code execution bug (at worst) is
found and exploited, it can only trash the user's profile, not the whole
system.

Windows NT has always had a security system, it's just that most people
didn't use it because it was too much bother, largely because applications
expected to be able to write anywhere and failed in unusual ways if they
couldn't. I used to use Windows XP as a standard user - I still do at work -
and it can be a lot of pain. Vista UAC makes it much easier to run with low
privileges most of the time and only invoke higher privileges when you need
them.

You're definitely on the right lines with moving files that all users need
to write to the Common Application Files folder, but you should question
whether all users on the same machine really need to write to the same file
or registry key. There really is no harm in having separate configurations
for each user, and it may surprise users if a setting changes because a
different user changed it. You could get into really odd scenarios with Fast
User Switching or Terminal Services, if settings can change under a running
copy of the program.

Modifying a file written by Windows Installer can have a surprising effect -
it may not be overwritten when you install an upgrade, depending on when you
schedule RemoveExistingProducts (I think). Modifying a key can be similar -
there is no versioning involved, registry key updates always overwrite. I
would recommend treating whatever is installed as immutable except by the
next version of the installer.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley
Sent: 19 February 2008 15:51
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Where do I begin...

First off I suppose I should say hello, it's been ages since I posted as
our lovingly tailored installers have been carefree for sometime now.

Here is my problem... Vista.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] INstall SQL Database

2008-02-21 Thread Alexander Shevchuk

Try this:










From: Eric Latendresse [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 21, 2008 2:47 PM
To: Alexander Shevchuk; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] INstall SQL Database

Thanks for your reply, but now I get the error:

error CNDL0005 : The CreateFolder element contains an unexpected child element 
'sql:SqlDatabase’


Eric

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander 
Shevchuk
Sent: Thursday, February 21, 2008 4:29 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] INstall SQL Database

Hi Eric,

Add  around .   is a custom 
action and Windows Installer will not create an empty folder unless it will be 
forced to do so with explicit :










Alex


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse
Sent: Thursday, February 21, 2008 2:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] INstall SQL Database

I am trying to create a SQL database as a separate component. I know that it is 
probably something simple maybe you could take a look at the attached and point 
me in the right direction. Basically I want to install the SQL Data and Log 
files in a sub directory to the Main application folder. Attached is my wxs. 
The error that I get is:

“The Directory/Component pair must be listed in the CreateFolders table”


Eric

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] INstall SQL Database

2008-02-21 Thread Eric Latendresse

Thanks for your reply, but now I get the error:

 

error CNDL0005 : The CreateFolder element contains an unexpected child element 
'sql:SqlDatabase’

 

 

Eric 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander 
Shevchuk
Sent: Thursday, February 21, 2008 4:29 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] INstall SQL Database

 

Hi Eric,

 

Add  around .   is a custom 
action and Windows Installer will not create an empty folder unless it will be 
forced to do so with explicit :

 















 

 

Alex

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse
Sent: Thursday, February 21, 2008 2:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] INstall SQL Database

 

I am trying to create a SQL database as a separate component. I know that it is 
probably something simple maybe you could take a look at the attached and point 
me in the right direction. Basically I want to install the SQL Data and Log 
files in a sub directory to the Main application folder. Attached is my wxs. 
The error that I get is:

 

“The Directory/Component pair must be listed in the CreateFolders table”

 

 

Eric 

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Feature Tree - Redundant Options ?

2008-02-21 Thread Tom.Chmielenski

I have a simple feature tree with a couple of features, where each of
these features have no sub-features.
Code fragment currently looks like this:



This give the user gets three options to select from:

1.  Will be Installed on local hard drive
2.  Entire Feature will be installed on local hard drive
3.  Entire Feature will be unavailable.

But since these features has no subfeatures,
option 1 and 2 are redundant.
Is there any way to show just Options (1 and 3) or (2 and 3)?

I played with the attributes on the Feature element, 
but I can't figure it out. Maybe it is not possible?

Thanks in advance.
Tom

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] INstall SQL Database

2008-02-21 Thread Alexander Shevchuk

Hi Eric,

Add  around .   is a custom 
action and Windows Installer will not create an empty folder unless it will be 
forced to do so with explicit :










Alex


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse
Sent: Thursday, February 21, 2008 2:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] INstall SQL Database

I am trying to create a SQL database as a separate component. I know that it is 
probably something simple maybe you could take a look at the attached and point 
me in the right direction. Basically I want to install the SQL Data and Log 
files in a sub directory to the Main application folder. Attached is my wxs. 
The error that I get is:

“The Directory/Component pair must be listed in the CreateFolders table”


Eric Latendresse
Optimum Solutions, Inc.
(615) 369-6097 office
(615) 329-4448 fax
[EMAIL PROTECTED]
www.optimum-solutions.com
Payroll ∙ HR ∙ Time & Attendance
Made Simple.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] INstall SQL Database

2008-02-21 Thread Eric Latendresse

I am trying to create a SQL database as a separate component. I know that it is 
probably something simple maybe you could take a look at the attached and point 
me in the right direction. Basically I want to install the SQL Data and Log 
files in a sub directory to the Main application folder. Attached is my wxs. 
The error that I get is:

 

"The Directory/Component pair must be listed in the CreateFolders table"

 

 

Eric Latendresse

Optimum Solutions, Inc.

(615) 369-6097 office

(615) 329-4448 fax

[EMAIL PROTECTED]

www.optimum-solutions.com  

Payroll ∙ HR ∙ Time & Attendance
Made Simple.

 



SuiteSetup.wxs
Description: SuiteSetup.wxs
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Not detecting correct version of aspnet_regiis.exe

2008-02-21 Thread Luke Bakken

>  
> Key="SOFTWARE\Microsoft\.NETFramework" Name="InstallRoot" Type="raw">
>   Depth="1">
> MinVersion="2.0.50727.42"/>
> 
>   
> 

Here's what I'm using, it appears to work OK:



  



  



  



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop

2008-02-21 Thread Richard.Foster

Dan,
 
I believe the information you need is also captured on the WiX wiki -
see http://wix.mindcapers.com/wiki/ICE38
 
Hope this helps,
Regards,
Richard



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Hoeger
Sent: Thursday, February 21, 2008 3:41 PM
To: Bob Arnson; Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a
folder on the Desktop



I can't connect to Rob's Blog archive for some reason and he's Out of
the office right now.

 

I'm running into this same error and need to resolve this ASAP.

 

Does anyone have the text?

 

Thanks,

 

Dan

 




* 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. Quixote 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.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop

2008-02-21 Thread Alexander Shevchuk

You need to create a dummy registry key under HKCU, something like:








From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hoeger
Sent: Thursday, February 21, 2008 12:41 PM
To: Bob Arnson; Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on 
the Desktop

I can't connect to Rob's Blog archive for some reason and he's Out of the 
office right now.

I'm running into this same error and need to resolve this ASAP.

Does anyone have the text?

Thanks,

Dan

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, January 23, 2008 9:54 PM
To: Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on 
the Desktop

Paul McLaughlin wrote:
test.wxs(18) : error LGHT0204 : ICE38: Component idTestProgram installs to user 
profile.
It must use a registry key under HKCU as its KeyPath, not a file.



I tried learning what KeyPath means, but I can't find anything that really 
talks about it in the WiX help file.  Many topics refer to it, but I can't find 
what ICE38 is and why I need a registry key, and I still don't know what a 
KeyPath means.

WiX doesn't do much on documenting MSI concepts; for those, you want/need the 
MSI SDK. KeyPath is a column in the Component table: 
http://msdn2.microsoft.com/en-us/library/aa368007(VS.85).aspx.

See 
http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx
 for the oddities of ICEs and resources installed into the user profile.

--

sig://boB

http://joyofsetup.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop

2008-02-21 Thread Dan Hoeger

I can't connect to Rob's Blog archive for some reason and he's Out of the 
office right now.

I'm running into this same error and need to resolve this ASAP.

Does anyone have the text?

Thanks,

Dan

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, January 23, 2008 9:54 PM
To: Paul McLaughlin
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on 
the Desktop

Paul McLaughlin wrote:
test.wxs(18) : error LGHT0204 : ICE38: Component idTestProgram installs to user 
profile.
It must use a registry key under HKCU as its KeyPath, not a file.



I tried learning what KeyPath means, but I can't find anything that really 
talks about it in the WiX help file.  Many topics refer to it, but I can't find 
what ICE38 is and why I need a registry key, and I still don't know what a 
KeyPath means.

WiX doesn't do much on documenting MSI concepts; for those, you want/need the 
MSI SDK. KeyPath is a column in the Component table: 
http://msdn2.microsoft.com/en-us/library/aa368007(VS.85).aspx.

See 
http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx
 for the oddities of ICEs and resources installed into the user profile.


--

sig://boB

http://joyofsetup.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Coniguring Vista HTTP Namespace reservations in WIX

2008-02-21 Thread Damian Mehers

I'm guessing I'm not the only one who will be needing to make HTTP namespace
reservations to allow my application to accept incoming HTTP calls on Vista,
so in case it is of use to anyone else, I've written up some steps to do
this:

http://damianblog.com/2008/02/21/configuring-http-namespace-reservations-on-vista-using-wix/

I actually coded up a custom action initially, only to then discover a much
simpler way of doing it.  I am new to WIX, so any constructive comment is
most welcome.

Damian
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to change the order of InstallSqlData custom action?

2008-02-21 Thread Yancho Yanev

Hello,

We are trying to change the order of our actions and don't have any success so 
far. By default InstallFiles has a sequence number of 4000 and InstallSqlData 
gets the number 4001. We need to run our custom action between these 2 action. 
We tried to explicitly include InstallSqlData in the InstallExecuteSequence and 
give it a different sequence number but it didn't work. What is the way to do 
that?

Thank you,
Yancho
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Localization with WiX3

2008-02-21 Thread Corey Alix


Thanks you!  I was confused by the fact that I was only getting errors with
German, Spanish and Dutch because I thought those translations were
complete.  By adding these missing  items to my own 1031.wxl file I
was able to build an MSI.  

The February 15, 2008 version of the WiX source requires these additions for
a WixUI_InstallDir build (true for Spanish and Dutch as well):


http://schemas.microsoft.com/wix/2006/localization";
Codepage="1252" Culture="de-DE">
[ProductName]
Setup
WixUI_Ico_Info
Information
icon
Installation directory
must be on a local hard drive.
[ProductName] kann nicht entfernt werden.
[ProductName] kann nicht repariert werden.
Ordner|Neuer 
Ordner 


-- 
View this message in context: 
http://www.nabble.com/Localization-with-WiX3-tp15489213p15614709.html
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Simon Topley

Good point. Thanks again Bob. 

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: 21 February 2008 15:47
To: Simon Topley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Simon Topley wrote:
> That does raise a question of how I detect if the user has changed the

> output path. I thought about adding a property to the browse folder 
> click but it is possible a user will browse but not change the output 
> directory. It's not a major problem if we tell them all the time it 
> just would be nicer if it only warned them if they haven't changed the
path.
>   

I wouldn't, simply because then you're in the game of keeping a list of
potential writable-v-not directories.

--
sig://boB
http://joyofsetup.com/

The information contained in this e-mail is likely to be confidential and
may be legally privileged. It is intended only for the addressee. If you
have received this message in error please notify the sender immediately at
the above address. The disclosure, copying or distribution of this message
or its contents without the prior approval of Wallingford Software is
strictly prohibited. Wallingford Software is not liable for
unauthorised disclosures nor for subsequent actions or omissions in reliance
upon them.

Registered in the UK, company no: 02288719
Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Bob Arnson

Simon Topley wrote:
> That does raise a question of how I detect if the user has changed the
> output path. I thought about adding a property to the browse folder
> click but it is possible a user will browse but not change the output
> directory. It's not a major problem if we tell them all the time it just
> would be nicer if it only warned them if they haven't changed the path.
>   

I wouldn't, simply because then you're in the game of keeping a list of 
potential writable-v-not directories.

-- 
sig://boB
http://joyofsetup.com/

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread Bob Arnson

si wrote:
> In particular, XmlFile and XmlConfig are slowly driving us crazy. Part
> of the frustration is knowing how easy it is in C#, part of it is the
> large amount of grunt work you have to do in WiX, especially
> manipulating existing xml. 

How would C# make it easier to support uninstall, repair, rollback, 
upgrades, and patching? What are some examples of grunt work?

-- 
sig://boB
http://joyofsetup.com/

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize

2008-02-21 Thread Bob Arnson

Brian Rogers wrote:
> Please don't mistake the fact that I like using Windows Installer as a 
> tool, I just think it needs to become more robust at this point.

I'm pretty sure nobody's arguing against that.

-- 
sig://boB
http://joyofsetup.com/

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Simon Topley

 That does raise a question of how I detect if the user has changed the
output path. I thought about adding a property to the browse folder
click but it is possible a user will browse but not change the output
directory. It's not a major problem if we tell them all the time it just
would be nicer if it only warned them if they haven't changed the path.

Simon

-Original Message-
From: Simon Topley 
Sent: 21 February 2008 14:43
To: 'Bob Arnson'
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Thanks bob, we have opted to warn the user that installing to the
programfile folder will mean they may have issues with writing. I'd do
something better but our release deadline is speeding towards us and we
will be deploying our tutorial data in a different way for the next
release anyway.

Simon (See you all again in 6 months)

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 16:20
To: Simon Topley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Simon Topley wrote:
> the issue. I have attempted to suggest sensible places we may want to 
> put our files, application data folder for example (if I could find a 
> common one that all users could use). Even the desktop. Sadly everyone

> apart from me is rather keen on using the root of the C drive, or 
> windows drive.

Bad idea for the same reason. If the goal is to write to a directory
that all users can share, delete, overwrite regardless of other users,
you can use CommonAppDataFolder and use PermissionEx to give all users
permissions.

--
sig://boB
http://joyofsetup.com/

The information contained in this e-mail is likely to be confidential and
may be legally privileged. It is intended only for the addressee. If you
have received this message in error please notify the sender immediately at
the above address. The disclosure, copying or distribution of this message
or its contents without the prior approval of Wallingford Software is
strictly prohibited. Wallingford Software is not liable for
unauthorised disclosures nor for subsequent actions or omissions in reliance
upon them.

Registered in the UK, company no: 02288719
Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

2008-02-21 Thread Simon Topley

Thanks bob, we have opted to warn the user that installing to the
programfile folder will mean they may have issues with writing. I'd do
something better but our release deadline is speeding towards us and we
will be deploying our tutorial data in a different way for the next
release anyway.

Simon (See you all again in 6 months)

-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: 19 February 2008 16:20
To: Simon Topley
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1

Simon Topley wrote:
> the issue. I have attempted to suggest sensible places we may want to 
> put our files, application data folder for example (if I could find a 
> common one that all users could use). Even the desktop. Sadly everyone

> apart from me is rather keen on using the root of the C drive, or 
> windows drive.

Bad idea for the same reason. If the goal is to write to a directory
that all users can share, delete, overwrite regardless of other users,
you can use CommonAppDataFolder and use PermissionEx to give all users
permissions.

--
sig://boB
http://joyofsetup.com/

The information contained in this e-mail is likely to be confidential and
may be legally privileged. It is intended only for the addressee. If you
have received this message in error please notify the sender immediately at
the above address. The disclosure, copying or distribution of this message
or its contents without the prior approval of Wallingford Software is
strictly prohibited. Wallingford Software is not liable for
unauthorised disclosures nor for subsequent actions or omissions in reliance
upon them.

Registered in the UK, company no: 02288719
Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread Richard.Foster

Dana wrote:
 
 The best practice is not to use C# managed custom actions at all.  If
you search an archive of this list here:
http://www.nabble.com/wix-users-f4470.html, you'll see plenty of reasons
why this is stated.  

This is not a limitation of WiX, but rather a requirement imposed upon
all of us by using Windows Installer. 
 
While I agree 100% with what Dana wrote, I have to say that the original
poster also has a valid point. There are a lot of things which could
very easily be accomplished using managed code... but it's not supported
(and based on previous discussions is unlikely to *ever* be supported).
Yes, there are challenges associated with the additional dependencies
which managed code drags into the picture, but why on earth do Microsoft
insist on regularly giving us shiny new tools for application
development while not providing similar support (as far as I can tell)
in the management and deployment area? I know that some members of the
Installer team read this list. Would any of you care to comment?
 
Just my rant for the day
 
Regards,
Richard
 



* 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. Quixote 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.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

2008-02-21 Thread Dana Gutride

The best practice is not to use C# managed custom actions at all.  If you
search an archive of this list here:
http://www.nabble.com/wix-users-f4470.html, you'll see plenty of reasons why
this is stated.

This is not a limitation of WiX, but rather a requirement imposed upon all
of us by using Windows Installer.  You need to write your custom actions
preferably in C++, script custom actions are also supported, but no C#
without using hacks to make it work.

Dana

On Thu, Feb 21, 2008 at 2:47 AM, si <[EMAIL PROTECTED]> wrote:

> Greetings,
>
> Does anyone have any good links as to best practice and guidance for
> implementing C# managed custom actions in Wix 3.0?
>
> In particular, XmlFile and XmlConfig are slowly driving us crazy. Part
> of the frustration is knowing how easy it is in C#, part of it is the
> large amount of grunt work you have to do in WiX, especially
> manipulating existing xml. So we're looking for other options to
> ensure that all our developers will embrace WiX, as most of it is
> awesome.
>
> Thanks in advance.
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

40 matches

Mail list logo