웹 사이트 프로젝트가 Visual Studio에서 서명 된 어셈블리를 참조 할 수 있습니까?

Question

나는 2008 Visual Studio에서 웹 프로젝트의 다음과 같은 두 가지 유형의 알고 있어요 :

• 웹 사이트 프로젝트
• 웹 응용 프로그램 프로젝트로 서명 된 어셈블리를 참조 할 수 있습니다

웹 응용 프로그램 프로젝트 웹 응용 프로그램의 어셈블리도 동일한 키로 서명 된 상태 여야합니다. 그러나 어셈블리에 서명 할 장소가 없기 때문에이 방법은 웹 사이트 프로젝트에서 작동하지 않습니다. 어셈블리가 서버에서 동적으로 컴파일되기 때문에 이것이라고 생각하십니까?

어쨌든이 서명 된 어셈블리로 웹 사이트 프로젝트를 진행할 수 있습니까? 아니면이 웹 사이트 프로젝트를 웹 응용 프로그램 프로젝트로 변환해야합니까?

편집 : 다음과 같은 상황이 문제에 대해 해명을 요구하라고 요구했다

:

나는 Visual Studio에서 내 솔루션에 여러 다른 프로젝트에 의해 참조되고있는 클래스 라이브러리를 가지고있다. 프로젝트 중 하나는 특정 외부 사용자에게 배포 될 Windows 응용 프로그램입니다. 응용 프로그램이 올바른 어셈블리를 사용하고 있는지 확인하고 다른 사용자가 어셈블리를 사용하지 못하게하려면 (그 효과에 대한 제한 사항을 알고 있습니다) 모든 어셈블리가 서명되고 라이브러리의 모든 클래스가 선언됩니다 친구 (내부).

웹 사이트 프로젝트에서 어셈블리에 서명 할 수있는 방법이없는 것 같으며 라이브러리에서 무엇인가를 사용하려고 할 때 다음과 같은 메시지가 나타납니다. "CLASS는 'Friend'이므로이 컨텍스트에서 평가할 수 없습니다. ", 예상되는 것입니다.

다음 속성

내 클래스 라이브러리 프로젝트의 Assemblyinfo.vb의 파일 안에있는 :

<Assembly: InternalsVisibleTo("OtherProject1, PublicKey=AAA...")> 
<Assembly: InternalsVisibleTo("OtherProject2, PublicKey=AAA...")> 
... 

내 결론 :

웹 사이트를 변환하는 것이 작업을 수행하는 가장 깨끗한 방법 같은데 웹 애플리케이션으로 만들지 만, 우리 사이트는 이미 꽤 복잡해지고 다른 토론에서 지적한 바와 같이 할 시간이 조금 필요할 것입니다. 앞으로는 웹 응용 프로그램을 만드는 것이 더 나은 아이디어 일 수 있고 미래 개발을 위해 훨씬 더 융통성이있을 수 있다고 생각합니다.

Answer 1

두 프로젝트를 같은 키로 서명 할 필요는 없습니다. 모든 프레임 워크 어셈블리가 모두 MS의 키로 서명 된 후에도 액세스 할 수 없지만 웹 사이트와 웹 응용 프로그램 프로젝트.

웹 사이트 프로젝트에서 서명 된 어셈블리를 참조하는 것을 중단하는 데있어 아무 것도 없습니다. 어떤 오류가보고 있습니까?

---

편집 업데이트 된 정보에 비추어

을 추가, 그래, 나도에 당신이 가지고있는 것 같아요 :

1. 웹 응용 프로그램에 웹 사이트를 변환 -로 당신은 올바르게 사이트를 서명 할 방법이 없다는 것을 지적하고 실제로 ASP.NET이 사이트를 위해 생성 할 라이브러리에 대한 실질적인 통제는 없습니다.
2. 서명 된 클래스 라이브러리와 그렇지 않은 클래스 라이브러리를 두 버전으로 컴파일하십시오. 이를 달성하기 위해 조건부 컴파일을 사용할 수 있습니다.

---

편집

내가 조건부 컴파일 아마 빨리 더러워지고 끝날 것이라고 생각 추가 할 수 있지만, 간략하게는 다음과 같이 작동합니다 :

• 열기 프로젝트 속성 클래스 라이브러리의 경우 '빌드'탭으로 이동하십시오.
• "구성"드롭 다운을 "모든 구성"으로 전환하십시오.
• "조건부 컴파일 기호"상자에 "INTERNAL"과 같은 새 기호를 추가하십시오. 당신이 대중을하고, 같은 그들을 수정할 클래스 라이브러리에

이동 : 라이브러리의 공개 버전을 생성 할 때

#if INTERNAL 
    internal class MyClass 
#else 
    public class MyClass 
#endif 
    { 
    [...] 
    } 

그런 다음 "INTERNAL를 제거 "기호를 추가하고 다시 작성하십시오.이 기호가 정의 된 새로운 Debug 및 Release 구성 세트를 작성하고 Solution Configuration 드롭 다운을 사용하여 이들 사이를 전환하면 더 쉽게이 작업을 수행 할 수 있습니다.

잠재적 인 문제 : 당신이 심볼이 정의 가지고 여부를했는지 알 쉽지 않을 수도

1. - ReSharper에서 그것을 것이다 설치 그러나 함께, 내가 행동이 바닐라 VS에 모르는 현재 심볼 집합에서 컴파일되지 않는 코드 부분을 회색으로 표시하고 입력 할 때 클래스에 액세스 할 수없는 플래그를 지정합니다.
2. 성격과 방법을 public으로 남겨 두어 "내부"로 빌드하지 않으면 액세스 할 수 있지만 약간 이상하게 보일 수 있습니다 (아무런 경고도 발생하지 않음). 분명히 합법적이다).

Answer 2

서명 된 어셈블리의 공용 멤버는 DLL에 액세스 할 수있는 다른 프로젝트에서 사용할 수 있어야합니다. 서명 된 어셈블리를 여러 개 만들어 내 팀 구성원들에게 배포했습니다. 우리는 웹 사이트, 웹 프로젝트 및 콘솔 응용 프로그램을 혼합하여 사용했습니다. 우리가 충돌을 일으킨 유일한 곳은 콘솔 앱에서 HttpContext.Current를 참조하는 어셈블리를 사용하려고했을 때였습니다. 심지어 우리가이 참조를 사용하는 방법을 회피하면 효과가있었습니다.

서명/키가 문제가되는 유일한 경우는 서로 "내부"유형 및 방법을 볼 수있는 "친구"로 만들려는 경우입니다.친구 및 서명에 관한 규칙은 여기에 문서화되어 있습니다. http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

Answer 3

이제 나는 원래의 대답이 잘 적용되지 않는다는 것을보다 명확하게 알았습니다. 비슷한 상황에서 이전에했던 일은 소스 컨트롤을 사용하여 "Friend"클래스의 코드 파일을 소비 프로젝트로 분기하여 소비 어셈블리의 일부로 컴파일합니다.

필자의 경우 다른 서버 제어 프로젝트에서 별도의 DLL에 넣지 않고 코드를 재사용하려고했지만 내 웹 사이트 시나리오에서도 잘 작동하는 것으로 판단됩니다. 클래스가 사이트의 일부로 컴파일되므로 내부 선언문을 모두 사용할 수 있어야하므로 웹 사이트에서 서명 된 DLL을 참조 할 필요가 없습니다.

이것이 당신을위한 옵션이 될지 모르지만, 당신이 사용하는 소스 제어 도구, 코드 저장소를 설정하는 방법 및 분기 및 병합 개념에 얼마나 익숙한 지에 따라 달라집니다 .