Menu

#1637 Reference Paths do not update Reference Hintpath

v3.0
closed
msbuild (104)
2012-09-15
2009-04-16
Seravy
No

Bug found in WIX Version 3.0.5120.0.

Using the 'Reference Paths' section in the wix project properties to point to a new path does not update the Hintpath of WixLibrarys or WixExtensions. When you open the Visual Studio WIX project properties and click on Paths tab you can change the Reference Paths here. This functionality performs in an identical manner as the other .net VS projects, it just looks a little different and is in a different place. Adding a folder to the reference path adds it to the list below where a new file is created <projectname>.wixproj.user with the following lines.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ReferencePaths>D:\Folder1\Debug\;D:\Folder2\Debug</ReferencePaths>
</PropertyGroup>
</Project>

Where the two folders D:\Folder1\Debug\ and D:\Folder2\Debug in that order are checked for the references. What happens on other .net projects is for any references if they are found in those folder they have their hint paths updated so that these new references are used. The tags which are not being updated are
<ItemGroup>
<WixExtension Include="WixUIExtension">
<HintPath>..\OldPathTest\bin\Debug\WixUIExtension.dll</HintPath>
</WixExtension>
</ItemGroup>
<ItemGroup>
<WixLibrary Include="PathTest">
<HintPath>..\OldPathTest\bin\Debug\PathTest.wixlib</HintPath>
</WixLibrary>
</ItemGroup>

But if I were to update the folder to use D:\ReferenceTest\OldPathTest\bin\Debug\ which contains a different PathTest.wixlib file, this one won't be used as the hint path, when it should be.

Example:
You can test this by creating two WIX libraries with just contain a feature of the same component with different description.

Wix Library's Contents:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Feature Id="ProductFeature" Title="ReferenceTest" Description="&lt;UPDATE THIS&gt;" Level="1" &gt;<br=""> <ComponentRef Id="test"/>
</Feature>
</Fragment>
</Wix>

Where you can update the <UPDATE THIS=""> section with something like 'Using new path' and 'Using old path'.

Then you can create a product wix project which references the 'old' path (Using a browse to select the .wixlib, not using the project reference in the same solution).

Product Contents:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="00541297-eb9c-4696-8c0b-7e9565bd4e36" Name="ReferenceTest" Language="1033" Version="1.0.0.0" Manufacturer="ReferenceTest" UpgradeCode="64cbac1a-878c-46f2-98e5-472cdad96370">
<Package InstallerVersion="200" Compressed="yes"/>
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="ReferenceTest">
<Component Id="test" Guid="C5C2004F-DB06-4C7B-BE61-B4F5C47406A4">
<File Source="Product.wxs"></File>
</Component>
</Directory>
</Directory>
</Directory>
<FeatureRef Id="ProductFeature"/>
<UIRef Id="WixUI_FeatureTree"/>
</Product>
</Wix>

This has a link to the feature so that if its pointing to the old path it will show in the UI the description 'Using old path' when compiled.

The concept is that if we now go to the product's project properties, click path and add in the directory of the output where the new path's PathTest.wixlib is located then THAT one will be used instead.

What i believe need to occur is that the inclusion of these .user files needs to be absorbed by the msbuild task if they are not already (they may be). It then should update the hint paths based on the ReferencePaths property. This may already be done for '<Reference>' itemgroup references but because wix uses '<WixExtension>' and '<WixLibrary>' references these may not be checked.

I am happy to give further examples of this problem if requested.

Cheers,
Murray

