Почему я получаю исключение FileNotFound при ссылке на другой проект из того же решения?

Question

Я учусь пользоваться NUnit. У меня есть основной проект в этом решении, и я создал отдельный проект в том же решении, который будет проводить мои модульные тесты с собственным пространством имен. Из этого проекта я добавляю ссылку на основной проект и добавляю

using MainProjectNamespace;

к вершине.

Когда я захожу в NUnit, все мои тесты, не относящиеся к основной работе проекта. Это тесты, которые я настроил только для того, чтобы привыкнуть к NUnit, и они практически бесполезны. Когда NUnit запускает реальные тесты, тест выдает это исключение:

TestLibrary.Test.TestMainProject: System.IO.FileNotFoundException: Не удалось загрузить файл или сборку 'WpfApplication2, версия = 1.0.0.0, Культура = нейтральная, PublicKeyToken = null ' или одна из его зависимостей. система не может найти указанный файл.

Почему я получаю это исключение?

EDIT:

Теперь, когда я пытаюсь загрузить сборку в NUnit, она даже не загружается (поэтому я даже не могу получить шанс запустить тесты)

Это исключение, которое приходит sup, и трассировка стека:

System.IO.DirectoryNotFoundException: Не удалось найти часть пути «ДОЛГОЙ ПУТЬ ЗДЕСЬ, Я НЕ ХОЧУ ТИП»

System.IO.DirectoryNotFoundException...

Server stack trace: 
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.Directory.SetCurrentDirectory(String path)
    at NUnit.Core.DirectorySwapper..ctor(String directoryName)
    at NUnit.Core.Builders.TestAssemblyBuilder.Load(String path)
    at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites)
    at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites)
    at NUnit.Core.TestSuiteBuilder.Build(TestPackage package)
    at NUnit.Core.SimpleTestRunner.Load(TestPackage package)
    at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
    at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
    at NUnit.Core.RemoteTestRunner.Load(TestPackage package)
    at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
    at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
    at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]: 
    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
    at NUnit.Core.TestRunner.Load(TestPackage package)
    at NUnit.Util.TestDomain.Load(TestPackage package)
    at NUnit.Util.TestLoader.LoadTest(String testName)

EDIT2: Указанный выше путь явно находится на моем жестком диске

EDIT3: Я просто переключился с Debug на Release, на NUnit, и загрузил dll из папки релиза TestingLibrary ... И он загрузился! 1 из 3 тестов, относящихся к пространству имен, сработал. Добираюсь куда-нибудь, я.

EDIT4: Welllllllll ... Я могу сейчас запустить тесты, но я вернулся к первоначальной ошибке. ЭТО не находит сборку для основного проекта

Answer 1

Компилятор удаляет все неиспользуемые ссылки и не развертывает dll без необходимости. A using (само по себе) не считается использованием. Либо пометьте DLL для развертывания с помощью параметра «Копировать в выходной каталог», либо добавьте некоторый код, который действительно использует типы, объявленные в DLL.

Answer 2

У меня была та же проблема, и мне помог ответ RKitsons.

В основном я скопировал все библиотеки DLL, от которых зависит мой проект, а также файл nunit.framework.dll в один каталог ... obj / debug / Это один из способов сделать это.

Элегантный метод заключается в изменении конфигурации проекта в Visual Studio на вкладке «Сборка» для перехода в режим выпуска, и, если проект настроен правильно, следует скопировать все зависимые DLL в соответствующий каталог «out» или «release». 1005 *

Answer 3

Переименовали ли вы имя выходной сборки ИЛИ пространство имен в исходном проекте?

Похоже, ваш исходный файл "WPFApplication1", и я предполагаю, что вы могли изменить тип вывода с dll на exe?

Answer 4

Похоже, что одна из сборок, на которую вы ссылаетесь в вашем приложении, зависит от другой сборки, которой нет в папке bin.