Problem compiling large projects

Jan 6, 2009 at 4:31 PM
I am trying to compile a project that has a some long paths in it.  It is a VB project.  After doing some research it appears that the VB compiler will not accept paths in access of 64 character.  The nPanday tool is trying to use the full path to each file in the project and fails to build because of this. 

Would it be possible to adjust the tool to change to the directory of the solution and use the relative path from there?  That should shorten the path tremendously and allow these projects to build.  I have tried it at the command line and it appears to work properly.

The C# compiler does not have this limitation.

Thanks
Chris
Coordinator
Jan 6, 2009 at 6:48 PM
Yes Chris we will include this in our road map.

Thanks for bringing it up.
Jan 6, 2009 at 9:48 PM
Actually it appears not to be the vbc 64 character issue, but that the cmd.exe is being called to execute the compiler and cmd.exe has a 8192 character limit.  cmd.exe doesn't need to be called, you should be able to just call either vbc, aspnet_comp or csc directly and skip cmd all together. 
Coordinator
Jan 16, 2009 at 6:09 AM
Fixed in the trunk.

We opted to copy the needed files for compilation into a temp Directory and added the /recurse option.

Thanks,
Jan 16, 2009 at 3:20 PM
Edited Jan 16, 2009 at 3:22 PM
Will this work for projects such as Web Applications where there are controls in a different directory and they are referenced in an aspx page in the root of the project?  So the project directory structure would like something like.

Solution
|__Project
    |__Controls
    |    |__control.ascx
    |__default.aspx
Coordinator
Jan 20, 2009 at 5:40 AM
Yes it does work for projects containing controls in different directories.

But we will be eventually change the compilation of projects and will be using MS Build. This change in the compilation would require some major overhauling of NPanday so it will be moved to the roadmap at the moment.

Thanks.
Developer
Jan 22, 2009 at 1:08 PM
> We opted to copy the needed files for compilation into a temp Directory and added the /recurse option.

Can you explain a bit more about where the temporary directory gets created, how it's named and how it gets cleaned up?

In r24510, it looks like the temp directories are underneath C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\NPanday_Temp and that the entire NPanday_Temp directory gets deleted at build time.

What will happen if two projects are built at the same time?

Thanks,
--
Wendy
Coordinator
Jan 23, 2009 at 1:58 AM
We will be changing the location of  the Temp Folder and will be using the TempFolder function, we will just rely on the User or on the System's Disk Cleanup utility to delete the temp folder since it would be hard for us to keep track of the temp folder since the deletion of the temp folder is in a different module.

With using of the temp folder we could avoid the collisions on parallel builds.

Thanks.
Coordinator
Jan 23, 2009 at 3:55 AM
I think that is a bit of a concern - with the frequency of builds you would use up disk space at a rapid rate!

Is it possible to create the folder in a known location under the 'target' directory? That way one location is reused and it can be cleaned up with a simple "mvn clean".
Jan 23, 2009 at 4:30 AM
I agree with Brett. Windows doesn't clean up the temp directory very much if ever.

The a directory in the target directory or could the project be compiled in place? Not real clear on why the project is copied but I think leaving it to windows will cause issues

Chris Bown

On Jan 22, 2009, at 9:55 PM, brettporter <notifications@codeplex.com> wrote:

From: brettporter

I think that is a bit of a concern - with the frequency of builds you would use up disk space at a rapid rate!

Is it possible to create the folder in a known location under the 'target' directory? That way one location is reused and it can be cleaned up with a simple "mvn clean".
Coordinator
Jan 26, 2009 at 7:27 AM
Hi,

Brett there was a problem before with the test project that We were using to verify the fix. But as it turned out it was remote to that project and it is safe to use the 'target' directory.

We will be implementing the change for the temp directory now.

Thanks,