> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Christian Leh > Sent: vrijdag 1 april 2005 10:03 > To: nant-developers@lists.sourceforge.net > Subject: [nant-dev] <solution> some little changes > > Hi there, > our software is a big project in .NET which consists of 8 solutions > (each containing about 5-8 projects, where some of them have more than > 220 classes/forms) > > 1.) > the first time we tried to run NAnt the first problem occurred: the > resource file generation takes a lot of time (we have a > background virus > scanner), about 2-3 seconds for 1 file. so we downloaded a > nightly build > (0.85 26.03.05) and made some changes to the > VSNet.ManagedProjectBase::WriteCompilerOptions() .. we killed the 2 > lines for compiling the resources over the VSNet.Resource object and > replaced it with a new procedure called WriteResxOptions. > Here we simply > used the existing DotNet.ResgenTask, added all resources and executed > it. It works properly and imperceptible fast.
I'm definitely interested in seeying what you did here. > 2.) > another issue comes along with our own "Office.dll" (not in GAC). We > also have MS Office installed and got a Primary Interop Assembly from > MS. The problem: NAnt preferred the Office.dll from MS > installed in GAC. > Maybe thats not the general solution but changing the priority of GAC > and NAnt assembly folders (3. GAC 4.AF -> 4.AF 3.GAC) in > VSNet.ManagedAssemblyReference::ResolveAssemblyReference() > solved that. > Maybe you have to think about it :) Is that also the behavior you're seeing from VS.NET ? Do you have a small repro for this ? > > 3.) > now we could build our solutions within 900 seconds. it's a > long time if > you are waiting in front of your monitor :( devenv.exe needs > the half of > time (420s). something must slow down the whole process. After running > NAnt with our .NET Profiler application, we could see that > the most time > is spend in resolving assemblies and their referenced assemblies. > So we had an idea: lets cache already resolved assemblies. We wrote a > file based assembly cache class (because the VSNet.ReferencesResolver > gets disposed if a new solution task starts) and merged it with the > existing code Don't think we'll add support for this ... > > 4.) > We use third party controls too. so if new versions get released, > everybody must have the same version installed to compile the > project. A > little new task helps us to compile with different versions: > UpLicxTask > (currently only implemented in > VSNet.ManagedProjectBase::WriteResxOptions())... Everytime a > .licx file > should be compiled, a UpLicxTask is executed. it replaces the version > stored in .licx file, with the version installed in GAC > (works only with > GAC assemblies at the moment) > > Other things: > - The project GUIDs are compared but there is no check if the projects > in the solution have the same GUID, so NAnt only builds one > project (of > them with the same GUID) I don't recall exactly, but I think we do check this now. > - Maybe there should be a "suppress resgen output" attribute > in solution > task, because if you have 200 resx files to compile, the output is > really annoying I know, I'll consider adding this (with or without an option). > Summary: > - New Task: UpLicxTask > - Patched: VSNet.ReferencesResolver (cache resolved assemblies) > - Patched: VSNet.ManagedProjectBase (use resgen task for resources) > - Patched: VSNet.ManagedAssemblyReference (changed assembly folders > priority) > > > however, after all that work in the last week, now we have NAnt that > compiles our underlying library (2 solutions, 25 projects) and the > software itself in 250s (remember, it took around 900s > before) on a 3Ghz > machine. > theres no way for devenv.exe to do it faster :) we love NAnt, > thanks for > that great work > > Thats our first contribution to the NAnt project (which is > wonderful for > huge software applications) > > Its some code we fixed up, so i decided not to put it in this mailing. > If you are interested in the changes we made, i will publish the > affected files on the mailinglist or to anybody who wants :) I'd definitely be interested. Better not send it to the list unless the size is small. Gert ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
