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

Темы:

Архив:

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

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

WiX-devs Digest, Vol 18, Issue 17

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. [ wix-Bugs-1827123 ] Create sql database if database name
contains '-' symbol (SourceForge.net)
2. [ wix-Bugs-1824858 ] Font Localization not supported in the
WXL file (SourceForge.net)
3. [ wix-Bugs-1666461 ] ICE60 hash table error when
File/@DefaultVersion given (SourceForge.net)
4. [ wix-Bugs-1757835 ] DefaultLanguage/DefaultVersion ignored
(+fix) (SourceForge.net)
5. [ wix-Bugs-1824809 ] SourceName Inheritance failing
(SourceForge.net)
6. [ wix-Bugs-1810136 ] SmartCabbing doesn't work for same
directory files (SourceForge.net)


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

Message: 1
Date: Fri, 09 Nov 2007 11:20:58 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1827123 ] Create sql database if
database name contains '-' symbol
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1827123, was opened at 2007-11-06 12:30
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1827123&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: afedorov (ipm-fedorov)
>Assigned to: pmarcu (pmarcu)
Summary: Create sql database if database name contains '-' symbol

Initial Comment:
If the name of SQL database contains '-' symbol then the error -2147217900 appears during execution sql scripts.

msi log: "CreateDatabase: Error 0x80040e14: failed to create to database: 'Reports-001', error: Incorrect syntax near '-'."

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

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



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

Message: 2
Date: Fri, 09 Nov 2007 11:21:11 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1824858 ] Font Localization not
supported in the WXL file
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1824858, was opened at 2007-11-02 12:58
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1824858&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: candle
Group: v3.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ericbaud (ericbaud)
>Assigned to: pmarcu (pmarcu)
Summary: Font Localization not supported in the WXL file

Initial Comment:
Hello,

Font Size and Font FaceName are usually Language dependent. With the new wix schema localized resource are pushed to the WXL file so it make sense to also support the font style localization. Unfortunately when we try to do this the compiler does not like it because the Font Attributes are being validated before the linker process.

Open the bug. If you really want it fixed quickly, feel free to jump in the code. We?d be happy to have the fix.

From: Eric Baudouin
Sent: Friday, November 02, 2007 09:06
To: Peter Marcu; Aaron Stebner; Bob Arnson; Fredrik Grohn; Joe Abbott; John Lyon-Smith; Jordan Fitzgibbon; Justin Rockwood; Mike Holcomb; Reid Gustin; Rob Mensching; Robert Flaming; Scott Kurtzeborn
Cc: Paul Houldridge
Subject: RE: [WiX-users] Font definition and WXL

Well then this is a bug. We should be able to localize those, unless you have another approach. Font localization is a common problem. We could write a script that preprocess the wix file by bypassing candle, but I was hoping that there would be a solution coming out of the box.

Thank you.

E.


From: Peter Marcu
Sent: Friday, November 02, 2007 9:00 AM
To: Eric Baudouin; Aaron Stebner; Bob Arnson; Fredrik Grohn; Joe Abbott; John Lyon-Smith; Jordan Fitzgibbon; Justin Rockwood; Mike Holcomb; Reid Gustin; Rob Mensching; Robert Flaming; Scott Kurtzeborn
Cc: Paul Houldridge
Subject: RE: [WiX-users] Font definition and WXL

