MakeSfxCA.exe Could not find a part of the path

[wixbot]

Hello, During a build of a Custom Action project, I am seeing an odd System.IO.DirectoryNotFoundException along with a Wix.CA.targets error for MakeSfxCA.exe.

This same project can be built just fine on various machines except a few.

The very confusing part is that the DirectoryNotFoundException text cites a directory that does not exist, a single character is typically missing from the referenced project's path.

It would appear there are no coded references to this file or path, it must be inferring it somehow as part of the build process.

I feel I've ran into this issue in the past and it might have been related to the length of the path to the file .. but it just doesn't make sense that it is random characters within the middle of the path.

EXEC: System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\Builds\464\ZZZZZZZZZZZZZ\YYYYYYYYYYYYYYYY\src\Source\ZZZZZZZZZZZZZ\Installer\Setu\bin\Debug\XXXXXXXX.dll'.

The path is quite long, sorry for the blanks.. I've filled in the number of characters.

Note the last part of the path Installer\Setu\bin\Debug

This should be Installer\Setup\bin\Debug, I've seen this happen with other characters in the same path.. different DLL, previously saw the following on a different builder:

System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\CruiseControl\YYYYYYYYYYYYY\Work\Source\ZZZZZZZZZZZZZ\Instaler\Setup\bin\Release\XXXXXX.dll'

This time it is the Installer directory missing a letter.

The next error is:

C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\Wix.CA.targets (141): The command ""C:\Program Files (x86)\WiX Toolset v3.8\bin..\sdk\MakeSfxCA.exe" {Lots of semicolon delimited file paths}" exited with code 1.

I've blanked out all of the referenced path's and dlls... the important thing to note is the specific DLL that threw the DirectoryNotFoundException had the correct path in the command line text.

D:\Builds\464\ZZZZZZZZZZZZZ\YYYYYYYYYYYYYYYY\src\Source\ZZZZZZZZZZZZZ\Installer\Setup\bin\Debug\XXXXXXXX.dll

Anyone have any thoughts on this?

Thanks.

Originally opened by aluitink

[wixbot]

Looks like the MakeSfxCA.exe path is missing a slash.

Originally posted by rseanhall

[wixbot]

Please post a diagnostic-level MSBuild log.

Originally posted by barnson

[wixbot]

One of our developers resolved the issue by reducing the length of the path by like 20-25 characters.

If you would like to reproduce, I would suggest creating a custom action project with a deep path, it seems like that is the issue.

Also, I've tried the missing slash fix, it makes no difference.

Thanks anyways.

Originally posted by aluitink

[wixbot]

If you post a diagnostic-level MSBuild log, we can take a look.

[wixbot]

ping

[wixbot]

Please re-open if more details are available.

Resolution set to moreinfo Status changed from Untriaged to Resolved

[wixbot]

I am having the same issue as stated above. I am using TFS 2013.4 and my build definition is failing with the same error above and the path is missing one character.

Here is the path that it is failing on: C:\Builds\1\Assure\GRC Studio 4.2.5\rc\FastpathCustomActions\CustomAction.config

Where the path shows \rc\ it should be \src\ - so just missing the 's' character.

The path is not overly long, so what could be the issue. I have the same exact build defintion running for version 4.3.0 instead of 4.2.5 on the same build machine and it works.

Thoughts?

Originally posted by boettcher

[wixbot]

I am having the same issue as stated above. I am using TFS 2013.4 and my build definition is failing with the same error above and the path is missing one character.

Here is the path that it is failing on: C:\Builds\1\Assure\GRC Studio 4.2.5\rc\FastpathCustomActions\CustomAction.config

Where the path shows \rc\ it should be \src\ - so just missing the 's' character.

The path is not overly long, so what could be the issue. I have the same exact build defintion running for version 4.3.0 instead of 4.2.5 on the same build machine and it works.

Thoughts?

Originally posted by boettcher Status changed from Resolved to Untriaged

[wixbot]

Which version of WiX are you using? Can you repro the problem outside of Team Build?

Resolution changed from moreinfo to

[wixbot]

We are using WiX 3.8 On my local machine, I haven't been able to repro the issue and my local development path is actually longer than the build path on the build server. One other note, when I change the build location on the server I saw the following results: I removed a couple of characters from the build location, the build succeeded. I added a couple of characters multiple different ways. Anytime that I increased the length of the path, the build would fail again. However, it would actually give a different error message for the different changes I made.

Originally posted by boettcher

[wixbot]

Any update on this issue?

Originally posted by boettcher

[wixbot]

I fixed wix.ca.targets to grab Content items by %(Identity)=%(FullPath) which works well for other projects.

However for a specific project this happens.

The command line is fine. But the path in the exception message is mysteriously missing an 'r' smack down the middle ('Upgraders' -> 'Upgrades').

The file isn't the first or last in the list and there are many similarly named files.

The missing character isn't near any escape characters and doesn't match any special token that I know of.

This is using toolset version 3.9.421.0

