Comment 3 for bug 1084284

The need to access files in the same directory as the test assembly is
the most commonly cited reason for disabling shadow copy. However,
this is spurious.

NUnit doesn't copy any assemblies: shadow copy is a function of .NET
itself. Consequently, the problem needs to be viewed as "How can I
access the file where it is?" rather than "How can I get the file
copied to where I think it should be?"

There are three ways to locate a file that is located in the same
directory as the assembly:

1) Use Assembly.Codebase - this will give you the location as a URI,
which you must then tranform to an appropriate path.

2) Use the current directory, which NUnit has historically set to
directory containing the executing test assembly. However, this may
not be true for future releases.

3) Use NUnit's TestContext.CurrentContext.TestDirectory, which is the
available in the most recent releases.

All of these approaches actually use Assembly.Codebase under the
covers, with NUnit doing the work of tranforming the URI correctly in
#2 and #3. The common approach of using Assembly.Location is
incorrect, unless you actually want the location of the shadow copy
cache.

Charlie

On Fri, Dec 28, 2012 at 5:09 AM, David Moore <email address hidden> wrote:
> We are also impacted by this issue. In our case we are also dynamically
> loading additional assemblies for our unit tests. If we have assembly
> A.UnitTests.dll, it will look for file A.UnitTests.dll.loader.config
> during [SetupFixture] for a list of additional dependencies to load.
>
> This configuration file is in A.UnitTests.csproj and is marked as
> BuildAction=Content and "Copy always" so the configuration file is
> always built right next to A.UnitTests.dll. If Shadow Copying would
> honor that build action + bring such files along, I believe it might
> work.
>
> If there is another way I can package or tag that .config file with my
> UnitTests so that the shadow copying process would know to bring
> A.UnitTests.dll.loader.config along with the .dll and .pdb, that would
> probably work for my case.
>
> Like another poster on this topic, we have a large codebase and we've
> introduced this dynamic loading complication to avoid endless
> CopyLocal=True which drastically slows and destabilizes our builds. On
> our build servers we disable shadow copying for running our test suites
> both for performance reasons and because it broke for any of our unit
> tests that needed to perform dynamic loading. If you were to drop
> support for disabling shadow copying, we'd need a way to tell NUnit's
> shadow copying to bring along additional files side-by-side with the
> .dll.
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1084284
>
> Title:
> Unable to disable Shadow Copy
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunit-vs-adapter/+bug/1084284/+subscriptions