Those attributes are not localizable attributes. Therefore !(loc variables will not be replaced in them.

From: Eric Baudouin
Sent: Friday, November 02, 2007 8:52 AM
To: Aaron Stebner; Bob Arnson; Fredrik Grohn; Joe Abbott; John Lyon-Smith; Jordan Fitzgibbon; Justin Rockwood; Mike Holcomb; Peter Marcu; Reid Gustin; Rob Mensching; Robert Flaming; Scott Kurtzeborn
Cc: Paul Houldridge
Subject: FW: [WiX-users] Font definition and WXL

Hello,

I am also forwarding this question to your team.
Thank you for letting us know if you have any ideas on how to resolve this.

Thank you very much.

E.

From: Paul Houldridge
Sent: Friday, November 02, 2007 8:18 AM
To: Eric Baudouin; Kelly Leahy
Cc: ;
Subject: RE: [WiX-users] Font definition and WXL

I actually rewrote the code for the last test. If you look at the original example the names match.

However, after trying a few more things, it looks like the FaceName attribute takes the localized string just fine. It?s the Size and Bold attributes that are not preprocessing the localized string. Look at the original errors below.

Paul

From: Eric Baudouin
Sent: Thursday, November 01, 2007 5:20 PM
To: Kelly Leahy
Cc: Paul Houldridge; ;
Subject: RE: [WiX-users] Font definition and WXL

Not a bad suggestion?

Paul would you mind to have a look at this, in case the linker is case sensitive.

Thank you.

E.

From: Kelly Leahy [mailto:]
Sent: Thursday, November 01, 2007 4:59 PM
To: Eric Baudouin
Cc: Paul Houldridge; ;
Subject: Re: [WiX-users] Font definition and WXL


Ok... It also appears that your error message says 'Facename' (lowercase 'N'), but your declaration shows an uppercase. Not sure if it matters, just thought I'd mention it since I noticed it.

Kelly
Eric Baudouin

Sent by:
11/01/2007 04:44 PM To Kelly Leahy

cc "" , Paul Houldridge , ""

Subject Re: [WiX-users] Font definition and WXL






Here is the answer from Paul, so it look like syntaxically speaking we were doing the right thing.
So I think we need to focus more on the methodology. Thank you anyway for your reply.

No luck. Using the ! instead of the $ is right. $ is deprecated.

.\SetupUI.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions.
warnings in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions.
.\SetupUI.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined.
errors in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined.
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66'
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66'
Stop.


From: Kelly Leahy [mailto:]
Sent: Thursday, November 01, 2007 4:31 PM
To: Eric Baudouin
Cc: Paul Houldridge; ;
Subject: Re: [WiX-users] Font definition and WXL


Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)?

Kelly
Eric Baudouin

Sent by:
11/01/2007 04:17 PM
To ""

cc Paul Houldridge

Subject [WiX-users] Font definition and WXL









Hello,

We have moved our resource to a wxl file to facilitate the localization of our component.
In the localization world it is a good practice to make sure that the font size and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well so that the localization team could change it accordingly, since the font size and the font facename are different for the Japanese, or any far-east languages.


Unfortunately as you can see down below replacing the font attribute with the WXL loc ID causes the compiler to break, because the preprocessor might run some validation because linked the loc data in the code.

Would you have a different approach we could use so that at least we have a work-around.

Thank you very much.

E.




MS Sans Serif
12
yes

Then within my tag I have:


The error I get indicates that the !(loc.name) syntax does not work within the attributes for TextStyle. The loc variables are not getting processed into the defined values. This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is not a legal integer value. Legal integer values are from -2,147,483,648 to 2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : The TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is not a legal yes/no value. The only legal value is 'no' or 'yes'.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
WiX-users mailing list

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



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

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



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

Message: 3
Date: Fri, 09 Nov 2007 14:38:16 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1666461 ] ICE60 hash table error when
File/@DefaultVersion given
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1666461, was opened at 2007-02-22 11:39
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1666461&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: light
Group: v3.0
>Status: Pending
>Resolution: Fixed
Priority: 1
Private: No
Submitted By: Chris Allen (mozzie)
Assigned to: pmarcu (pmarcu)
Summary: ICE60 hash table error when File/@DefaultVersion given

Initial Comment:

Hi,

Say you have an unversioned file that is the key file for a component, but you specify "@DefaultVersion" so that it will always be installed even if the user has modified it, for example:



Light croaks with the following error because it still treats the file as unversioned and adds an entry to the MsiFileHash table.

error LGHT0204 : ICE60: The file script.pl is Versioned. It cannot be hashed

Although you can use "-sice:ICE60" as a workaround, this means that you also won't see the ICE60 warning if you've forgotten to add "@DefaultLanguage" too.

Thanks,
Chris



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

Comment By: pmarcu (pmarcu)
Date: 2007-10-02 14:27

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

Is this a duplicate. Need to find the duplicate.

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

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



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

Message: 4
Date: Fri, 09 Nov 2007 14:38:42 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1757835 ]
DefaultLanguage/DefaultVersion ignored (+fix)
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1757835, was opened at 2007-07-20 15:24
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1757835&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: light
Group: v3.0
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ken (kenmuse)
Assigned to: pmarcu (pmarcu)
Summary: DefaultLanguage/DefaultVersion ignored (+fix)