PackCustomAction:
  "..\..\..\..\..\external\Wix\sdk\MakeSfxCA.exe" "C:\projects\work1\dev\system\Zvm\Installation\Resources\CA\ZvmCA\obj\x86\Debug\ZvmCA.CA.dll" "..\..\..\..\..\external\Wix
  \sdk\x86\SfxCA.dll" "C:\projects\work1\dev\system\Zvm\Installation\Resources\CA\ZvmCA\obj\x86\Debug\ZvmCA.dll" "C:\Program Files (x86)\WiX Toolset v3.9\SDK\Microsoft.Depl
  oyment.WindowsInstaller.dll;C:\projects\work1\dev\system\Zvm\StorageUpgrade\bin\Debug\StorageUpgrade.dll;C:\projects\work1\dev\system\infra\cs\Zerto.Infra\bin\Debug\Zerto
  .Infra.dll;C:\projects\work1\bin\debug\Zerto.Zvm.Common.dll;C:\projects\work1\bin\debug\Zerto.Zvm.Storage.dll;C:\projects\work1\bin\debug\Microsoft.Practices.Unity.Interc
  eption.dll;C:\projects\work1\bin\debug\NLog.dll;C:\projects\work1\dev\system\infra\cs\Zerto.Infra\bin\Debug\ICSharpCode.SharpZipLib.dll;C:\projects\work1\bin\debug\Ionic.
  Zip.dll;C:\projects\work1\dev\system\infra\cs\Zerto.Infra\bin\Debug\SevenZipSharp.dll;C:\projects\work1\bin\debug\Zerto.Common.dll;C:\projects\work1\dev\system\external\V
  MwareWebServices\Vim25Service2005.dll;C:\projects\work1\bin\debug\ScvmmBasics.dll;C:\projects\work1\bin\debug\PbmService.dll;C:\projects\work1\bin\debug\VcloudRestSchema_
  V5_1.dll;C:\projects\work1\bin\debug\VcloudSDK_V5_1.dll;C:\projects\work1\bin\debug\Remoting.dll;C:\projects\work1\dev\system\Zvm\StorageUpgrade\bin\Debug\Iesi.Collection
  s.dll;C:\projects\work1\bin\debug\FluentNHibernate.dll;C:\projects\work1\bin\debug\NHibernate.dll;C:\projects\work1\bin\debug\System.Data.SqlServerCe.dll;C:\projects\work
  1\bin\debug\Microsoft.Practices.Unity.dll;C:\projects\work1\bin\debug\ErikEJ.SqlCe40.dll;C:\projects\work1\bin\debug\SqlCeScripting40.dll;C:\projects\work1\bin\debug\ISql
  CeScripting.dll;C:\projects\work1\bin\debug\Interop.DiskQuotaTypeLibrary.dll;C:\projects\work1\bin\debug\Microsoft.SystemCenter.VirtualMachineManager.dll;C:\projects\work
  1\bin\debug\Utils.dll;C:\projects\work1\bin\debug\Errors.dll;C:\projects\work1\bin\debug\TraceWrapper.dll;C:\projects\work1\bin\debug\NativeMethods.dll;C:\projects\work1\
  bin\debug\Microsoft.Practices.ServiceLocation.dll;C:\projects\work1\dev\system\external\VMwareWebServices\Vim25Service2005.XmlSerializers.dll;C:\projects\work1\bin\debug\
  PbmService.XmlSerializers.dll;System.Data.SqlServerCe.dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\System.Data.SqlServerCe.dll;System.Data.SqlServerCe.Entity.
  dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\System.Data.SqlServerCe.Entity.dll;Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest=C:\projects\work1\dev\system\ex
  ternal\SqlCompact_4.0\x86\Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest;Microsoft.VC90.CRT\msvcr90.dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\Microsoft
  .VC90.CRT\msvcr90.dll;Microsoft.VC90.CRT\README_ENU.txt=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\Microsoft.VC90.CRT\README_ENU.txt;sqlceca40.dll=C:\projec
  ts\work1\dev\system\external\SqlCompact_4.0\x86\sqlceca40.dll;sqlcecompact40.dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\sqlcecompact40.dll;sqlceer40EN.d
  ll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\sqlceer40EN.dll;sqlceme40.dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\sqlceme40.dll;sqlceqp40
  .dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\sqlceqp40.dll;sqlcese40.dll=C:\projects\work1\dev\system\external\SqlCompact_4.0\x86\sqlcese40.dll;PbmServic
  e.dll=C:\projects\work1\dev\system\external\VMwareWebServices\PbmService.dll;PbmService.XmlSerializers.dll=C:\projects\work1\dev\system\external\VMwareWebServices\PbmServ
  ice.XmlSerializers.dll;Vim25Service2005.dll=C:\projects\work1\dev\system\external\VMwareWebServices\Vim25Service2005.dll;Vim25Service2005.XmlSerializers.dll=C:\projects\w
  ork1\dev\system\external\VMwareWebServices\Vim25Service2005.XmlSerializers.dll;VimService2005.dll=C:\projects\work1\dev\system\external\VMwareWebServices\VimService2005.d
  ll;VimService2005.XmlSerializers.dll=C:\projects\work1\dev\system\external\VMwareWebServices\VimService2005.XmlSerializers.dll;VMware.Security.CredentialStore.dll=C:\proj
  ects\work1\dev\system\external\VMwareWebServices\VMware.Security.CredentialStore.dll;DbScripts\AmberToBerylUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upg
  raders\DbScripts\AmberToBerylUpgrade.sql;DbScripts\BerylToCorkiteUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\BerylToCorkiteUpgrade.sql
  ;DbScripts\CorkiteToCorkiteU1Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\CorkiteToCorkiteU1Upgrade.sql;DbScripts\CorkiteU1ToCorkiteU2U
  pgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\CorkiteU1ToCorkiteU2Upgrade.sql;DbScripts\CorkiteU2ToCorkiteU3Upgrade.sql=C:\projects\work1
  \dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\CorkiteU2ToCorkiteU3Upgrade.sql;DbScripts\CorkiteU3ToCorkiteU4Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgra
  de\Upgraders\DbScripts\CorkiteU3ToCorkiteU4Upgrade.sql;DbScripts\CorkiteU4ToCorkiteU5Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\Corki
  teU4ToCorkiteU5Upgrade.sql;DbScripts\CorkiteU4ToDiamondUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\CorkiteU4ToDiamondUpgrade.sql;DbScr
  ipts\CorkiteU5ToDiamondUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\CorkiteU5ToDiamondUpgrade.sql;DbScripts\DiamondToEmeraldUpgrade.sql
  =C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\DiamondToEmeraldUpgrade.sql;DbScripts\EmeraldToFlintUpgrade.sql=C:\projects\work1\dev\system\Zvm\Stor
  ageUpgrade\Upgraders\DbScripts\EmeraldToFlintUpgrade.sql;DbScripts\FlintToGraniteUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\FlintToGr
  aniteUpgrade.sql;DbScripts\GraniteToGraniteU1Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteToGraniteU1Upgrade.sql;DbScripts\Grani
  teToHaliteUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteToHaliteUpgrade.sql;DbScripts\GraniteU10ToHaliteUpgrade.sql=C:\projects\w
  ork1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU10ToHaliteUpgrade.sql;DbScripts\GraniteU1ToGraniteU2Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpg
  rade\Upgraders\DbScripts\GraniteU1ToGraniteU2Upgrade.sql;DbScripts\GraniteU2ToGraniteU3Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\Gra
  niteU2ToGraniteU3Upgrade.sql;DbScripts\GraniteU3ToGraniteU4Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU3ToGraniteU4Upgrade.sql
  ;DbScripts\GraniteU4ToGraniteU5Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU4ToGraniteU5Upgrade.sql;DbScripts\GraniteU5ToGranit
  eU6Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU5ToGraniteU6Upgrade.sql;DbScripts\GraniteU6ToGraniteU7Upgrade.sql=C:\projects\w
  ork1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU6ToGraniteU7Upgrade.sql;DbScripts\GraniteU7ToGraniteU8Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageU
  pgrade\Upgraders\DbScripts\GraniteU7ToGraniteU8Upgrade.sql;DbScripts\GraniteU8ToGraniteU9Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\G
  raniteU8ToGraniteU9Upgrade.sql;DbScripts\GraniteU9ToGraniteU10Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\GraniteU9ToGraniteU10Upgrade
  .sql;DbScripts\HaliteToIronUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\HaliteToIronUpgrade.sql;DbScripts\IronToJadeUpgrade.sql=C:\proj
  ects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\IronToJadeUpgrade.sql;DbScripts\JadeToKarliteUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgr
  aders\DbScripts\JadeToKarliteUpgrade.sql;DbScripts\KarliteToKarliteU1Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteToKarliteU1Upg
  rade.sql;DbScripts\KarliteU1ToKarliteU2Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteU1ToKarliteU2Upgrade.sql;DbScripts\KarliteU2
  ToKarliteU3Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteU2ToKarliteU3Upgrade.sql;DbScripts\KarliteU3ToKarliteU4Upgrade.sql=C:\pr
  ojects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteU3ToKarliteU4Upgrade.sql;DbScripts\KarliteU4ToKarliteU5Upgrade.sql=C:\projects\work1\dev\system\Zvm\
  StorageUpgrade\Upgraders\DbScripts\KarliteU4ToKarliteU5Upgrade.sql;DbScripts\KarliteU5ToKarliteU6Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbS
  cripts\KarliteU5ToKarliteU6Upgrade.sql;DbScripts\KarliteU6ToKarliteU7Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteU6ToKarliteU7U
  pgrade.sql;DbScripts\KarliteU7ToLapisUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\KarliteU7ToLapisUpgrade.sql;DbScripts\LapisToMicaUpgr
  ade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\LapisToMicaUpgrade.sql;DbScripts\MicaToNickelUpgrade.sql=C:\projects\work1\dev\system\Zvm\Stor
  ageUpgrade\Upgraders\DbScripts\MicaToNickelUpgrade.sql;DbScripts\NickelToOpalUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\NickelToOpalU
  pgrade.sql;DbScripts\OpalToPearlUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\OpalToPearlUpgrade.sql;DbScripts\PearlToPearlU1Upgrade.sql
  =C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\PearlToPearlU1Upgrade.sql;DbScripts\PearlU1ToPearlU2Upgrade.sql=C:\projects\work1\dev\system\Zvm\Stor
  ageUpgrade\Upgraders\DbScripts\PearlU1ToPearlU2Upgrade.sql;DbScripts\PearlU2ToPearlU3Upgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\Pearl
  U2ToPearlU3Upgrade.sql;DbScripts\PearlU3ToQuartzUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\PearlU3ToQuartzUpgrade.sql;DbScripts\Quart
  zToRubyUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\QuartzToRubyUpgrade.sql;DbScripts\RubyToSpinelUpgrade.sql=C:\projects\work1\dev\sys
  tem\Zvm\StorageUpgrade\Upgraders\DbScripts\RubyToSpinelUpgrade.sql;DbScripts\SharkToTigerUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\S
  harkToTigerUpgrade.sql;DbScripts\SpinelToTopazUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\SpinelToTopazUpgrade.sql;DbScripts\TigerToUn
  icornUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\TigerToUnicornUpgrade.sql;DbScripts\TopazToUviteUpgrade.sql=C:\projects\work1\dev\sys
  tem\Zvm\StorageUpgrade\Upgraders\DbScripts\TopazToUviteUpgrade.sql;DbScripts\UnicornToViperUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts
  \UnicornToViperUpgrade.sql;DbScripts\ViperToWolfUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\ViperToWolfUpgrade.sql;DbScripts\WolfToXem
  eUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\WolfToXemeUpgrade.sql;DbScripts\XemeToYakUpgrade.sql=C:\projects\work1\dev\system\Zvm\Sto
  rageUpgrade\Upgraders\DbScripts\XemeToYakUpgrade.sql;DbScripts\YakToZebraUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\YakToZebraUpgrade
  .sql;DbScripts\ZebraToAmberUpgrade.sql=C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgraders\DbScripts\ZebraToAmberUpgrade.sql;CustomAction.config=C:\projects\work1\d
  ev\system\Zvm\Installation\Resources\CA\ZvmCA\CustomAction.config"
  Searching for custom action entry points in ZvmCA.dll
      Loaded dependent assembly: C:\Program Files (x86)\WiX Toolset v3.9\SDK\Microsoft.Deployment.WindowsInstaller.dll
      CAData=ZvmCA!ZvmCA.CustomActions.CAData
      ZvmInstallCA=ZvmCA!ZvmCA.CustomActions.ZvmInstallCA
      ZvmUpgradeCA=ZvmCA!ZvmCA.CustomActions.ZvmUpgradeCA
      ZvmUpgradeRollbackCA=ZvmCA!ZvmCA.CustomActions.ZvmUpgradeRollbackCA
      ZvmRemoveCA=ZvmCA!ZvmCA.CustomActions.ZvmRemoveCA
  Searching for an embedded UI class in ZvmCA.dll
  Modifying SfxCA.dll stub
  Copying file version info from C:\projects\work1\dev\system\Zvm\Installation\Resources\CA\ZvmCA\obj\x86\Debug\ZvmCA.dll to C:\projects\work1\dev\system\Zvm\Installation\R
  esources\CA\ZvmCA\obj\x86\Debug\ZvmCA.CA.dll
  Packaging files
EXEC : error : System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\projects\work1\dev\system\Zvm\StorageUpgrade\Upgrades\DbScripts\KarliteU2ToKarlit
eU3Upgrade.sql'. [C:\projects\work1\dev\system\Zvm\Installation\Resources\CA\ZvmCA\ZvmCA.csproj]
     at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
     at System.IO.File.GetAttributes(String path)
     at Microsoft.Deployment.Compression.ArchiveFileStreamContext.OpenFileReadStream(String path, FileAttributes& attributes, DateTime& lastWriteTime)
     at Microsoft.Deployment.Compression.Cab.CabPacker.Pack(IPackStreamContext streamContext, IEnumerable`1 files, Int64 maxArchiveSize)
     at Microsoft.Deployment.Compression.Cab.CabEngine.Pack(IPackStreamContext streamContext, IEnumerable`1 files, Int64 maxArchiveSize)
     at Microsoft.Deployment.Compression.CompressionEngine.Pack(IPackStreamContext streamContext, IEnumerable`1 files)
     at Microsoft.Deployment.Compression.ArchiveInfo.PackFileSet(String sourceDirectory, IDictionary`2 fileNames, CompressionLevel compLevel, EventHandler`1 progressHandler
  )
     at Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.PackInputFiles(String outputFile, IDictionary`2 fileMap)
     at Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.Build(String output, String sfxdll, IList`1 inputs, TextWriter log)
     at Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.Main(String[] args)

Originally posted by tetnacious Status changed from Open to Untriaged

[wixbot]

I solved my issue.

The issue was with the msbuild Exec task handling for long paths.

It seems there is some cleverness in the Exec task that breaks the command line into arguments and the failure is caused by having a single argument which is too long by itself.

I worked around the issue by changing wix.ca.targets to separate items with spaces instead of semicolons.

Originally posted by tetnacious

[wixbot]

Thanks for the comment tetnacious. I'm having troubles editing my wix.ca.targets file. Can you please post your exact file so I can try to replicate your fix? Thanks!!

Originally posted by boettcher

[wixbot]

Sure, see file below.

This file also packs Content items using %(Link) or %(Identity) as appropriate.

I've also removed the WiX detection logic and changed the paths because we use WiX from a static location.

So you want to select the parts you need.

FYI, this should probably be fixed in votive directly as it is a workaround for a known issue.

<?xml version="1.0" encoding="utf-8" ?>
<!--
  <copyright file="wix.ca.targets" company="Outercurve Foundation">
    Copyright (c) 2004, Outercurve Foundation.
    This software is released under Microsoft Reciprocal License (MS-RL).
    The license and further copyright text can be found in the file
    LICENSE.TXT at the root directory of the distribution.
  </copyright>

  <remarks>
    WARNING:  DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
              created a backup copy.  Incorrect changes to this file will make it
              impossible to load or build your projects from the command-line or the IDE.

    This file defines properties used in the post-build process for WiX/DTF managed custom action projects.
  </remarks>
-->
<!--

    Tamir Daniely @ CodeValue - 7/27/2015

    Changed this file to support sub folders in SFX using Content project items.
    Linked Content project items are supported as well.
    Also changed paths to use the WiX version in the GIT repo over the local installation.
    Changed command line arguments formatting to use space for delimiters to work around long argument buug in Exec task

-->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <Import Project="$(CustomBeforeWixCATargets)" Condition=" '$(CustomBeforeWixCATargets)' != '' and Exists('$(CustomBeforeWixCATargets)')" />

    <PropertyGroup>
        <TargetCAFileName Condition=" '$(TargetCAFileName)' == '' ">$(TargetName).CA$(TargetExt)</TargetCAFileName>
        <WixSdkPath>..\..\..\..\..\external\Wix\sdk</WixSdkPath>
        <MakeSfxCA>$(WixSdkPath)\MakeSfxCA.exe</MakeSfxCA>
        <SfxCADll Condition="'$(Platform)' != 'x64'">$(WixSdkPath)\x86\SfxCA.dll</SfxCADll>
        <SfxCADll Condition="'$(Platform)' == 'x64'">$(WixSdkPath)\x64\SfxCA.dll</SfxCADll>
    </PropertyGroup>

    <Target Name="AfterCompile" DependsOnTargets="PackCustomAction" />
    <Target Name="BeforeClean" DependsOnTargets="CleanCustomAction" />

    <!--
  ==================================================================================================
  PackCustomAction

    Creates an MSI managed custom action package that includes the custom action assembly,
    local assembly dependencies, and project content files.

    [IN]
    @(IntermediateAssembly) - Managed custom action assembly.
    @(Content) - Project items of type Content will be included in the package. (With their relative path)
    $(CustomActionContents) - Optional space-delimited list of additional files to include.

    [OUT]
    $(IntermediateOutputPath)$(TargetCAFileName) - Managed custom action package with unmanaged stub.
  ==================================================================================================
  -->
    <Target Name="PackCustomAction"
     Inputs="@(IntermediateAssembly);@(Content);$(CustomActionContents)"
     Outputs="$(IntermediateOutputPath)$(TargetCAFileName)">

        <!-- Find all referenced items marked CopyLocal, but exclude non-binary files. -->
        <CreateItem Include="@(ReferenceCopyLocalPaths)" Condition=" '%(ReferenceCopyLocalPaths.extension)' == '.dll' or '%(ReferenceCopyLocalPaths.extension)' == '.exe' ">
            <Output TaskParameter="Include" ItemName="CustomActionReferenceContents"/>
        </CreateItem>

        <!-- Get content items with relative dir to use in archive -->
        <ItemGroup>
            <ContentItem Include="@(Content)">
                <PackedPath>%(Content.Link)</PackedPath>
                <PackedPath Condition=" '%(Content.Link)' == '' ">%(Content.Identity)</PackedPath>
            </ContentItem>
        </ItemGroup>
        <PropertyGroup>
            <SpaceDelimitedContents>@(ContentItem->'"%(PackedPath)=%(FullPath)"',' ')</SpaceDelimitedContents>
        </PropertyGroup>

        <!--
  Items to include in the CA package:
     - Reference assemblies marked CopyLocal
     - Project items of type Content
     - Additional items in the CustomActionContents property
  -->

        <CreateItem Include="@(IntermediateAssembly->'%(FullPath)')">
            <Output TaskParameter="Include" ItemName="IntermediateCAAssembly" />
        </CreateItem>

        <CreateItem Include="@(IntermediateAssembly->'%(RootDir)%(Directory)$(TargetCAFileName)')">
            <Output TaskParameter="Include" ItemName="IntermediateCAPackage" />
        </CreateItem>

        <!-- Run the MakeSfxCA.exe CA packaging tool. -->
        <Exec Command='"$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "@(CustomActionReferenceContents)" $(SpaceDelimitedContents) $(CustomActionContents)'
              WorkingDirectory="$(ProjectDir)" />

        <!-- Add modules to be copied to output dir. -->
        <CreateItem Include="@(AddModules);@(IntermediateCAPackage)">
            <Output TaskParameter="Include" ItemName="AddModules" />
        </CreateItem>

    </Target>

    <Target Name="CleanCustomAction">
        <Delete Files="$(IntermediateOutputPath)$(TargetCAFileName)" TreatErrorsAsWarnings="true" />
    </Target>

    <Import Project="$(CustomAfterWixCATargets)" Condition=" '$(CustomAfterWixCATargets)' != '' and Exists('$(CustomAfterWixCATargets)')" />

</Project>

Originally posted by tetnacious

[langk]

We were having the same issue when building under Visual Studio 2015:

EXEC : error : System.IO.DirectoryNotFoundException: Ein Teil des Pfades "C:\Users\user\company\development\Product\Product.Setup.CustomActions\Users\user\company\development\Product\Product.Engine\bin\Debug\de\DevExpress.XtraScheduler.v13.1.Core.resources.dll" konnte nicht gefunden werden.
7>     bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
7>     bei System.IO.File.GetAttributes(String path)
7>     bei Microsoft.Deployment.Compression.ArchiveFileStreamContext.OpenFileReadStream(String path, FileAttributes& attributes, DateTime& lastWriteTime)
7>     bei Microsoft.Deployment.Compression.Cab.CabPacker.Pack(IPackStreamContext streamContext, IEnumerable`1 files, Int64 maxArchiveSize)
7>     bei Microsoft.Deployment.Compression.Cab.CabEngine.Pack(IPackStreamContext streamContext, IEnumerable`1 files, Int64 maxArchiveSize)
7>     bei Microsoft.Deployment.Compression.CompressionEngine.Pack(IPackStreamContext streamContext, IEnumerable`1 files)
7>     bei Microsoft.Deployment.Compression.ArchiveInfo.PackFileSet(String sourceDirectory, IDictionary`2 fileNames, CompressionLevel compLevel, EventHandler`1 progressHandler)
7>     bei Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.PackInputFiles(String outputFile, IDictionary`2 fileMap)
7>     bei Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.Build(String output, String sfxdll, IList`1 inputs, TextWriter log)
7>     bei Microsoft.Deployment.Tools.MakeSfxCA.MakeSfxCA.Main(String[] args)