Discussion

  • Heath Stewart

    Heath Stewart - 2009-04-17

    I was not able to reproduce the behavior where the HintPath is replaced by either an absolute or a relative path that is equivalent to the HintPath for a C# project file (.csproj) in VS2008. It seems, then, that Votive is behaving the same in V2008 as the C# project system.

    Also, a project file is almost always checked in, but reference paths are a user preference (which actually create a .csproj.user file, in this example) that should not typically be checked in. This allows developers to build the same projects in different machine environments without affecting the project, i.e. the project file wouldn't even be checked out unless other changes were made to it like adding another reference or a source file.

     
  • Seravy

    Seravy - 2009-04-17

    Screen Shot of Visual Studio with No User Reference Paths

     
  • Seravy

    Seravy - 2009-04-17

    Screen Shot of Visual Studio using User Reference Paths

     
  • Seravy

    Seravy - 2009-04-17

    An example Visual Studio Solution with C# and VB examples of using User References to replace the hint path.

     
  • Seravy

    Seravy - 2009-04-17

    Hi,

    I just created a test solution file attached as (ReferencesPathsExample.zip) which has a C# and VB Example of having a reference with a hint path to 'old path' and when adding the user reference it then updates it to the 'new path' where both (a) the namespaces unique to each are no longer valid in the other and (b) the function common to both produce the text of either 'Old Path' or 'New Path' depending on which dll it is referencing.

    I have included two screen shots, 1NoUserReferences.png which shows all the required information with no hint path, and then 2UserReferences.png which all i have done is entered the new path into the user references and it has updated the user reference in all of the spots.

    The contents of the Reference item group inside CSharpExample.csproj is as follows.
    <Reference Include="PathTest, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\OldPath\PathTest.dll</HintPath>
    </Reference>

    You should be able to replicate the steps, which does not occur in the Wix Librarys.

    Your second paragraph is correct and is the exact situaion we are trying to use it in (we dont want it checked in). It is for the developers to work on the product with their own set of references (wix librarys are among them). I believe i gave this context in the user group mail list where these developers need to point to another wix libaray location without checking out the project file, and thus use the .user file. As far as i can tell Votive is doing the correct job and it is the msbuild script which needs the fix? Unless it isn't including the file in the build.

    Please let me know if there is any more information I can provide.

    Regards,
    Murray

     
  • Heath Stewart

    Heath Stewart - 2009-04-17

    I see. Thank you for clarifying.

    The issue here is that the reference paths added by a .user file are not overriding (or added to) the list of paths to check for a .wixlib, so if the HintPath metadata for a WixLibrary on one machine isn't available the reference path is not used to resolve the WixLibrary. This does not allow developers to reference libraries in distinct paths but reference a shared .wixproj.

     
  • Eric StJohn

    Eric StJohn - 2009-04-23

    To fix this we should follow the same fallback precedence for locating references as used in Microsoft.Common.targets ResolveAssemblyReference (below). I will make this change to the extent possible.

    In future versions of WIX we could consider actually using the ResolveAssemblyReference task to do this work instead of embedding the logic in light.

    <!--
    The SearchPaths property is set to find assemblies in the following order:

            (1) Files from current project - indicated by {CandidateAssemblyFiles}
            (2) $(ReferencePath) - the reference path property, which comes from the .USER file.
            (3) The hintpath from the referenced item itself, indicated by {HintPathFromItem}.
            (4) The directory of MSBuild's "target" runtime from GetFrameworkPath.
                The "target" runtime folder is the folder of the runtime that MSBuild is a part of.
            (5) Registered assembly folders, indicated by {Registry:*,*,*}
            (6) Legacy registered assembly folders, indicated by {AssemblyFolders}
            (7) Look in the application's output folder (like bin\debug)
            (8) Resolve to the GAC.
            (9) Treat the reference's Include as if it were a real file name.
        -->
        <AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == '' ">
            {CandidateAssemblyFiles};
            $(ReferencePath);
            {HintPathFromItem};
            {TargetFrameworkDirectory};
            {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
            {AssemblyFolders};
            {GAC};
            {RawFileName};
            $(OutDir)
        </AssemblySearchPaths>
    
     
  • Eric StJohn

    Eric StJohn - 2009-04-25

    Give this a try in next weeks build (5/1), I changed the order which referencepath is used.

    -Eric

     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 21 days (the time period specified by
    the administrator of this Tracker).