data folder on Web Builds

[rxelizondo]

I noticed that when I do a web build, InstallAware creates my installation "exe", a couple of "7zip" files and one folder called "data".

My question is about the "data" folder. The "data" folder has a lot of sub folders in it, but in case it matters, the immediate folders are "Microsoft .NET Framework 4" and "Microsoft .NET Framework Client 4".

What is this folder used for?

Thanks.

[giaviv]

Hi,

Could you please attach here the project that this happens with?

[rxelizondo]

After further research, I think the issue is not with the InstallAware project itself but with the folder the project resides under. if the path is too long, something breaks and leaves the "data" folder in there.

I was able to reproduce the issue using a path that was at least 85 charactes long as follows:

C:\Users\Rene\Documents\visual studio 2010\Projects\WpfApplicationIATest\InstallAware\WpfApplicationIATest.mpr

I am using Windos 7 and InstallAware 2012 (trial edition).

Can you try this on your side and let me know if you experience the same issue?

Thanks.

[rxelizondo]

Steps I took to reproduce bug:

1. Create a new Visual Studio 2010 WPF project. Name the project “WpfApplicationIATest” and make sure it resides under the default Visual Studio 2010 project directory (C:\Users\<User>\Documents\visual studio 2010\Projects).
2. Compile the project to create the exe.
3. Go to the main menu and click “InstallAware > Create Setup Project”.
4. Go to the main menu and click “InstallAware > Launch InstallAware”.
5. On the InstallAware IDE, build a “Web Deploy”.
6. After the build is finished, open the folder containing the newly generated file and you will notice that the “data” folder is there.

I am able to get rid of this bug by moving the InstallAware project closer to the root director (such as c:\ProjectFolderHere). I am also able to get rid of the bug if I redirect the project output to a folder closer to the root directory. Both solutions are workarounds that just add complexity and inconvenience to the deployment project.

Also, is not ok that InstallAware silently fails without any notice, ideally, I should have received an error message letting me know that something went wrong on the build rather than just leave orphan files and outputting what it may possible be a corrupted files.

Thanks.

[giaviv]

Hi,

As long as the root folder has a fully built .EXE file and nothing other than .7ZIP files in it; this means that the web build has completed entirely successfully.

It is completely safe to ignore/delete any files in the data subfolder in a web build output under this scenario. A web build does NOT require ANY files in a data subfolder.

Any data folder was used during temporary processing; we are aware sometimes it may not be fully cleaned up; but this is safe to delete/ignore; and will be nuked anyways on rebuilds.

[rxelizondo]

You guys need to fix this behavior. I spent two hours trying to figure out the purpose of that folder and trying to reproduce the behavior.

If you guys were aware of this issue (as you say in your response), why is this behavior not stated on the documentation? Or better yet, why not just fix InstallAware so that it makes sure it cleans everything up and prevent users from waisting time on a wild goose chasese?

Thanks.

[giaviv]

Thank you for your comments - we will take them into account.

[bradwyoung]

I assume there is nothing new on this. It is all good to say ignore, but when you cannot ignore it because it is causing other errors then I feel this needs to be fixed. I have add steps to our TFS build process template to compile our setup as part of the build. The setup compiles fine, but because the path is to long the build process cannot copy to the drop folder, then when the build tries to run again, it fails when it is trying to clean up from the previous build. If InstallAware is able to clean it up the next time the setup is built, then I don't understand why it cannot clean it up before it completes the setup build. I am running InstallAware 15.

[FrancescoT]

Dear User,

unfortunately, it is not that simple as it seems and we know that this behaviour occurs with Net runtimes inclusion.

Regards