2014년 2월 19일 수요일

[C#/WPF/닷넷WPF/ASP.NET/ADO닷넷/닷넷교육/닷넷강좌학원/닷넷공부/닷넷책/닷넷객체지향교육]전용 및 공유 어셈블리 지금까지는 전용 어셈블리 즉 하나의 단일한 응용 프로그램의 일부로서 배포되는 어셈블리에 대해 이야기를 했는데 이러한 어셈블리 이외에 닷넷은 ... 전용 및 공유 어셈블리 지금까지는 전용 어셈블리 즉 하나의 단일한 응용 프로그램의 일부로서 배포되는 어셈블리에 대해 이야기를 했는데 이러한 어셈블리 이외에 닷넷은 여러 응용 프로그램들이 하나의 어셈블리를 동시에 공유하는 기능을 제공한다. 1. 전용 어셈블리 기본적으로 어셈블리는 해당 프로젝트 전용으로 쓰이며 전용 어셈블리는 반드시 해당 응용 프로그램과 동일한 디렉토리에 있어야 한다. Shapes.dll 역시 전용 입니다. 이 어셈블리를 ShapeUSer에서 참조하려면 두 프로젝트를 동일한 디렉토리에서 빌드 하거나 ShapeUSer에서 명시적으로 프로젝트 참조를 추가해야 한다. 프로젝트 참조를 할 경우 VS는 Shapes.dll의 복사본을 만들어 ShapeUser 디렉토리에 넣는다. Shapes.dll이 복사되므로 원래의 Shapes.dll이 사라져도 문제되지 않지만 많은 프로그램에서 참조되는 어셈블리의 경우 DLL을 매번 복사하는 것은 비 효율적 이므로 이를 해결한 것이 공유 어셈블리 이다 2. 공유 어셈블리 공유 어셈블리는 시스템 안의 모든 프로그램들이 공유 하는 어셈블리 이다. 모든 공유 어셈블리는 전역 어셈블리 캐쉬(Global Assembly Cache, GAC)라는 특별한 .NET 시스템 디렉토리에 저장 되므로 프로그램들은 공유 어셈블리의 위치를 알 필요가 없다. 공유 어셈블리들은 시스템 전반에서 사용되므로 .NET 런타임은 공유 어셈블리에 대한 보안이나 버전 호환성 면에서 좀 더 많은 점검을 수행 한다. 공유 어셈블리 작성 강력한 이름(Strong Name)을 가진 공유 어셈블리를 만들려면 어셈블리의 서명에 사용할 공개/비공개키 쌍을 만들어야 합니다. 공개/비공개키 암호화 시스템은 암호화된 메시지를 보내는 사람만 알고 있는 비공개 키와 누구에게나 알려지는 공개키를 사용 한다. .NET환경은 이러한 동일한 메커니즘을 이용해서 참조된 공유 어셈블리가 실제 그 어셈블리인지 점검을 하는 것 이다. 어셈블리 이름, 버전, 공개키 조합은 반드시 고유 하며 이러한 조합을 강력한 이름 이라고 부른다. .NET Framework은 이러한 강력한 이름을 만들어 내는 sn.exe(Strong Name)라는 도구를 제공 하는데 이 도구는 명령 프롬프트에서만 사용 가능 하다. sn의 사용법은 다음과 같다. C:\dotnet\project\Shapes\Shapes\obj\Debug>sn –k shapes.snk  이렇게 하면 현재 폴더에 Shapes.snk라는 키 파일이 생기며 이 키로 어셈블리를 서명 하려면 프로젝트의 AssemblyInfo.cs 안의 끝 부분에 있는 AssemblyKeyFile 특성을 수정해야 한다. [assembly: AssemblyKeyFile("shapes.snk")] 아래 그림처럼 수정 해야 합니다. VS에서 키 파일의 위치는 기본적으로 프로젝트 디렉토리의 obj\debug 이며 만약 키 파일을 다른 곳에 두었다면 상대 경로를 적절히 이용하면 된다. 프로젝트를 정상적으로 빌드 하면 어셈블리에 서명이 추가 됩니다. 다시 ildasm으로 shapes.dll의 MANIFEST를 보면 서명이 추가되어 있는 것을 알 수 있습니다. 15. [C#,닷넷강좌].NET전용 및 공유 어셈블리,전역 어셈블리 캐쉬(Global Assembly Cache, GAC) 이 시점에서 ShapeUser.exe를 다시 컴파일 하지 않고 실행한다면 “어셈블리 참조가 일치 하지 않는다”는 오류가 발생 한다. 이 경우 다시 컴파일 하게 되면 ShapeUser에서는 서명된 버전의 Shpaes.dll을 참조하게 됩니다. 아직까지 shapes.dll은 공유 어셈블리가 된 것은 아다. 진정한 공유 어셈블리가 될려면 GAC에 넣어야 합니다. shapes.dll을 GAC 폴더(c:\Windows\assembly)에 끌어 놓으면 된다. (명령 프롬프트에서는 등록시  gacutil /I shapes.dll, 삭제시  gacutil /u shapes) 실제로 shapes.dll이 캐시에 추가 되었는지를 확인 하기 위해 shapeuser.exe가 있는 곳에 shapes.dll을 삭제 후 shapeuser.exe를 실행 해 보자. (명령 프롬프트에서) gacutil /u shapes 라고 입력한 후(shapes.dll을 해제 후) 다시 실행을 하면 실행이 되지 않을 것이다. [출처] 오라클자바커뮤니티 - http://www.oraclejavanew.kr/bbs/board.php?bo_table=LecCsharp&wr_id=142 자바 오라클/빅데이터 아이폰/안드로이드 닷넷/WPF 표준웹/HTML5 채용/취업무료교육 초보자코스 C#4.0, ADO.NET, Network 프로그래밍 총 5일 35시간 02-24 C#,ASP.NET마스터 총 18일 54시간 03-03 닷넷실무자를위한WPF개발자과정 총 8일 56시간 02-29 C#,ASP.NET마스터 총 8일 56시간 03-09

[C#/WPF/닷넷WPF/ASP.NET/ADO닷넷/닷넷교육/닷넷강좌학원/닷넷공부/닷넷책/닷넷객체지향교육]전용 및 공유 어셈블리 지금까지는 전용 어셈블리 즉 하나의 단일한 응용 프로그램의 일부로서 배포되는 어셈블리에 대해 이야기를 했는데 이러한 어셈블리 이외에 닷넷은 ...

전용 및 공유 어셈블리
지금까지는 전용 어셈블리 즉 하나의 단일한 응용 프로그램의 일부로서 배포되는 어셈블리에 대해 이야기를 했는데 이러한 어셈블리 이외에 닷넷은 여러 응용 프로그램들이 하나의 어셈블리를 동시에 공유하는 기능을 제공한다.

1. 전용 어셈블리

기본적으로 어셈블리는 해당 프로젝트 전용으로 쓰이며 전용 어셈블리는 반드시 해당 응용 프로그램과 동일한 디렉토리에 있어야 한다. Shapes.dll 역시 전용 입니다. 이 어셈블리를 ShapeUSer에서 참조하려면 두 프로젝트를 동일한 디렉토리에서 빌드 하거나 ShapeUSer에서 명시적으로 프로젝트 참조를 추가해야 한다. 프로젝트 참조를 할 경우 VS는 Shapes.dll의 복사본을 만들어 ShapeUser 디렉토리에 넣는다. Shapes.dll이 복사되므로 원래의 Shapes.dll이 사라져도 문제되지 않지만 많은 프로그램에서 참조되는 어셈블리의 경우 DLL을 매번 복사하는 것은 비 효율적 이므로 이를 해결한 것이 공유 어셈블리 이다
 
2. 공유 어셈블리

공유 어셈블리는 시스템 안의 모든 프로그램들이 공유 하는 어셈블리 이다. 모든 공유 어셈블리는 전역 어셈블리 캐쉬(Global Assembly Cache, GAC)라는 특별한 .NET 시스템 디렉토리에 저장 되므로 프로그램들은 공유 어셈블리의 위치를 알 필요가 없다. 공유 어셈블리들은 시스템 전반에서 사용되므로 .NET 런타임은 공유 어셈블리에 대한 보안이나 버전 호환성 면에서 좀 더 많은 점검을 수행 한다.


공유 어셈블리 작성
강력한 이름(Strong Name)을 가진 공유 어셈블리를 만들려면 어셈블리의 서명에 사용할 공개/비공개키 쌍을 만들어야 합니다. 공개/비공개키 암호화 시스템은 암호화된 메시지를 보내는 사람만 알고 있는 비공개 키와 누구에게나 알려지는 공개키를 사용 한다. .NET환경은 이러한 동일한 메커니즘을 이용해서 참조된 공유 어셈블리가 실제 그 어셈블리인지 점검을 하는 것 이다. 어셈블리 이름, 버전, 공개키 조합은 반드시 고유 하며 이러한 조합을 강력한 이름 이라고 부른다. 

.NET Framework은 이러한 강력한 이름을 만들어 내는 sn.exe(Strong Name)라는 도구를 제공 하는데 이 도구는 명령 프롬프트에서만 사용 가능 하다.

sn의 사용법은 다음과 같다.

C:\dotnet\project\Shapes\Shapes\obj\Debug>sn –k shapes.snk

   이렇게 하면 현재 폴더에 Shapes.snk라는 키 파일이 생기며 이 키로 어셈블리를 서명 하려면 프로젝트의 AssemblyInfo.cs 안의 끝 부분에 있는 AssemblyKeyFile 특성을 수정해야 한다.



[assembly: AssemblyKeyFile("shapes.snk")]
아래 그림처럼 수정 해야 합니다.


VS에서 키 파일의 위치는 기본적으로 프로젝트 디렉토리의 obj\debug 이며 만약 키 파일을 다른 곳에 두었다면 상대 경로를 적절히 이용하면 된다.

프로젝트를 정상적으로 빌드 하면 어셈블리에 서명이 추가 됩니다. 다시 ildasm으로 shapes.dll의 MANIFEST를 보면 서명이 추가되어 있는 것을 알 수 있습니다.
15. [C#,닷넷강좌].NET전용 및 공유 어셈블리,전역 어셈블리 캐쉬(Global Assembly Cache, GAC)



이 시점에서 ShapeUser.exe를 다시 컴파일 하지 않고 실행한다면 “어셈블리 참조가 일치 하지 않는다”는 오류가 발생 한다. 이 경우 다시 컴파일 하게 되면 ShapeUser에서는 서명된 버전의 Shpaes.dll을 참조하게 됩니다. 아직까지 shapes.dll은 공유 어셈블리가 된 것은 아다. 진정한 공유 어셈블리가 될려면 GAC에 넣어야 합니다. shapes.dll을 GAC 폴더(c:\Windows\assembly)에 끌어 놓으면 된다. 
(명령 프롬프트에서는 등록시  gacutil /I shapes.dll, 삭제시  gacutil /u shapes)

실제로 shapes.dll이 캐시에 추가 되었는지를 확인 하기 위해 shapeuser.exe가 있는 곳에 shapes.dll을 삭제 후 shapeuser.exe를 실행 해 보자. (명령 프롬프트에서)
gacutil /u shapes 라고 입력한 후(shapes.dll을 해제 후) 다시 실행을 하면 실행이 되지 않을 것이다.

댓글 없음:

댓글 쓰기