Hi. I am evaluating installer builders for my company's new .Net applications. So far we have been able to do everything we need with InstallAware, which has not been possible with any other product we've tested yet.
But we encountered a troubling problem - most troubling because it was entirely unclear why the failure occurred.
We created an installer using all defaults for the .Net Setup template. At this point the installer would build.
We then simply selected the .Net Framework v3.5 SP1 Runtime (its dependencies all automatically checked themselves), and built the setup.
The setup would fail with only "Error during build: Failed to compile plug-in action: File Bag", which occurred immediately after "Built plug-in action MSXML".
Through trial and error we found if we unchecked the .Net 3.0 runtime the installer would build.
After much frantic experimenting, we realized that if we moved the whole setup project folder to a less recursed directory (i.e., shorter path) it would build correctly with the .Net 3.0 runtime re-checked.
We concluded that there was probably a file copy error due to too long of a path, but there was absolutely no information we could find to indicate anything more specific than "Error during build: Failed to compile plug-in action: File Bag".
Did we miss it in the documentation somewhere? Maybe its specific to Windows XP?
I suppose it's easily avoided once known, but for a moment we were pulling our hair out trying to figure out what went wrong.
.Net 3.0 runtime File Bag fails to build - is path too long?
-
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
A shorter output path will solve this problem. What is going on is that you are exceeding the Windows path length limit (~255 characters) and file copies are therefore failing.
Michael Nesmith
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
I just ran into this, too.
It's not really us that's exceeding MAX_PATH, it is InstallAware. Our path to the root of IA's output directory is not that long. The path provided to miabuild.exe via the /o parameter on our build server is 88 characters long. This leaves 167 characters of path (about 2/3 of MAX_PATH) for IA to work with when building the data for the compressed exe installer. However, IA exceeeds this by building this path:
C:\our\88\character\path\Release\Single\data\Microsoft .NET Framework 3.0\mFileBagIDE.dll\bag\WCF_x86\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.Selectors.dll
This path ends up being 256 characters long, exceeding MAX_PATH.
I would like to request that future versions of IA not require their output path to be so few characters. If the "data" directory structure must be built before being compressed into the exe, I suggest building the temporary directory structure in a location that you know will not exceed MAX_PATH rather than building it in the final output path. It's not unreasonable for an InstallAware user to want to build to a path such as:
C:\p4root\projects\next_release_branch_num\our_product_name\build\Release\x64\Setup
But if an output path like this one is provided, IA fails because MAX_PATH is exceeded during packaging of the .NET 3.0 runtime. It's feasible, even, that someone's %TEMP% directory, which is based on their username, could be longer than 88 characters. For instance:
C:\Documents and Settings\JimmyHasalongname.OURLONGCOMPANYDOMAINNAME\Local Settings\Temp
That's a legal temp directory, based on user and domain name length. If that was my %TEMP% dir and I passed /o=%TEMP% when calling miabuild.exe, it would fail.
A shorter output path will solve this problem. What is going on is that you are exceeding the Windows path length limit (~255 characters) and file copies are therefore failing
It's not really us that's exceeding MAX_PATH, it is InstallAware. Our path to the root of IA's output directory is not that long. The path provided to miabuild.exe via the /o parameter on our build server is 88 characters long. This leaves 167 characters of path (about 2/3 of MAX_PATH) for IA to work with when building the data for the compressed exe installer. However, IA exceeeds this by building this path:
C:\our\88\character\path\Release\Single\data\Microsoft .NET Framework 3.0\mFileBagIDE.dll\bag\WCF_x86\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.IdentityModel.Selectors.dll
This path ends up being 256 characters long, exceeding MAX_PATH.
I would like to request that future versions of IA not require their output path to be so few characters. If the "data" directory structure must be built before being compressed into the exe, I suggest building the temporary directory structure in a location that you know will not exceed MAX_PATH rather than building it in the final output path. It's not unreasonable for an InstallAware user to want to build to a path such as:
C:\p4root\projects\next_release_branch_num\our_product_name\build\Release\x64\Setup
But if an output path like this one is provided, IA fails because MAX_PATH is exceeded during packaging of the .NET 3.0 runtime. It's feasible, even, that someone's %TEMP% directory, which is based on their username, could be longer than 88 characters. For instance:
C:\Documents and Settings\JimmyHasalongname.OURLONGCOMPANYDOMAINNAME\Local Settings\Temp
That's a legal temp directory, based on user and domain name length. If that was my %TEMP% dir and I passed /o=%TEMP% when calling miabuild.exe, it would fail.
using InstallAware 9 R2 (Build Moya.sp3.070910)
Re: .Net 3.0 runtime File Bag fails to build - is path too l
Does this error message always correspond with a file path that is too long or are there other conditions that can lead to this error?
Thanks,
brian
Thanks,
brian
Re: .Net 3.0 runtime File Bag fails to build - is path too l
There is at least one other condition which could cause "Error during build: Failed to compile plug-in action: File Bag".
http://www.installaware.com/forum/viewt ... 33d6399b34
http://www.installaware.com/forum/viewt ... 33d6399b34
Andy Mills
InstallAware
Other Help:
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help - Press F1 in the InstallAware IDE.
InstallAware
Other Help:
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help - Press F1 in the InstallAware IDE.
Re: .Net 3.0 runtime File Bag fails to build - is path too l
I've come across that thread already, but I don't think I understand what the issue really was. I am using both runtimes (x86, x64) in my project and conditionally installing one or the other. When i made my first pass at that portion of work, i simply clicked the two check boxes for those runtimes. Sure enough, InstallAware generated the two scripts to install those runtimes. If i'm not mistaken, it was right after I added those two scripts that i go this File Bag problem. Not really knowing what else to do, i decided to wrap the calls to those two runtime scripts in conditionals so that they would only attempt to run on the right hardware. It was right after this that my File Bag build error went awat. What i don't understand is why this was a build error. I would have expected to see a runtime error if was trying to install something for the wrong platform. This makes me wonder what the real problem may have been. Any thoughts?
-
- Posts: 1
- Joined: Mon Mar 28, 2011 9:36 am
Re: .Net 3.0 runtime File Bag fails to build - is path too l
I am using path too long for a long time. And now i am not facing such kind of error messages.
http://LongPathTool.com/
http://LongPathTool.com/
Re: .Net 3.0 runtime File Bag fails to build - is path too l
Dear InstallAware users,
This bug has been fixed in InstallAware 10.
That being said, Windows Explorer itself may still have trouble copying files found in long paths like the ones mentioned above.
This bug has been fixed in InstallAware 10.
That being said, Windows Explorer itself may still have trouble copying files found in long paths like the ones mentioned above.
Aviv Giladi
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
Re: .Net 3.0 runtime File Bag fails to build - is path too l
Oh my god, that just happened to me when copying a jenkins project to one with a slightly longer name.
I'm looking forward to the day when Windows goes away...
I'm looking forward to the day when Windows goes away...
http://www.pointline.com
http://www.paraeasy.ch
http://ulrichard.ch
http://www.paraeasy.ch
http://ulrichard.ch
-
- Posts: 14
- Joined: Mon Jul 05, 2010 2:45 am
Re: .Net 3.0 runtime File Bag fails to build - is path too l
I'm having the same problem:
We are using Installaware 9 R2, but I have also tried the Installaware 2012 Trial which doesn't work either.
I suppose it's due to a too long path, because when I use a different output folder (shorter path) it works - but I don't know which file exactly leads to the problem.
All paths are prepended with "\\?\" as suggested in the MSDN.
Any ideas?
Regards,
Manuel Pöter
Error during build: Failed to compile plug-in action: File Bag
We are using Installaware 9 R2, but I have also tried the Installaware 2012 Trial which doesn't work either.
I suppose it's due to a too long path, because when I use a different output folder (shorter path) it works - but I don't know which file exactly leads to the problem.
All paths are prepended with "\\?\" as suggested in the MSDN.
Any ideas?
Regards,
Manuel Pöter
Re: .Net 3.0 runtime File Bag fails to build - is path too l
Hi,
Could you pin down a maximum path length that does not cause this error?
Could you pin down a maximum path length that does not cause this error?
Aviv Giladi
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
Who is online
Users browsing this forum: No registered users and 54 guests