Solution to get the build was to:

1. Installation of Windows SDK was missing. (bootstrapper is required)
2. Visual Studio needs to be run as local administrator

Question now is why has VS to be run as local administrator in order to enable building?

[Burtsev-Alexey]

We have same problem, one of the latters in path missing and we get System.IO.DirectoryNotFoundException

[JimmyBcn]

Hi guys.

I have exactly the same problem. Well, I have 4 solution configurations (Debug - Release - Test - UAT) and everything works great but on the UAT, which is actually a copy of Test.

Changes at the wix.ca.targets have no effects. Actually, I can remove the file from the SDK folder and the results are exactly the same (works everywhere but on UAT).

The missing file should be named CrossCuttingBase instead of CossCuttingBase, as you can imagine.

I think that @wixbot solution can work but, as changes on the file are doing nothing, I'm completely lost. I've no idea of what is going on. I'm working locally and it started happening suddenly, I can't guess what the source of the problem can be.

Any help will be kindly appreciated.

[JimmyBcn]

I realized that the wix.ca.targets file to be modified is on C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x folder, it is not the one located on the SDK folder of Wix installation path.

Anyway, I could modify the file (now I can "feel" the changes) with no effect. The error is exactly the same. This is my current config:

` <Target Name="_SetDefaultPathValues">

<ReadRegistry
  Hive="LocalMachine"
  Key="$(WixInstallRegKey)"
  Name="InstallRoot"
  FailIfMissing="false"
  Condition=" '$(WixToolPath)' == '' ">

  <Output TaskParameter="Value" PropertyName="WixToolPath" />
</ReadRegistry>

 <ReadRegistry
  Hive="LocalMachine"
  Key="$(WixInstallRegKeyWow64)"
  Name="InstallRoot"
  FailIfMissing="false"
  Condition=" '$(WixToolPath)' == '' ">

  <Output TaskParameter="Value" PropertyName="WixToolPath" />
</ReadRegistry>

<CreateProperty Value="$(WixToolPath)..\sdk\" Condition=" '$(WixSdkPath)' == '' ">
  <Output TaskParameter="Value" PropertyName="WixSdkPath" />
</CreateProperty>
<CreateProperty Value="$(WixSdkPath)x86\" Condition=" '$(WixSdkX86Path)' == '' ">
  <Output TaskParameter="Value" PropertyName="WixSdkX86Path" />
</CreateProperty>
<CreateProperty Value="$(WixSdkPath)x64\" Condition=" '$(WixSdkX64Path)' == '' ">
  <Output TaskParameter="Value" PropertyName="WixSdkX64Path" />
</CreateProperty>

<CreateProperty Value="$(WixSdkPath)MakeSfxCA.exe" Condition=" '$(MakeSfxCA)' == '' ">
  <Output TaskParameter="Value" PropertyName="MakeSfxCA" />
</CreateProperty>
<CreateProperty Value="$(WixSdkX86Path)SfxCA.dll" Condition=" '$(SfxCADll)' == '' and '$(Platform)' != 'x64'">
  <Output TaskParameter="Value" PropertyName="SfxCADll" />
</CreateProperty>
<CreateProperty Value="$(WixSdkX64Path)SfxCA.dll" Condition=" '$(SfxCADll)' == '' and '$(Platform)' == 'x64'">
  <Output TaskParameter="Value" PropertyName="SfxCADll" />
</CreateProperty>

<CreateItem
 Include="@(ReferenceCopyLocalPaths)"
 Condition=" '%(ReferenceCopyLocalPaths.extension)' == '.dll' or '%(ReferenceCopyLocalPaths.extension)' == '.exe' ">
  <Output TaskParameter="Include" ItemName="CustomActionReferenceContents"/>
</CreateItem>

<ItemGroup>
  <ContentItem Include="@(Content)">
    <PackedPath>%(Content.Link)</PackedPath>
    <PackedPath Condition=" '%(Content.Link)' == '' ">%(Content.Identity)</PackedPath>
  </ContentItem>
</ItemGroup>
<PropertyGroup>
  <SpaceDelimitedContents>@(ContentItem->'"%(PackedPath)=%(FullPath)"',' ')</SpaceDelimitedContents>
</PropertyGroup>

<CreateItem Include="@(IntermediateAssembly->'%(FullPath)')">
  <Output TaskParameter="Include" ItemName="IntermediateCAAssembly" />
</CreateItem>

<Exec Command='"$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "@(CustomActionReferenceContents)" $(SpaceDelimitedContents) $(CustomActionContents)'
          WorkingDirectory="$(ProjectDir)" />

<CreateItem Include="@(AddModules);@(IntermediateCAPackage)">
<Output TaskParameter="Include" ItemName="AddModules" />
</CreateItem>

`

