Property related crash when loading WiX project in Visual Studio

[MichaWiedenmann]

I think I have tracked down a crash when loading a WiX project in Visual Studio, which seems to be related to properties. Consider the following definition:

<ItemGroup>
  <HarvestDirectory Include="$(SolutionDir)"/>         <!-- does not load in VS -->
  <!-- <HarvestDirectory Include="H:\temp\Setup\"/>--> <!-- does load -->
</ItemGroup>

This builds with MSBuild (from the command line) but loading the solution in Visual Studio 2010 fails with the following error:

InvalidParameter Parametername: CreateFolderNodes path

If I replace the property with a constant path (H:\temp\Setup\), the project does load.

• I have verified that $(SolutionDir) points to "H:\temp\Setup\".
• Replacing HarvestDirectory with Foo shows the same behavior, therefore this issue is probably unreleated to HarvestDirectory.
• Replacing $(SolutionDir) with $(ProjectDir) does load.
• I think this is a WiX issue, since the string "CreateFolderNodes path" is used in the WiX code.

• The code at src/Votive/votive2010/vssdk/projectnode.cs suggests, that the path must be subdirectory of the project:

  // Ensure we are using a relative path if (String.Compare(this.ProjectFolder, 0, path, 0, this.ProjectFolder.Length, StringComparison.OrdinalIgnoreCase) != 0) throw new ArgumentException(SR.GetString(SR.InvalidParameter, CultureInfo.CurrentUICulture), "CreateFolderNodes path");

  However, I don't understand, why the constant path works.

• The restriction that the harvest directory needs to be a subdirectory of the Wix project seem strange to me:
  1. MSBuild from the commandline does not place such an restriction.
  2. Since I keep both the WiX project and the harvest source in different repositories, I have different checkout paths. I don't want to have the source be a subdirectory of the WiX project.
• Please note that this is a minimal test case. (In reality I have a $(SourceDir) property to set the source path from the outside.)

I still wonder though:

• Why does the constant path work, even though it is not a subdirectory of the project?
• Is there a technical limitation that from within the visual studio project, only subdirectories are possible?

Hope this helps, Micha

This is my .wixproj file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
    <ProductVersion>3.10</ProductVersion>
    <ProjectGuid>{45358f0f-91db-4dc2-a7b8-60b8ffb3c26d}</ProjectGuid>
    <SchemaVersion>2.0</SchemaVersion>
    <OutputName>Setup</OutputName>
    <OutputType>Package</OutputType>
    <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
    <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <OutputPath>bin\$(Configuration)\</OutputPath>
    <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
    <DefineConstants>Debug</DefineConstants>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <OutputPath>bin\$(Configuration)\</OutputPath>
    <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
  </PropertyGroup>
  <Import Project="$(WixTargetsPath)" />
  <ItemGroup>
    <HarvestDirectory Include="H:\temp\Setup\"/>
    <!-- <HarvestDirectory Include="$(SolutionDir)"/> -->
    <!-- <Foo Include="H:\temp\Setup\"/> -->
    <!-- <Foo Include="$(SolutionDir)"/> -->
  </ItemGroup>
</Project>

[barnson]

Same basic problem as #4493. Unfortunately, nobody's currently working on Votive bugs.

[JustinPealing]

I've noticed that AddIndependentFileNode has a check to see if the item is in the project hierarchy, however it uses item.Xml.Include, which evaluates to "$(SolutionDir)" and the path comparisons don't make any sense. For reference, this is the check its trying to make:

// Make sure the item is within the project folder hierarchy. If not, link it.
string linkPath = item.GetMetadataValue(ProjectFileConstants.Link);
if (String.IsNullOrEmpty(linkPath))
{
    string projectFolder = new Uri(this.ProjectFolder).LocalPath;
    string itemPath = new Uri(Path.Combine(this.ProjectFolder, item.Xml.Include)).LocalPath;
    if (!itemPath.StartsWith(projectFolder, StringComparison.OrdinalIgnoreCase))
    {
        shouldLink = true;
    }
}

GetItemParentNode uses item.EvaluatedInclude instead - if I swap out the item.Xml.Include for item.EvaluatedInclude I no longer get the load failure and the node appears as a link, matching the behaviour of a C# project.

If the variable resolves to a folder rather than a file, it appears as a blank link (C# projects handle this by not displaying the item).

Is this the right approach? (I'm not especially familiar with VSX development). If it is I'll submit a PR.

[nick-n-dev]

Almost 3 Years later and my session grinds to a halt after running into this exact bug... Although absolutely nothing works for me, be it relative OR absolute.

Judging by the metric ton of out-dated and misleading info around the web its looking more and more like having to manually write out 1000's of file refs/components. The joy.

[robmen]

This issue is open and unassigned. That means it is waiting for someone to investigate the root problem, discuss possible solutions to that problem then implement the decided solution.

If you are interested in doing so yourself, our developer documentation provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. Since this issue has been open for a long time then there probably isn't much interest in this particular issue. In that case, you'll want to consider how to motivate others to fix it for you or consider commercial alternatives.

[nick-n-dev]

Normally i would have jumped right in, but considering i already have far too much to do already, joining a mailing list and submitting proposals etc just for a bug fix is a little too many hoops to jump through, (Could also be the reason no-one else has tried either, just saying).

But then again, i havn't touched a VS Extension in years, they were becoming quite a horrible mess of COM junk and undocumented classes/interfaces each with 20 similar variants, doubt that's changed any.

Since its been so long, i would love to hear how people are working around it then? Considering its quite the show-stopper, atm im looking at just using HeatDirectory itself and creating a custom task to include the results.

Only other option i could see is using the command line directly, maybe in a seperate build task.

Anywho, apologies for resurrecting this in such a fashion :)

[jmoutray]

FYI, inserting a <Link> element within <HarvestDirectory> prevents the error message.