Бизнес-робот
Бизнес
робот

Темы:

Архив:

Каталог рекламы и объявлений

Ящик для предложений: sales@blogslov.ru

WiX-devs Digest, Vol 13, Issue 31

Send WiX-devs mailing list submissions to


To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-devs
or, via email, send a message with subject or body 'help' to


You can reach the person managing the list at


When replying, please edit your Subject line so it is more specific
than "Re: Contents of WiX-devs digest..."


Today's Topics:

1. Re: scheduling deferred custom actions for SSRS publication
(Bob Arnson)
2. Re: questions on procedure for submitting changes (Bob Arnson)
3. [ wix-Bugs-1744399 ] NetFx extension uses duplicate RegSearch
IDs (SourceForge.net)
4. [ wix-Feature Requests-1585281 ] Add solution and project
variables back to Votive v3 (SourceForge.net)
5. [ wix-Feature Requests-1743864 ] Change CloseApplication to
support sending close message (SourceForge.net)


----------------------------------------------------------------------

Message: 1
Date: Fri, 29 Jun 2007 07:21:31 -0700
From: Bob Arnson
Subject: Re: [WiX-devs] scheduling deferred custom actions for SSRS
publication
To: Adam Langley
Cc:
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"

Adam Langley wrote:
>
> The code in WiX appears only to read from the MSI tables when
> /installing/, but relies on serialized data from the Metabase upon
> rollback/uninstall, is that correct (Im making a big assumption around
> what on earth the 'MetaBase' is, and what's its for)?
>

Generally, the scheduling CAs run every time, read the custom table
which includes a component reference, and use the state of the component
to determine what to do. For example, if the install state of the
component is 'absent' and the action state is 'install local,' then the
scheduling CA needs to write custom action data to install the widget.
Likewise, 'installed local' to 'absent' means remove the widget and so
on. That makes it fairly easy to support patching and repair too because
you can make the right decision in the same code path. It also means
that CAs don't have to persist much data between installations.

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

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Fri, 29 Jun 2007 07:49:44 -0700
From: Bob Arnson
Subject: Re: [WiX-devs] questions on procedure for submitting changes
To: Kevin Fischer
Cc:
Message-ID:
Content-Type: text/plain; charset="windows-1252"

Kevin Fischer wrote:
> I'm already approved on the assignment agreement. I uploaded the code
> change via a tracker. The entry is at:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1743864&group_id=105970&atid=642717
>

I reviewed the code last night. There are three issues and a question:

1. There are a couple of instances of clashing with the WiX coding style
(e.g., capitalization of identifiers) that I can clean up.

2. You need to modify ext\UtilExtension\wixext\Data\tables.xml to
include new columns in custom tables. That's what WiX uses to actually
create the tables in the .msi database.

3. Notwithstanding #2, the WixCloseApplication table already has an
Attributes column that's not being used. I'd make the CloseMessage and
RebootPrompt columns bits in the Attributes column instead. That avoids
needing to change the table schema at all.

4. It's not clear to me why you created the list of close app entries.
Generally, CAs do that only when they need to pass around the whole list
for processing and need a lifespan longer than the lifespan of a single
function. It doesn't seem necessary for WixCloseApplications: The close
message can be sent from the same loop that reads the
WixCloseApplication table and constructs the custom action data for the
deferred CA. It seems the UI support could even be implemented that way.
Am I missing something?

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

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Wed, 27 Jun 2007 11:45:03 -0700
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1744399 ] NetFx extension uses
duplicate RegSearch IDs
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1744399, was opened at 2007-06-27 12:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1744399&group_id=105970

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: extensions
Group: v3.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jonatin (jonatin)
Assigned to: Scott Kurtzeborn (scotk)
Summary: NetFx extension uses duplicate RegSearch IDs

Initial Comment:
The .NET detection properties in the NetFx extension use duplicate RegSearch IDs when searching for the installation key and the service pack keys.

Example:
RegistrySearch Id="NetFramework11" ... Name="Install" ...
RegistrySearch Id="NetFramework11" ... Name="SP" ...

This causes the following light.exe error when both the installation and SP properties are referenced in a .wxs:

