Hello Matthew,
MM> Looks pretty good to me. Do you notice an impact on compile speed?
I don't. I'm building from remote login session to two-processor
Pentium 4 :-)
But if all of the dll's are copied my build fails because it tries to
run tests on dll's in some subfolders which need config files
Looks pretty good to me. Do you notice an impact on compile speed?
I can try patching my local copy of NAnt and running it through our
build torture test - 90+ projects with all sorts of inter-project and
3rd-party references. :) I may not have time to do this until next
week, however.
Matt
Hello Matthew,
I've fixed the current implementation of Reference.cs in VSNet-tasks
project. Now it creates new AppDomain in which it tries to resolve all
assemblies which are referenced from the given assembly, which are
located in the same directory. Recently, all assemblies in that
directory we
Hello Matthew,
I've implemented the proof-of-concept program, which creates AppDomain
and loads assemblies there, but I'm not sure if it works around the
problem you've described. Probably it would be good to set up some
security policy for the newly-created AppDomain, so that the loaded
assembly
(re-cc'ing the list)
AppDomains allow you load/unload assemblies at will. The .NET runtime
tends to exhibit some odd/unpredictable behaviour as you load assemblies
with the same name, especially if they don't have strong names. You can
end up with types no longer resolving as expected. By lo
Sounds good - just make sure you use a separate AppDomain while checking
for assembly references. I would also recommend caching lists of
dependent assemblies based on filename to save time.
Ivan Tarasov wrote:
Hello nant-developers,
I have quite a big project which uses task to build
ce