* cause obviously we can not* exactly hard code paths.
On Sun, Jul 29, 2012 at 2:43 PM, Michael Herndon
mhern...@wickedsoftware.net wrote:
to explain further, the shadow copy feature basically copies the test
assemblies to a different location and executes them from that location.
However, to my knowledge it does not copy the file resources. The location
of where a test assembly is located and execute is not guaranteed which
makes using relative paths fickle, but its required cause obviously we can
exactly hard code paths.
Shadow copy breaks using relative paths in test code. However if you turn
shadow copy off, then it kills the workflow of writing tests from within
visual studio since the test assembly is seen being used by another process
and blocks VS from rebuilding the test assembly which can be really
frustrating as you would imagine.
The thing to do is attempt to account for all situations so that people
can download on whatever box using whatever test tools with as little
friction as possible. I'm open to suggestions.
On Sun, Jul 29, 2012 at 2:20 PM, Michael Herndon
mhern...@wickedsoftware.net wrote:
because of the shadow copy feature in nunit.
simply using
Path.Combine(Index, index. + oldNames[i]);
won't work when the test assemblies are located in funky places.
On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson si...@devhost.se wrote:
I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a
Mac, debugging one failure at a time. The TestBackwardsCompability tests
fails when unzipping because the paths for the source zip files are
incorrectly calculated. It originates in Paths.AssemblyDirectory, where it
returns a rooted path on Windows (C:\Users\sisve\...), but a relative
path on Mac (Users/sisve/...).
We could use the existing Path.Combine, and choose to copy to
input.xxx.zip files to the output directory. This would remove the need
for the Paths class completely [if I understand it correctly]. (It's also
used from LuceneTestCase to initialize a variable no-one uses.)
Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
test/core/index/index. + oldNames[i]);
New: System.String dirName = Path.Combine(Index, index. +
oldNames[i]);
But this makes me wondering, why was the Paths class introduced at all?
// Simon