Please help!

[KMoraz]

This issue caused when PackCustomAction target in wix.ca.targets gets an ItemGroup (@(Content)) so big that's it fails parsing it correctly.

To resolve it, I've excluded some unnecessary files from the custom action using BeforeBuild target. On my case I've found that @(Content) contains some redundant resources files originates from a NuGet package. (that is, redundant for the custom action, not necessarily for the origin project that brought them).

I've placed the code below in my custom action .csproj to fix the issue.

  <PropertyGroup>
    <RootDir>$([System.IO.Directory]::GetParent($(MSBuildProjectDirectory)..\..\..\..\..\..\..))</RootDir>
    <BinDir>$(RootDir)\bin\</BinDir>
  </PropertyGroup>
  <Target Name="BeforeBuild">
    <ItemGroup>
      <LanguageFilesToRemove Include="
          $(BinDir)**\zh-*\*.*;
          $(BinDir)**\System*resources.dll;
          $(BinDir)**\Microsoft*resources.dll"
      />
    </ItemGroup>
    <Message Importance="high" Text="RootDir=$(RootDir)
    About to remove @(LanguageFilesToRemove->Count()) files." />
    <Delete Files="@(LanguageFilesToRemove)" />
  </Target>

[antibarbie]

@KMoraz I think your analysis is correct. But I cannot see why deleting files "BeforeBuild" would help reducing @(Content) items. It only deletes files from the previous build.

