Как получить доступ к статическому классу в том же пространстве имен, но другой сборке?

Question

Я работаю с приложением WPF в C#. У меня есть ряд констант, определенных в статическом классе, как:

Project1:

namespace MyCompany 
{ 
    public static class Constants 
    { 
     public static int MY_CONSTANT = 123456; 
    } 
} 

Тогда все, что мне нужно сделать, чтобы получить доступ к моей постоянной в любом месте внутри проекта 1 является:

int x = Constants.MY_CONSTANT; 

Теперь я добавляю еще один проект, к тому же решению, и использовать тот же корневое пространство имен:

проект 2

namespace MyCompany.MyControl 
{ 
    class VideoControl 
    { 
     int x; 
     x = Constants.MY_CONSTANT; //<-- doesn't work 
     x = MyCompany.Constants.MY_CONSTANT; //<-- doesn't work either 
    } 
} 

Я просто не могу понять, как получить доступ к моему статическому классу Constants из второй сборки. Я также не могу добавить ссылку на первую сборку, потому что она приводит к циклической зависимости (вторая сборка проекта - это элемент управления WPF, используемый первой сборкой проекта).

Является ли то, что я пытаюсь сделать, даже возможно? В настоящее время мое обходное решение передает все необходимые константы в конструкторе, но я бы хотел просто получить к ним доступ напрямую.

Answer 1

Вы можете переместить все статические константы из проекта 1 в проект 2, поэтому все константы видны как для проекта 1, так и для проекта 2; Я рекомендовал ввести другой проект (возможно, общий), который мог бы помочь управлять всеми материалами, которые были доступны для всех других проектов. это общий инфраструктурный проект.

Answer 2

Вы должны добавить ссылку в проект 1 в проект 2, тогда она должна работать нормально. Вам нужна графика, чтобы проиллюстрировать, как это сделать?

Вот ссылка MSDN http://msdn.microsoft.com/en-us/library/wkze6zky.aspx

А вот ТАК ответить с картинками>Adding projects to a project in Visual Studio 2010

Answer 3

Другой ответ близок, но это на самом деле наоборот: Project 2 необходима ссылка проекта 1. Код должен затем скомпилируйте.

EDIT:

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