Wixsharp: Community feedback needed...

Created on 22 Nov 2017 · 9Comments · Source: oleg-shilo/wixsharp

There have been a few user feedback reports indicating that the default auto-id generation algorithm, which handles duplicated ids by adding incremental index to the ID name is not adequate/convenient:

 <File  Id="plugin_descriptor.properties.1"... 
 <File  Id="plugin_descriptor.properties.2"...

While the algorithm works well its non-deterministic nature may trigger undesired side affects.

The issue was addressed by implementing an alternative deterministic _target-path-hash-based_ algorithm that addresses the issue (Release v1.4.11.0).

 <File  Id="plugin_descriptor.properties.2133121231"... 
 <File  Id="plugin_descriptor.properties.2343242422"...

Effectively the old incremental algorithm has become a legacy feature. The switch between an latest and the legacy algorithm is as simple as:
C# Compiler.AutoGeneration.LegacyDefaultIdAlgorithm = false; // or true (current default)
Thus I am facing this product release dilemma:

Should LegacyDefaultIdAlgorithm be disabled by default?
Side effect - users who store generated WXS will need to enable the lagacy algorithm in their code if they still prefer it.

Thank you.

Done / Released enhancement help wanted

Source

oleg-shilo

Most helpful comment

Agree, folder hash makes more sense. Accepted.

However... I am not a big fan of having obvious practically usless tokens (e.g. prefix 'File') in the names of entities. In fact in the first WiX implementation it was the approach and eventually users pushed for simpler cleaner IDs. I fully agree. Thus it has to be without the prefix. And... the hash cannot be the first token in the name. WiX does not allow IDs start with the number.

This is the latest built-in hashing algorithm returns $"{file_name}.{dir_hash}";.

And, of course, if one still wants to have the custom tokens, now it's easy:
```C#
project.CustomIdAlgorithm =
entity =>
{
if (entity is File file)
{
var target_path = this.GetTargetPathOf(file);

            var dir_hash = Math.Abs(target_path.PathGetDirName().GetHashCode32());
            var file_name = target_path.PathGetFileName();

            return $"File.{dir_hash}.{file_name}";
        }
    };

```

oleg-shilo on 24 Nov 2017

👍2

All 9 comments

In the book "WiX 3.6: A Developer's Guide to Windows Installer XML" there is a word "Speeding up file installations" there recommend, in ID files use folder names where they will be installed.

Thinking out loud.

Xaddan on 23 Nov 2017

Interesting... Didn't know about this recommendation.

Though it's a controversial one as WiX has a limit in the length of the ID as well as restriction on some characters (e.g. numbers) to be in the certain position with in the ID string. Both restrictions can be very easy violated by file system naming convention.

Cannot say I like it. :)

Though the latest "_target-path-hash-based algorithm_" in fact embraces that very recommendation but in a safer way:

Instead of recommended:
```C#
var id_val = "program_files_my_company_my_product_manual.txt";
new File(new Id(id_val), ...

WixSharp produces this: 
```C#
var id_val = "manual.txt."+@"program_files/my company/my product/manual.txt".GetHashCode();
new File(new Id(id_val), ...

Meaning that the spirit of that recommendation is respected.

oleg-shilo on 23 Nov 2017

You can get a hash from the folder.
```C#
string file = @"C:\program files\my company\my product\manual.txt";
string fileName = new FileInfo(file).Name;
int dirHash = new FileInfo(file).DirectoryName.GetHashCode();
string id = $"File_{dirHash}_{fileName}";

Files that are installed in the same directory will have the same hash that satisfies the recommendations.

File_1149205876_manual.txt
File_1149205876_app.exe

Another folder already has another hash:

File_1201615407_manual.txt
File_1201615407_app.exe
```

Xaddan on 23 Nov 2017

Agree, folder hash makes more sense. Accepted.

This is the latest built-in hashing algorithm returns $"{file_name}.{dir_hash}";.

And, of course, if one still wants to have the custom tokens, now it's easy:
```C#
project.CustomIdAlgorithm =
entity =>
{
if (entity is File file)
{
var target_path = this.GetTargetPathOf(file);

            var dir_hash = Math.Abs(target_path.PathGetDirName().GetHashCode32());
            var file_name = target_path.PathGetFileName();

            return $"File.{dir_hash}.{file_name}";
        }
    };

```

oleg-shilo on 24 Nov 2017

👍2

I would disable the Legacy Algorithm, and add a mask through which the user could configure the format ID.
Default:
```C#
FileIdMask = "{0}.{1}"

0 = file name
1 = hash

So the user can quickly adjust for themselves.
For example, I like this:
```C#
project.FileIdMask = "File_{1}_{0}"

Xaddan on 1 Dec 2017

👍1

Not bad. Though it cannot be Project as it's not a project but an algorithm property:
C# Compiler.AutoGeneration.HashedIdAlgorithmFileIdMask = "File_{1}_{0}";

oleg-shilo on 2 Dec 2017

Version 1.6.1, HashedTargetPathIdAlgorithm:

XXX.wxs(40): error LGHT0091: Duplicate symbol 'Component:Component.______.dll_1393593541' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
XXX.wxs(48): error LGHT0092: Location of symbol related to previous error.
XXX.wxs(41): error LGHT0091: Duplicate symbol 'File:______.dll_1393593541' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
XXX.wxs(49): error LGHT0092: Location of symbol related to previous error.

XXX.wxs:
... <Component Id="Component.______.dll_1393593541" Guid="3ec49adf-c352-4160-a68e-7efd661e1287"> <File Id="______.dll_1393593541" Source="..\..\..\ОбновляндерАгент\bin\Debug\КубПЭУ.dll" /> </Component> ... <Component Id="Component.______.dll_1393593541" Guid="3ec49adf-c352-4160-a68e-7efd661e1287"> <File Id="______.dll_1393593541" Source="..\..\..\ОбновляндерАгент\bin\Debug\Хелпер.dll" /> </Component> ...