[jvanegmond]

I think I have found the root cause of this problem. MakeSfxCA.exe can have very long command line arguments depending on the total number of dependencies and the depth of the folder structure in which the project is located.

This causes the command line argument for MakeSfxCA.exe to go over the Windows limit of 8192 characters. Source: https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation

The behavior typically seen is that a single character is missing at the 8192th place in the string, but I believe this is actually undefined behavior. In our case, it was a "CustomAction.config" which was translated into a "CusomAction.config" and we happened to notice that the missing character was exactly at the 8192th place and we had recently added another dll dependency which increases the length of the command line argument.

The proposed solution is (per Microsoft):

Modify programs that require long command lines so that they use a file that contains the parameter information, and then include the name of the file in the command line.

The article above also lists various workarounds but they are all stop-gap solutions until Wix is modified to use a file to pass the command line parameter information. These workarounds are:

• Use shorter names for folders and files.
• Reduce the depth of folder trees.

[KMoraz]

@jvanegmond This is correct. We've ended up shortening the command by using short paths which fixed the issue.

[Macromullet]

So the only way I could figure out how to get this to work was to use a file. I create a temp file, then write the references to that temp file. Then I modified makesfxca to be able to read in that temp file and read the lines in it and expand them. I then delete the temp file at the end of target. Windows just has that hard limit of 8191 characters and with .net standard assembly refs, there is just simply no way to keep it under 8191 characters.

[kannandevarajan]

@Macromullet : Could you explain your solution using a sample? Did you actually decompile makesfxca.exe, inserted your code and compiled it again?

[Macromullet]

I got the makesfxca sources from the wix site. I based the solution off of WiX 3.11. I changed this function: private static IDictionary<string, string> GetPackFileMap(IList<string> inputs)

Note that I'm looking to see if one of the files is a .tmp file. I then open that file and see if it contains a file for the first line item. It's not perfect but I just needed something to compile.

Now recompiling that is with a signing key is kind of a pain, and the docs say you need all versions of visual studio, but that's not really true if you just recompile that project and its dependent assemblies, but it will still do the visual studio version check for all versions so i had to alter the msbuild stuff as well, but that's another post. I'd try to just get it compiling first. You only need to sign it if you want to deploy it to build agents and such.

I then modified the targets file so make a temp file, and write the files that would normally be passed on that command line into that temp file. I then clean up that temp file at the end.

I then modified the csproj file to point to the targets file in the local directory like this <WixCATargetsPath Condition=" '$(WixCATargetsPath)' == '' ">build\Wix.CA.targets</WixCATargetsPath>

I've attached the files in this zip file (the wix.ca.targets file and the makesfxca.cs file).