Initial Comment:
May be related to issue 1666461 and is the cause of the issue noted about ttf files not getting the proper language. There's a logic issue that can prevent DefaultLanguage and DefaultVersion from being used. There is no workaround unless you suppress file info and manually version every file in your project.

In wix\Binder.cs UpdateFileInformation, section of code starting at line 2204 which occurs if you have not set suppressFileHashAndInfo (so that candle can get the version from the file):

If the file exists, the version and language are retrieved from the file using Installer.GetFileVersion. If version and language returned are empty (line 2228), the file is hashed.

If the file has a version, but no language (such as many TTF's), the logic falls through to line 2260:

fileRow.Version = version;
fileRow.Language = language;

Instead of returning to the default value if no value was returned for "version" or "language", the Binder sets row's value to empty instead of the default value. In these cases, the logic prevents the stated functionality from working for any file which exists and has either version data or language data but not both.

Solution is to replace the else ("update the file row with the version and language info"):

else
{
if (0 != version.Length)
{
fileRow.Version = version;
}

if (0 != language.Length)
{
fileRow.Language = language;
}
}

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

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



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

Message: 5
Date: Fri, 09 Nov 2007 16:52:55 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1824809 ] SourceName Inheritance
failing
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1824809, was opened at 2007-11-02 11:20
Message generated for change (Comment added) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1824809&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: light
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Martin Lavelle (hypercaust)
Assigned to: pmarcu (pmarcu)
Summary: SourceName Inheritance failing

Initial Comment:
Hi,
The enclosed build.log (Excerpt) and the source file Appware.wxs, show the linker unable to find files. Some of the directories have had their names replaced by non-sensical 8 character long names, which I 'think' are being derived by the hashing the parent directory's Id?
The directories in question usually/always have name clashes with other directories (their names are not unique).
The source file (appware.wxs) was originally generated by Heat.exe, and then cleaned up.
This bug can be worked around by inserting FileSource declarations on the directories whose names are getting mangled by the linker (light).
I have tried and failed to replecate this bug with a small example. Perhaps my sample was too simple or small?
The original files are unnecesary in order to replicate this problem, as the linker will report some silly paths if no media is present. Just Link to the ComponentGroup in the samples, and look at the paths of the files.
It would be nice if Heat had the option of not making one component per file. Better yet if it handled the choice based upon the file extension/name. A SourcePath declaration for every file really bloats out the non Fragmanted files like this, though it does cure this bug...

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

>Comment By: pmarcu (pmarcu)
Date: 2007-11-09 16:52

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

Should be fixed in an upcoming build.

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

Comment By: Martin Lavelle (hypercaust)
Date: 2007-11-04 05:30

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

I've uploaded a simpler example, which replecates the fault, and proves
that the linker is using the short (8.3) names of directories for source
path resolution, when it is deriving the source paths from the directory
hierarchy.
File Added: SourceForgeBug1824809.wxs

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

Comment By: Martin Lavelle (hypercaust)
Date: 2007-11-02 11:28

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

File Added: AppWare.zip

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

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



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

Message: 6
Date: Mon, 12 Nov 2007 09:52:51 -0800
From: "SourceForge.net"
Subject: [WiX-devs] [ wix-Bugs-1810136 ] SmartCabbing doesn't work for
same directory files
To:
Message-ID:
Content-Type: text/plain; charset="UTF-8"

Bugs item #1810136, was opened at 2007-10-09 06:02
Message generated for change (Comment added) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1810136&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: light
Group: None
>Status: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Shay Erlichmen (blackend)
Assigned to: pmarcu (pmarcu)
Summary: SmartCabbing doesn't work for same directory files

Initial Comment:
SmartCabbing doesn't work for same directory file, If you install the same file (from the same source) twice into the same directory (with different name obviously) the file will be duplicated in the CAB. SmartCabbing should work also in that situation, the file should reside in the CAB only once.

Below there a XML to repro the problem.








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

>Comment By: pmarcu (pmarcu)
Date: 2007-11-12 09:52

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

This does work. When you open the cab, it will still appear that there are
two entries but they both point to the same payload. You can see this if
you makea copy of File1.dll in another location and point one of the
sources to pick it up from there. The size of you cab will double.

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

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



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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

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

_______________________________________________
WiX-devs mailing list

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


End of WiX-devs Digest, Vol 18, Issue 17
****************************************

2007 15 ноября