프로젝트 중에 3rd Party 제품군을 Trial 로 사용하다가 정식 버전을 구매해서 적용을 했는데, 이미 Trial 상태에서 Expire된 상태로 설치를 했더니… 계속 애매한 오류가 발생하는 것이 있어 라이센스 매니저에 대해서 정리를 해 보도록 한다. (OS 재 설치를 하지 않기 위해서 사실 우회하는 방법을 찾아 보고 있다고 해야 하는 것이 더 맞을 듯… -_-)
라이센스 관련된 부분은 기본적으로 .NET Framework에서 제공하는 라이센스 매니저 (LicenseManager) 를 사용하게 된다.
자세한 내용은 여기를 참고하도록 하고, 기본적인 구현 방식은 아래와 같이 무척이나 간단하다.
[LicenseProvider(typeof(CustomLicenseProvider))]
pulic class CustomClass {
...
public CustomClass() {
LicenseManager.Validate(typeof(CustomClass), this);
}
...
}
위와 같이 라이센스를 적용할 클래스에 LicenseProvider 특성을 지정하고 생성자에서 LicenseManager에 Validation을 호출하면 된다.
당연히 라이센스를 검증하기 위한 처리는 LicenseProvider에 지정하면 된다.
pulic class CustomLicenseProvider : System.ComponentModel.LicenseProvider {
...
public override License GetLicense(LicenseContext context, Type type, object instance, bool allowExceptions) {
return null;
}
...
}
검증 로직이야 작성하는 사람 맘대로이니.. 별다른 의미는 없고, 라이센스가 올바르다고 판단이 되는 경우에는 License 개체 (실제로 구현한) 를 반환하면 된다. null 을 반환하면 당연히 라이센스가 없는 것이다.
.NET Framework에서 기본으로 제공하는 LicFileLicenseProvider는 아주 간단하게 해당 클래스가 라이센스로 보호되고 있는 것인지만을 검증하는 것이기 때문에 실행 경로에 "네임스페이스를 포함한 클래스의 전체 이름.lic" 파일만 만들어 놓아도 라이센스가 통과된다.
FDTWorks.DCAB.Modeler.SurfaceEditor is a licensed component.
위의 같이 클래스의 전체 이름의 파일 내에 클래스 전체 이름에 해당하는 문장을 넣어두면 된다. 물론 LicFileLicenseProvider를 상속해서 IsKeyValid 와 GetKey 등을 재 정의하면 어느 정도의 상용과 같은 보호는 할 수 있다.
어떻게 보면 이 글을 정리하는 이유이기도 한 "lc.exe" 에 대해서도 알아 봐야 한다. 라이센스와 관련해서 자세한 내용은 여기를 참고하도록 한다.
lc.exe를 사용해서 좋은 점은 위의 라이센스 파일 하나에 여러 개의 보호할 클래스를 정의할 수 있는 것이 가능하고, 이 파일을 어셈블리 내의 Embedded Resource로 처리가 가능한 것이다.
lc.exe 실행 방법은 MSDN의 도움말을 보면 자세히 알 수 있다.
C:\> lc.exe /target:LicenseTest.exe /complist:LicenseTestLic.txt /i:FDTWorks.DCAB.Modeler.SurfaceEditor.dll
위의 LicenseTestLic.txt 에는 라이센스 보호 대상이 되는 클래스와 어셈블리를 라인 단위로 여러개 지정이 가능하다. 중요한 것은 어셈블리를 지정할 때 확장자를 붙이지 말아야 한다. 그렇지 않으면 lc.exe에서 오류를 뿜는다.
처리 결과로 LicenseTest.exe.licenses 파일이 생성이 되는데 이 파일을 해당 어셈블리에 Embedded Resource로 포함할 수 있다. 그러나 이런 방식 보다는 MSbuild 에서 처리할 수 있도록 프로젝트 내에 *.licx 라는 파일을 등록하면 자동으로 리소스로 처리를 해 준다.
관련된 License 참조들은 다음의 내용들을 확인해 보면 된다.
- http://skysigal.xact-solutions.com/Blog/tabid/427/entryid/1962/C-LicenseManager-and-Other-uses-Get-a-Mobile-Devices-Unique-ID.aspx
- http://skysigal.xact-solutions.com/Blog/tabid/427/entryid/1963/C-Developing-a-LicenseProvider-License-Getting-the-Motherboard-ID.aspx
- http://skysigal.xact-solutions.com/Blog/tabid/427/entryid/1964/C-Developing-a-LicenseProvider-License-Getting-the-Manufacturer-rsquo-s-UID.aspx
- http://skysigal.xact-solutions.com/Blog/tabid/427/entryid/1965/C-Developing-a-LicenseProvider-License-Getting-the-CPU-rsquo-s-ID.aspx
실제 번거로운 라이센스 정책을 피해(?)가는 방법도 있을 것 같아서 검색을 해 보면 의외로 관련된 항목들을 찾을 수가 있다.
ChartFx 관련되어 게시글들이 많은 것 같은데, 해당 제품은 GetEntryAssembly() 에서 반환되는 어셈블리에 Licenses.lic 리소스가 있는지를 검증하고 있다고 한다. IE Embedded 방식의 SmartClient에서는 GetEntryAssembly() 가 null 이기 때문에 정식 버전을 사용한다고 해도 라이센스 오류가 발생할 수 밖에는 없다는 것이다.
Reflection으로 AppDomain.GetEntryAssembly() 를 확인해 보면 AppDomainManager.EntryAssembly 속성을 반환하고 있고 "virtual"로 선언되어 있는 것을 확인할 수 있다.
따라서 관련된 소스인 AppDomainManager를 변형하면 이런 문제를 회피할 수 있다는 말이 된다. 좀 더 자세하게 이야기를 하면 AppDomain.CurrentDomain.DomainManager 를 사용하게 되므로 라이센스를 검증하는 컴포넌트가 사용되는 곳에서 임시로 DomainManager를 재 정의한 것으로 교체를 했다가 다시 원래대로 복원을 하면 되는 것이다. Reflection을 사용하면 충분히 재 처리가 가능한 부분이니 시도해보는 것도 좋을 듯 하다.
계속 자료를 찾다가 보니 더 황당한 상황이 존재하고 있다. 이 황당함을 느끼게 해 주는 것은 바로 ".NET Profiler" 라는 놈이다. 이 놈은 라이센스고 뭐고 깡그리 무시를 한다고 봐도 될 듯 하다.
.NET Profiler에 대한 것은 "No Code Can Hide from the profiling API in the .NET Framework 2.0" 이라는 자료를 보면 된다.
찾아보면 라이센스를 무효화할 수 있는 방법이 너무나 많다. 따라서 더 이상의 내용을 확인하는 것은 큰 의미가 없을 듯 하다. 같은 개발자 입장에서 솔루션을 만들고 싶은데... 어쩌면 제 살 깍아먹기와 같으니까.
하지만 라이센스를 강화할 수 있는 방법을 찾는 측면에서는 좀 더 많은 노력이 필요할 듯 하다. 쩝~
댓글
댓글 쓰기