MakeSfxCA.exe Could not find a part of the path #4688
Comments
|
Looks like the MakeSfxCA.exe path is missing a slash.
|
|
Please post a diagnostic-level MSBuild log.
|
|
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.
|
|
If you post a diagnostic-level MSBuild log, we can take a look. |
|
|
|
Please re-open if more details are available.
|
|
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: 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?
|
|
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?
|
|
Which version of WiX are you using? Can you repro the problem outside of Team Build?
|
|
We are using WiX 3.8
|
|
Any update on this issue?
|
|
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
|
|
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.
|
|
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!!
|
|
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.
|
|
We were having the same issue when building under Visual Studio 2015: Solution to get the build was to:
Question now is why has VS to be run as local administrator in order to enable building? |
|
We have same problem, one of the latters in path missing and we get System.IO.DirectoryNotFoundException |
|
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. |
|
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: ` ` Please help! |
|
This issue caused when To resolve it, I've excluded some unnecessary files from the custom action using I've placed the code below in my custom action . |
|
@KMoraz I think your analysis is correct. But I cannot see why deleting files "BeforeBuild" would help reducing |
|
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):
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:
|
|
@jvanegmond This is correct. We've ended up shortening the command by using short paths which fixed the issue. |
|
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. |
|
@Macromullet : Could you explain your solution using a sample? Did you actually decompile makesfxca.exe, inserted your code and compiled it again? |
|
I got the makesfxca sources from the wix site. I based the solution off of WiX 3.11. I changed this function: 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 I've attached the files in this zip file (the wix.ca.targets file and the makesfxca.cs file). |
|
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? :) |
|
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. |
|
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 ***@***.***> 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
<#4688?email_source=notifications&email_token=AFTFPNVYAA7ZU6LVEO7K6FLPXAAKXA5CNFSM4BY36NPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWFVNUA#issuecomment-495670992>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFTFPNUZKBKR7U4HR7CSSNLPXAAKXANCNFSM4BY36NPA>
.
|
|
@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. |
|
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 ? |
|
@jvanegmond directed me in the right direction and @cschwarz solution works for me |
|
@cschwarz workaround is good for us too. :) Is it possible to fix the root issue? |
|
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 ***@***.***> 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
<#4688?email_source=notifications&email_token=AFTFPNU2QDVUGPPUQQYEF5TQ6BLTPA5CNFSM4BY36NPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJD7TOY#issuecomment-575142331>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFTFPNW5NTILGZXL5QOZ7P3Q6BLTPANCNFSM4BY36NPA>
.
|
|
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 : |
|
@robmen Thanks, |
|
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 |
|
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. 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! |
and others
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.
The text was updated successfully, but these errors were encountered: