.Net 3.0 runtime File Bag fails to build - is path too long?

[qstarin]

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.

[MichaelNesmith]

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.

[jsmith]

I just ran into this, too.

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.

[bsweeney]

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

[mills]

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

[bsweeney]

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?

[pathtoolong]

I am using path too long for a long time. And now i am not facing such kind of error messages.

http://LongPathTool.com/

[giaviv]

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.

[ulrichard]

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...

[ManuelPöter]

I'm having the same problem:

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

[giaviv]

Hi,

Could you pin down a maximum path length that does not cause this error?