C:\delivery\Dev\wix_public\src\ext\NetFxExtension\wixlib\NetFxExtension.wxs(33): error LGHT0130: The primary key 'NetFramework11' is duplicated in table 'RegLocator'. Please remove one of the entries or rename a part of the primary key to avoid the collision.

I would suggest changing the duplicate 'NetFramework11' and 'NetFramework20' IDs to 'NetFramework11SP' and 'NetFramework20SP' or the like.

Many Thanks!

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1744399&group_id=105970



------------------------------

Message: 4
Date: Wed, 27 Jun 2007 13:30:45 -0700
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Feature Requests-1585281 ] Add solution and
project variables back to Votive v3
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Feature Requests item #1585281, was opened at 2006-10-26 11:43
Message generated for change (Comment added) made by justinrockwood
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1585281&group_id=105970

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: votive
Group: None
>Status: Open
Priority: 8
Private: No
Submitted By: Justin Rockwood (justinrockwood)
Assigned to: Justin Rockwood (justinrockwood)
Summary: Add solution and project variables back to Votive v3

Initial Comment:
Votive v2 had a feature which has not yet been added
back to Votive v3, and that is automatically defining
the following preprocessor variables as part of the
build.

You should be able to right mouse click on
the .wixproj file?s "References" node and add a
project reference to another project in your solution
(a C# DLL project, for example). Once you have one or
more project references in your .wixproj file, then
before the compile happens, I generate 10 sets of
preprocessor definitions per project. For example, if
my reference project was named MyCSharpProject, then
I?d have the following preprocessor definitions:

$(var.MyCSharpProject.ProjectDir) ? example
C:\MySolution\MyCSharpProject\
$(var.MyCSharpProject.ProjectExt) ? example .csproj
$(var.MyCSharpProject.ProjectFileName) ? example
MyCSharpProject.csproj
$(var.MyCSharpProject.ProjectName) ? example
MyCSharpProject
$(var.MyCSharpProject.ProjectPath) ? example
C:\MySolution\MyCSharpProject\MyCSharpProject.csproj

$(var.MyCSharpProject.TargetDir) ? example
C:\MySolution\MyCSharpProject\bin\Debug\
$(var.MyCSharpProject.TargetExt) ? example .dll
$(var.MyCSharpProject.TargetFileName) ? example
MyCSharp.dll
$(var.MyCSharpProject.TargetName) ? example MyCSharp
$(var.MyCSharpProject.TargetPath) ? example
C:\MySolution\MyCSharpProject\bin\Debug\MyCSharp.dll

This then lets you do things like this in your wxs
file:






----------------------------------------------------------------------

>Comment By: Justin Rockwood (justinrockwood)
Date: 2007-06-27 13:30

Message:
Logged In: YES
user_id=1054914
Originator: YES

You're probably using native C++ project references, which aren't
supported yet. The reason why they're not supported is because they're not
MSBuild-compiant projects. I'll have to write a lot of custom code to parse
the vcproj file format to extract the needed information. It's something
that I'll probably do, but it will be a little bit before that's in.

----------------------------------------------------------------------

Comment By: Josh Korn (joshkorn)
Date: 2007-06-26 18:18

Message:
Logged In: YES
user_id=1829360
Originator: NO

Justin:

I can't get this to work at all. I've added the project references, but
the compiler still complains that the references don't exist. I even put a
small macro at the top of the file, just to see what I'd get:





Of course, I get the "ain't defined - sorry" error.

Any idea what might be wrong?

Thx
Josh


----------------------------------------------------------------------

Comment By: Justin Rockwood (justinrockwood)
Date: 2007-05-21 14:16

Message:
Logged In: YES
user_id=1054914
Originator: YES

Thanks for logging the extra bug. I'll treat that as a separate bug, since
it works in non-batched builds. Thanks for testing as well!

Here's the other bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1722849&group_id=105970&atid=642714


----------------------------------------------------------------------

Comment By: Doug S (tpaxatb)
Date: 2007-05-21 09:38

Message:
Logged In: YES
user_id=1342505
Originator: NO

This works from the command line as expected and also when doing a single
solution configuration's build. However (and I don't know if this is a
VS2005 issue or a WiX issue), when doing a batch build of multiple
configurations, the target directory of the dependent projects is always
set to the target directory of the currently selected solution
configuration. e.g.:
ConsoleApplication1 - executable
WixProject1 - depends on ConsoleApplication1.
Two configurations - Debug and Release (any cpu).

Do a Batch Build on both configurations (Debug and Release), regardless of
what the configuration manager says, if I have Debug|Any CPU as my
currently selected solution configuration, it will always use
bin\Debug\ConsoleApplication1.exe as the dependency resolotuion. Same for
Release|Any CPU.

In addition, the properties "Configuration", "FullConfiguration", and
"Platform" of the dependent project are not defined unless a command line
build is occuring (i.e. they are not set by the IDE build). This may also
be why the managed C++ references aren't resolved completely. Also logged
as new bug.

----------------------------------------------------------------------

Comment By: Justin Rockwood (justinrockwood)
Date: 2007-05-17 21:36

Message:
Logged In: YES
user_id=1054914
Originator: YES

This is finally done! For each project reference the following are defined
as preprocessor variables:

Configuration (i.e. Debug)
FullConfiguration (i.e. Debug|AnyCPU)
Platform (i.e. AnyCPU)

ProjectDir
ProjectExt
ProjectFileName
ProjectName
ProjectPath

TargetDir
TargetExt
TargetFileName
TargetName
TargetPath

So, to use them you author this into your .wxs file:
$(var.YourProjectName.TargetPath).

There is still a known bug. If you have a managed VC++ project reference,
you'll only get project references for this project if you build the
solution from the command line. Building from within Visual Studio (in
Votive) does not pick up the VC++ project reference correctly. If I find
that people want this feature (i.e. somebody logs a bug on this), then I'll
eventually fix it.

Also it's important to note that native VC project references don't work
either. That's because VC projects are not MSBuild-compliant and so I'll
have to write a lot of custom code to dig into the VC project file that
isn't technically supported (I'd be in no-man's land). Again, if people
want this feature (it's a feature request and not a bug), then I may be
able to get to it.

----------------------------------------------------------------------

Comment By: Justin Rockwood (justinrockwood)
Date: 2007-05-14 13:28

Message:
Logged In: YES
user_id=1054914
Originator: YES

I already have a local fix and plan to check in for next week's build.

----------------------------------------------------------------------

Comment By: Doug S (tpaxatb)
Date: 2007-05-14 13:21

Message:
Logged In: YES
user_id=1342505
Originator: NO

I've created a poor-man's version of this partially (by hijacking the
ResolveProjectReferences target from Microsoft.Common.targets and adding
that to a CustomAfterWixTargets file and depending AfterResolveReferences
on this target) but is there any word on an ETA for this feature in an
'official' build?

----------------------------------------------------------------------

Comment By: HeO (heo)
Date: 2007-03-01 06:42

Message:
Logged In: YES
user_id=1732464
Originator: NO

Adjustment of priority highly appreciated :)

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1585281&group_id=105970



------------------------------

Message: 5
Date: Wed, 27 Jun 2007 22:24:24 -0700
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Feature Requests-1743864 ] Change
CloseApplication to support sending close message
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Feature Requests item #1743864, was opened at 2007-06-26 20:54
Message generated for change (Settings changed) made by barnson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1743864&group_id=105970

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: extensions
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Kevin Fischer (kevinf872)
>Assigned to: Bob Arnson (barnson)
Summary: Change CloseApplication to support sending close message

Initial Comment:
CloseApplication currently only prompts for reboot if the specified application is running during install.

I want to add functionality to support sending WM_CLOSE to running applications to attempt to close them. It would do this silently if the option is enabled.

My code change implements this and adds two new boolean properties "CloseMessage" and "RebootPrompt" which control the new behavior and existing behavior.

I've attached a ZIP file which includes all of the files modified as part of this change. The source files are based on 3.0.3015.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=1743864&group_id=105970



------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

------------------------------

_______________________________________________
WiX-devs mailing list

https://lists.sourceforge.net/lists/listinfo/wix-devs


End of WiX-devs Digest, Vol 13, Issue 31
****************************************

2007 29 июня