wix.zip

[kannandevarajan]

Thanks @Macromullet

[tehkyle]

Could this be converted to a PR to MakeSfxCA? We are also running into this exact issue now that our CustomActionContents list has grown to a large enough size with localized resources.

[davidnmbond]

+1 for the MakeSfxCA pull request.

We have also hit this issue when using .NET Standard 2.0 as part of a Custom Action (CA). Our workaround was to take the build error from Visual Studio and remove all the individual dll references immediately following .netstandard.dll but before Microsoft.Deployment.WindowsInstaller.dll

However, this is a horrible hack! The best answer is to fix MakeSfxCA.

[gwesterfieldjr]

I am seeing the same issue in wix 3.11.0. I am using nuget package to install wix and then reference it for building my CA project. A pull request to fix the issue would be awesome!

[Macromullet]

I forked and committed my changes here: https://github.com/Macromullet/wix3/commit/51533a7f65d727afa360f5d23635d3bda8d317a9

My visual studio xml editor for my .targets file is using tabs instead of two spaces so there are more changes in the targets file than we really need. At this point my time to actually get that fixed is limited. If anyone wants to help test or give feedback please be my guest. I'd love to get this integrate in the toolset to help others out. I'm unable to build the full solution because I don't have every version of visual studio installed. I was able to hack together a build locally when I made my fix so that I could just get MakeSfxCa to compile, but that's not going to be good enough for a PR. Unfortunately I lack the time to install 5 different versions of visual studio just to get the solution proper to build, so I'm looking for some assistance.

[aneetakolhe]

After I made this change I am running into another problem Here's the error: 176>EXEC : error : Microsoft.Deployment.WindowsInstaller.dll must be included in the list of support files. If using the MSBuild targets, make sure the assembly reference has the Private (Copy Local) flag set. Did any of you guys run into this problem ?

[jschroed]

I am running into the same issue with one of my project builds. It looks like @Macromullet applied a commit so that we could use a tmp file to load DLLs instead of loading it at the command line.

Could someone explain how to use this feature? I wasn't sure how to create the list of DLLs or how to have wix use that file.

[cschwarz]

I'm using the following workaround which works without recompiling MakeSfxCA:

C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix.ca.targets

<!-- Run the MakeSfxCA.exe CA packaging tool. -->
<!--<Exec Command='"$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "$(CustomActionContents)"'
 WorkingDirectory="$(ProjectDir)" />-->

<PropertyGroup>
  <PowerShellTempFileName>$([System.IO.Path]::GetTempPath())$([System.Guid]::NewGuid()).ps1</PowerShellTempFileName>        
  <PowerShellContent>&amp; "$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "$([System.String]::Join(";", $(CustomActionContents)))"</PowerShellContent>
</PropertyGroup>
<WriteLinesToFile File="$(PowerShellTempFileName)" Lines="$(PowerShellContent)" Overwrite="true" Encoding="Unicode" />  
<Exec Command='powershell -command "&amp; {$(PowerShellTempFileName)}"' WorkingDirectory="$(ProjectDir)" />
<Delete Files="$(PowerShellTempFileName)" />

[woozer]

I'm using the following workaround which works without recompiling MakeSfxCA:

C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix.ca.targets

<!-- Run the MakeSfxCA.exe CA packaging tool. -->
<!--<Exec Command='"$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "$(CustomActionContents)"'
 WorkingDirectory="$(ProjectDir)" />-->

<PropertyGroup>
  <PowerShellTempFileName>$([System.IO.Path]::GetTempPath())$([System.Guid]::NewGuid()).ps1</PowerShellTempFileName>      
  <PowerShellContent>&amp; "$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "$([System.String]::Join(";", $(CustomActionContents)))"</PowerShellContent>
</PropertyGroup>
<WriteLinesToFile File="$(PowerShellTempFileName)" Lines="$(PowerShellContent)" Overwrite="true" Encoding="Unicode" />    
<Exec Command='powershell -command "&amp; {$(PowerShellTempFileName)}"' WorkingDirectory="$(ProjectDir)" />
<Delete Files="$(PowerShellTempFileName)" />

I added two lines to the config, to set the right ExecutionPolicy for the file:

<PropertyGroup>
  <PowerShellTempFileName>$([System.IO.Path]::GetTempPath())$([System.Guid]::NewGuid()).ps1</PowerShellTempFileName>        
  <PowerShellContent>&amp; "$(MakeSfxCA)" "@(IntermediateCAPackage)" "$(SfxCADll)" "@(IntermediateCAAssembly)" "$([System.String]::Join(";", $(CustomActionContents)))"</PowerShellContent>
</PropertyGroup>
<WriteLinesToFile File="$(PowerShellTempFileName)" Lines="$(PowerShellContent)" Overwrite="true" Encoding="Unicode" />  

<Exec Command='powershell -command "Set-ExecutionPolicy -Scope CurrentUser RemoteSigned"' />
<Exec Command='powershell -command "Unblock-File -Path {$(PowerShellTempFileName)}"' />

<Exec Command='powershell -command "&amp; {$(PowerShellTempFileName)}"' WorkingDirectory="$(ProjectDir)" />
<Delete Files="$(PowerShellTempFileName)" />

[DGray-SDM]

Using WiX 3.11.1. Trying to build a custom action. The command line for MakeSfxCA.exe is about 15,700 characters. This definitely causes this issue and there is little hope of reducing the file name lengths, since all but one are .NET DLLs with paths fixed by their install directories. MakeSfxCA.exe really needs to accept a temporary file to store these linked files in, then pass that file name in. I will attempt to reduce my .NET dependencies, but will probably end up modifying MakeSfxCA.exe.

[siasil]

I am also running into this issue on some of my build servers. I'll look into one of the workarounds above. Any chance a fix for this can be included in the upcoming 3.14? :)

[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. If 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. This is a pretty good list of support options.

[siasil]

If i can find some time i would love to contribute! I thought the root cause was already discovered. Ill pull the code and start getting familiar with it. :)

