* 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
>>>
>>
>>
>