On Fri, May 24, 2019, 11:09 AM Rob Mensching notifications@github.com wrote:

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 http://wixtoolset.org/development/ provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. If 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. This is a pretty good list of support options https://www.firegiant.com/support-options/.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wixtoolset/issues/issues/4688?email_source=notifications&email_token=AFTFPNVYAA7ZU6LVEO7K6FLPXAAKXA5CNFSM4BY36NPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWFVNUA#issuecomment-495670992, or mute the thread https://github.com/notifications/unsubscribe-auth/AFTFPNUZKBKR7U4HR7CSSNLPXAAKXANCNFSM4BY36NPA .

[Macromullet]

@robmen, I’m a little rusty on the issue but I do feel I provided a suitable workaround a year ago, with code samples. My hope was that would provide enough of a root cause for others to take it across the finish line. It stems from the way makesfxca uses the files in the exe argument list. When the number of files gets large, and/or the path nesting explodes, it means the whole things goes over the maximum number of characters supported by windows by default, and you start to get errors. This started for us with .net standard 2.0, as the total number of referenced files started to multiply.

While this may not affect a large number of people, when it happens it’s really hard to work around. I spent quite a bit of time understanding the codebase in order to make a fix, but the compilation requirements themselves are fairly stringent. It’s kind of a showstopper when it happens.

[antibarbie]

The proposed workaround with powershells are working pretty fine in production. Maybe all we need is just hack the workaround into the wix.ca.targets (instead of redefining in our projects), and propose a pull request ?

[engrasjadazeem]

@jvanegmond directed me in the right direction and @cschwarz solution works for me

[Dimigergo]

@cschwarz workaround is good for us too. :) Is it possible to fix the root issue?

[siasil]

I have tried to reproduce the issue in the office and at home. So far, I haven't been successful. In the office we got around the issue by changing the root of our source tree to a different location on the build server. Once we did that I haven't been able to reproduce it again. If anyone has a opensource project or an environment they wouldn't mind sharing, I would love to identify the root cause.

On Thu, Jan 16, 2020 at 8:06 AM Dimigergo notifications@github.com wrote:

@cschwarz https://github.com/cschwarz workaround is good for us too. :) Is it possible to fix the root issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wixtoolset/issues/issues/4688?email_source=notifications&email_token=AFTFPNU2QDVUGPPUQQYEF5TQ6BLTPA5CNFSM4BY36NPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJD7TOY#issuecomment-575142331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTFPNW5NTILGZXL5QOZ7P3Q6BLTPANCNFSM4BY36NPA .

[antibarbie]

Sorry @siasil that the repro wasn't easy for you, the projects your are testing are just not large enough :-) Large path + Many dependancies is the key (people here have command lines that are 15k caracters long). Maybe you can just measure your current command line length and adjust accordingly the path length, or the number of dependancies.

The root cause is easy to understand : The cause is the design where many files are passed in parameters to MakeSfxCA, combined with windows shell limitations. The "powershell hack" above, workarounds the limit by running the command directly in powershell context (passing the command line via temporary file).

[shaharnu11]

@robmen Hi, Regarding a new wixtoolset release containing the following fix: Use response file to pass contents that may overflow MakeSfxCA cmd-line Any idea when it will be released?

Thanks, Shahar Nussbaum Microsoft

[robmen]

You can get the fix in the latest v3.4 Development Release. The actual RTM of v3.14 is aligned with v4.0 this year.

This fix is not in v4.0 yet and that is why the issue is still open

[arunprakashn]

The latest Wix Toolset still has this issue. Any idea when the fix for this will go into the production release? For now, the PowerShell hack works but we need to update the wix.ca.targets in our azure DevOps build agents which are time-consuming to get approvals since the hosted agents are used by others too. It is easy to get the infra team to upgrade the WiX version instead of asking them to manually modify WiX target files. Thank you @woozer and @cschwarz for the Powershell fix. Appreciate it !

On a side note - Windows/MSBuild should not process such lengthy command lines and stop right away throwing an error, or at least log a warning stating lengthy path. I cannot comprehend the behavior where a random character from the path is cut off!

[KaineVarley]

Hi,

I'm experiencing similar problems attempting to upgrade my WiX project to v4:

[06/25/2024 16:58:06.115]: Converting project file Setup.wixproj...
[06/25/2024 16:58:06.129]: *** ERROR ***: Import failed with an exception.
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\xxxxxxx\source\repos\Internal - CRM 2011\Product Importer\Code\Setup\$(SolutionDir)Setup\Filter.xslt'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize, Boolean checkHost)
   at System.IO.File.InternalReadAllText(String path, Encoding encoding, Boolean checkHost)
   at FireGiant.HeatWave.ProjectConversion.VotiveProjectConverter.ProcessHeatTransforms(XDocument doc, String projectFolder)
   at FireGiant.HeatWave.ProjectConversion.VotiveProjectConverter.<ConvertAsync>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at FireGiant.HeatWave.ProjectConversion.VotiveProjectConverter.<TryConvertAsync>d__9.MoveNext().
[06/25/2024 16:58:06.129]: ---- Project Setup: Converted 7 files.
[06/25/2024 16:58:06.129]: ---- Total time: 00.022
[06/25/2024 16:58:06.129]: ========== Import complete:  1 errors, 0 warnings

I'm using Visual Studio 2022 Enterprise Edition (Version 17.10.3), with the 'HeatWave for VS2022' (v1.0.4) extension installed.

Trying to build the solution with the current WiX project crashes VS, so I've read that the recommendation is to update the project. On the WiX site, they recommend using HeatWave to manage the project update.

I've tried implementing the solution mentioned by @woozer, but this didn't appear to have any affect.

Background

I've inherited a .NET Framework windows forms app that needed some work and had to be updated to .NET Framework v4.8 before I would begin. The solution already contained the WiX project and, according the project file, the current version is v3.8

<ProductVersion>3.8</ProductVersion>

I'm not sure why, when the WiX project is included in the solution, it crashes VS when built, perhaps it's the older version. Anyway, my goal is to try to upgrade to the latest version in the hopes that it clears the issue.

I'd be grateful for any advice and guidance.

Kaine