Visual Studio로 Azure Function 개발하기

Azure Function은 Azure App Service에 포함된 기능 중 하나인 Azure Web Job을 별도의 상품으로 분리하여 출시하였습니다. 하지만 아쉽게도 Visual Studio의 풍부한 IDE 지원을 아직까지도 직접 받을 수 있는 상태는 아닙니다. 또한 Microsoft Docs 등에 공개된 방법도 간접적으로 Azure Function의 설정을 이용한다거나, Node용 CLI를 활용하는 정도에서 언급되는 것이 전부입니다.

소개하려는 내용은 Visual Studio의 콘솔 프로젝트와 Azure Storage Emulator를 이용하여 C# Azure Function을 C# Script가 아닌 통상적인 C# Compiler 기반 프로젝트로 개발과 테스트를 진행하고, 이것을 C# Azure Function으로 마이그레이션하는 방법에 관한 것입니다. 만약 LINQPAD Premium Version을 구입하여 사용 중이라면, 같은 작업을 LINQPAD에서도 실행할 수 있으니 더 적극적으로 Azure Function을 개발하실 수 있을 것입니다.

시작하기

Azure Web Job 기반이기 때문에, 기존에 .NET용으로 출시한 Web Job SDK와 각종 Extension을 Azure Function 사이에는 어느 정도 호환성이 있습니다. 다시 말해서 C# 스크립트로 무언가 새로운 코드를 작성한다기 보다, 기존의 SDK를 C# 스크립트에서 사용할 수 있도록 포장한 것이 Azure Function의 본질에 가깝습니다. 아쉽게도 완전히 같은 코드 베이스는 아니지만, 호환성이 있기 때문에 취할 수 있는 이점이 있고, 그 부분을 활용하는 것입니다.

시작을 위하여 다음의 소프트웨어 스택이 설치되어있는지 점검합니다.

  • Azure Storage Emulator (Azure Cloud Service SDK에 포함되어있습니다.)
  • Visual Studio 2015 Community Edition 이상의 IDE
  • .NET Framework 4.6 이상

만약 Windows 개발 환경이 아닌 경우 Azure Storage Emulator는 제공되지 않기 때문에 어쩔 수 없이 실제 Azure Storage 계정을 만들어 연결해야 합니다. IDE의 경우 Visual Studio Code, Visual Studio for Mac, Rider를 대신 활용할 수 있습니다. 그리고 Mono를 설치하여 개발을 진행할 수 있습니다. 아쉽게도 .NET Core는 2017년 4월 현재 지원되지 않습니다.

선호하는 IDE로 콘솔 프로젝트를 만든 다음, 다음의 NuGet 패키지들을 설치합니다.

  • Microsoft.Azure.WebJobs (2.0.0 이상)
  • Microsoft.Azure.WebJobs.Extensions (2.0.0 이상)

그 다음 Main 메서드를 다음과 같이 코딩합니다.

var jobHostConfig = new JobHostConfiguration("UseDevelopmentStorage=true");
jobHostConfig.UseCore();
jobHostConfig.UseFiles();
jobHostConfig.UseTimers();
jobHostConfig.UseDevelopmentSettings();

using (var cts = new CancellationTokenSource())
using (var jobHost = new JobHost(jobHostConfig))
{
    jobHost.StartAsync(cts.Token);
    Console.WriteLine("Press Ctrl + C to stop the service.");
    Console.CancelKeyPress += (s, e) => cts.Cancel();
    cts.Token.WaitHandle.WaitOne(Timeout.Infinite);
}

Local Azure Storage Emulator를 사용할 수 있는 Windows 환경에서만 UseDevelopmentStorage=true 연결 문자열을 지정하고, 그 외 환경에서는 실제 Azure Storage Account의 연결 문자열을 해당 속성 블레이드에서 찾아 대입해야 합니다.

그리고 Azure Function에 호스팅하려는 함수를 다음과 같이 코딩합니다.

public static void Run(
    [TimerTrigger("* * * * * *", UseMonitor = true)]
    TimerInfo myTimer,
    TraceWriter log)
{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}");
}

TimerTrigger가 TimerInfo 메서드 인자에 지정되는 것에 유의하여 위와 같이 코딩합니다. TimerTrigger에 지정되는 첫 인자는 타이머의 실행 간격을 나타냅니다. Crontab에 사용되는 반복 간격 표시 문법을 참조하여 값을 지정하도록 구성하는 것이 Azure Function으로 마이그레이션 할 때 편리하므로 해당 문법을 익히는 것을 권장합니다.

그리고 실행이 잘 되는지 확인하기 위하여, Azure Storage Emulator를 시작하고, F5 키를 눌러 샘플 프로그램을 실행합니다. 다음과 비슷하게 출력되면 정상적으로 실행되는 것입니다.

Press Ctrl + C to stop the service.
Development settings applied
Found the following functions:
TimerSample.Run
Singleton lock acquired (1ce1ebaf1e584866b90488a9e1b5d19f/TimerSample.Run.Listener)
The next 5 occurrences of the schedule will be:
2017-04-24 오전 12:16:59
2017-04-24 오전 12:17:00
2017-04-24 오전 12:17:01
2017-04-24 오전 12:17:02
2017-04-24 오전 12:17:03
Job host started
Executing 'TimerSample.Run' (Reason='Timer fired at 2017-04-24T00:16:59.0273081+09:00', Id=aa02dc0a-5a89-4ebd-bf08-8182cce53a0c)
C# Timer trigger function executed at: 2017-04-24 오전 12:16:59
Executed 'TimerSample.Run' (Succeeded, Id=aa02dc0a-5a89-4ebd-bf08-8182cce53a0c)
Executing 'TimerSample.Run' (Reason='Timer fired at 2017-04-24T00:17:00.0061625+09:00', Id=f8161e5d-c989-4d2d-9a49-cb5d9d269134)
C# Timer trigger function executed at: 2017-04-24 오전 12:17:00
Executed 'TimerSample.Run' (Succeeded, Id=f8161e5d-c989-4d2d-9a49-cb5d9d269134)
...

마이그레이션

이렇게 만들어진 Azure Function이 정말 잘 수행되는지 점검할 때 활용할 수 있는 유용한 서비스가 하나 있습니다. Try Azure App Service를 이용하면 실제 Microsoft Azure 구독과 무관하게, Microsoft 계정 이외에도 Google (GMAIL), Facebook, Github 계정으로 로그인하여 1시간짜리 테스트 Azure Function 계정을 발급받을 수 있습니다.

https://azure.microsoft.com/ko-kr/try/app-service/ 에 방문하여 새로운 계정을 하나 생성합니다.

그 다음, 위의 Run 메서드의 코드를 복사합니다. 단, 몇 가지 복사 전에 수정하거나 확인해야 할 부분이 있습니다.

  • 개발 중에 참조한 NuGet 패키지의 참조를 지정해야 합니다. project.json 파일은 기본적으로 만들어지지 않으므로 다음과 같은 뼈대를 만들고, 현재 개발한 프로젝트 내의 package.config 파일의 내용을 여기로 복사해서 넣어야 합니다. 종속 관계에 따라 자동으로 설치되는 패키지들은 제외하고, 실제로 추가했던 패키지만 지정해서 넣으면 됩니다.
{
  "frameworks": {
    "net46":{
      "dependencies": {
        "Microsoft.ProjectOxford.Face": "1.1.0"
      }
    }
   }
}
  • NuGet 패키지가 아닌 BCL 내 어셈블리 또는 개별 .NET DLL 파일을 참조했을 경우에는 C# 스크립트만의 고유 문법인 #r 지시자를 사용하여 참조를 지정합니다.
    • GAC에 설치했거나 별도로 수동 참조한 .NET DLL 파일은 bin 폴더로 직접 업로드해야 합니다.
    • x86용으로 명시하여 빌드한 DLL이거나, 설치 준비 및 사용 과정에서 시스템 레지스트리 변경 등의 작업이 필요한 경우에는 사용할 수 없습니다.
  • 함수를 옮겨 담기 전에는 메서드 이름과 시그니처가 처음 Azure Function을 만들었을 때와 동일한지 점검합니다. 만약 정상적으로 실행되지 않는다면 function.json 파일의 내용을 참고합니다.
{
  "disabled": false,
  "bindings": [
    {
      "name": "myTimer",
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "0 */5 * * * *"
    }
  ]
}
  • 마지막으로 앞에서 TimerTrigger나 BlobTrigger, 혹은 ServiceBusTrigger와 같이 트리거에 지정한 인자의 값을 확인하여 function.json 파일을 수정하도록 합니다. 위의 예제의 경우 매 초 마다 실행되도록 하였으므로, function.json의 schedule 프로퍼티를 “* * * * * *”으로 바꾸어야 합니다.

마무리

이렇게 해서 만들어진 최종 버전의 CSX 파일을 실제 Azure Function 서비스로 배포하는 것은 자유롭게 할 수 있습니다. 연속성 있는 개발을 위해서, 버전 관리 저장소를 통하여 배포하도록 설정해두면 더욱 편리할 것입니다.

이 글을 작성하면서 좀 더 고민해볼 만한 주제가 있다면, 아래와 같은 부분들이 있을 것 같습니다.

  • HTTP Trigger, Web Hook Trigger는 Web Job과 사실 직접적인 상관이 없으며, ASP.NET Web API의 서브셋에 가깝습니다. 다만 TraceWriter 클래스를 사용하는 부분만이 온전히 Web Job에 관련이 있는 부분입니다. 이 부분을 감안하여 DummyTraceWriter 클래스를 만들어 단위 테스트를 하도록 할 수 있을 듯 합니다.
class DummyTraceWriter : TraceWriter
{
    public DummyTraceWriter() : base(default(TraceLevel)) { }
    public override void Trace(TraceEvent traceEvent) => Console.WriteLine(traceEvent);
}
  • LINQPAD용 스크립트 템플릿을 만들어 공유한다면 정식 SDK가 출시되기 전에 더 많이 Azure Function을 개발하고 테스트할 수 있을 것이라고 생각합니다.
  • 일부 네이티브 코드를 포함하는 NuGet 패키지는 아마도 64비트용으로 빌드된 패키지를 사용하는 것이 실행에 문제가 없을 것으로 예상합니다. 32비트 버전의 패키지도 별도 EXE 파일로 실행하는 경우에는 Windows-on-Windows 호환성 기능으로 실행은 보장될 수 있을 것입니다.

더 세부적인 사항, 보충할 부분, 혹은 수정해야 할 부분에 대한 의견을 주시면 큰 도움이 될 것 같습니다.

새로운 .NET AOP 프레임워크 NConcern

Java와는 다르게 .NET은 AOP에 대한 논의나 실제 적용 사례를 찾기 쉽지 않았는데, 개인적으로는 가장 큰 이유가 .NET은 AOP 관점을 실제 런타임에 불어넣기 위한 Weaving 기법을 적용하기 매우 어렵기 때문이라고 생각합니다.

Java의 경우, 별도의 제약을 가하지 않는 한 클래스를 상속하여 필요한 구현체 클래스의 메서드를 자유롭게 재정의할 수 있지만, .NET의 경우 virtual method, 대리자, 혹은 데코레이터 패턴을 사전에 고려하지 않는 한 IL 수준이나 개발 도구 수준에서 미리 대비해야만 원하는 AOP 컨셉을 만들어낼 수 있습니다.

Java, Spring, AspectJ를 배워가면서 틈나는대로 AOP에 관한 다른 언어나 닷넷의 대응 구현체를 찾다가 뜻있는 라이브러리가 있어 간단한 아티클을 써봅니다. 바로 NConcern이라는 라이브러리입니다.

NConcern은 Java의 AOP 프레임워크와 거의 비슷하게 동작합니다. 그리고 PostSharp의 Compile Time Weaving과 Runtime Weaving과 동일한 기능을 제공합니다. 특히 Compile Time Weaving은 Mono의 Cecil 라이브러리를 기반으로 구현한 CNeptune 라이브러리의 도움을 받습니다.

아쉽게도 2017년 4월 현재 .NET Core는 지원하지 않고, .NET Framework 4.0 이상의 프로젝트에 대해서만 지원하는 상태입니다.

NConcern 시험해보기

NConcern이 어떻게 동작하는지 확인해보기 위하여 Visual Studio로 간단한 Console Application 프로젝트를 생성합니다. 프로젝트를 생성한 다음, NuGet Package 관리자로 다음의 두 패키지를 추가합니다.

  • CNeptune
  • NConcern

참고로 Compile Time Weaving을 사용하지 않고 Runtime Weaving만 사용하는 경우에는 NConcern만 설치해도 됩니다. 다만 이 아티클에서 이야기하려는 것은 Compile Time Weaving에 관한 것이므로 CNeptune까지 설치해서 테스트하는 것이 필요합니다.

정상적으로 패키지를 설치한 다음에 packages.config 파일에 다음과 같이 변경되어있는지 확인합니다.

<?xml version=”1.0″ encoding=”utf-8″?>
<packages>
<package id=”CNeptune” version=”1.0.6″ targetFramework=”net452″ />
<package id=”NConcern” version=”4.0.2″ targetFramework=”net452″ />
</packages>

이제 테스트용 클래스를 하나 만듭니다.

public sealed class Sample
{
public void Test()
{
Console.WriteLine(“Hello, World!”);
}
}

보시다시피 sealed 키워드로 선언되어있어 상속이 불가한 클래스입니다. 뿐만 아니라 Test 메서드는 virtual 메서드가 아니므로 직접적인 재정의가 불가합니다.

그리고 로그 기록을 목적으로 하는 Logging Aspect를 하나 추가하겠습니다.

public class Logging : IAspect
{
public IEnumerable<IAdvice> Advise(MethodBase method)
{
yield return Advice.Basic.Before((instance, arguments) =>
{
Console.WriteLine($”Before {method.Name}({String.Join(“, “, arguments)})”);
});
yield return Advice.Basic.After((instance, arguments) =>
{
Console.WriteLine($”After {method.Name}({String.Join(“, “, arguments)})”);
});
}
}

이제 Logging Aspect를 Weaving 하는 코드를 추가하겠습니다. 어트리뷰트나 인터페이스에 매칭되지 않지만 단지 메서드 이름이 “Test”인 메서드에 대해 Logging Aspect를 Weaving 하도록 지시하고, Sample 클래스를 인스턴스화하여 Test 메서드를 호출하는 코드입니다.

class Program
{
static void Main(string[] args)
{
Aspect.Weave<Logging>(x => x.Name == “Test”);
var test = new Sample();
test.Test();
}
}

그리고 이 코드를 컴파일하여 실행하면 다음과 같이 기대한 결과가 나타납니다.

Before Test()
Hello, World!
After Test()
Press any key to continue . . .

무엇이 달라졌는가

CNeptune 패키지를 설치하면 해당 프로젝트가 생성하는 어셈블리를 Compile Time Weaving을 할 수 있도록 어셈블리를 재작성하는 절차가 MSBUILD 프로젝트의 일부가 됩니다. 패키지를 설치한 프로젝트의 CSPROJ 파일을 열어보면 다음과 같은 부분이 추가된 것을 볼 수 있습니다.

<Import Project=”..\packages\CNeptune.1.0.6\build\CNeptune.targets” Condition=”Exists(‘..\packages\CNeptune.1.0.6\build\CNeptune.targets’)” />
<Target Name=”EnsureNuGetPackageBuildImports” BeforeTargets=”PrepareForBuild”>
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition=”!Exists(‘..\packages\CNeptune.1.0.6\build\CNeptune.targets’)” Text=”$([System.String]::Format(‘$(ErrorText)’, ‘..\packages\CNeptune.1.0.6\build\CNeptune.targets’))” />
</Target>

이에 따라 만들어지는 IL 코드는 컴파일러에 의하여 만들어내는 코드와는 다르게 코드를 재정의하기 손쉬운 형태로 변경하여 내보내게 됩니다. Weaving을 실제로 호출하든 하지 않든 MSBUILD를 통해 CNeptune을 호출하도록 되어있으므로 어셈블리의 결과물은 CNeptune 패키지 적용 이전과 달라지게 됩니다.

마무리

컴파일 타임에서의 처리이지만 Weaving의 적용과 해제가 자유롭도록 되어있습니다. 위의 샘플 코드 중 Main 메서드에 아래의 코드를 추가로 더 넣어 실행해보면 역시 의도한대로 결과가 나타나게 됩니다.

Console.WriteLine();
Aspect.Release<Logging>(x => x.Name == “Test”);
test.Test();

Before Test()
Hello, World!
After Test()

Hello, World!

이와 같이 .NET에서도 오픈 소스화된 AOP 프레임워크를 찾아볼 수 있게 되었습니다. 아울러 NConcern와 CNeptune은 모두 MIT 라이선스이므로 상용 프로젝트에도 라이선스 걱정 없이 적용할 수 있습니다.

앞으로 발전이 기대되는 라이브러리입니다. 🙂

이미지 출처: https://commons.wikimedia.org/wiki/File:Effects_of_aspect_on_vegetation-_SW_Idaho.JPG

LINQPad로 Facebook Graph API 빠르게 테스트하기

C#을 사용하면서 알아두면 여러모로 유용하게 활용할 수 있는 도구로 LINQPad가 있습니다. LINQPad Developer Edition부터는 NUGET 패키지를 Query에 포함시킬 수 있는 기능도 제공이 되는데, 이 기능을 활용하여 Outercurve Foundation이 관리하는 Facebook .NET SDK NuGet 패키지를 추가하여 빠르게 Facebook Graph API를 호출할 수 있습니다.

LINQPad에서 NuGet 패키지를 추가하려면, 쿼리 창에서 오른쪽 버튼을 클릭한 다음, NuGet Package Manager 메뉴를 선택합니다.

그 다음, 검색어에 Facebook을 입력하여 검색하면, Facebook이라는 이름의 NuGet 패키지가 검색 결과 제일 처음에 나타납니다. Add To Query 버튼을 눌러 패키지 캐시에 추가한 다음, 설치가 완료되면 Add Namespace 링크를 클릭하여 쿼리에서 편하게 쓸 수 있도록 합니다.

아래 코드 조각을 테스트하기 위해서는 App ID, App Secret, Access Token을 사전에 Facebook Developer 페이지를 통하여 획득하셔야 합니다. 아래 샘플 코드에서는 관리 권한이 있는 Facebook Page에 대해 간단하게 포스팅하고, 해당 포스트의 정보를 가져오는 코드이므로 대상 Page ID도 획득해야 합니다.

string appId = "";
string appSecret = "";
string accessToken = "";
string pageId = "";

FacebookClient client = new FacebookClient(accessToken)
{
  AppId = appId,
  AppSecret = appSecret
};
dynamic result = null;

result = client.Post($"/{page_id}/feed", new
{
  message = $"Random Message {DateTime.UtcNow.Ticks.ToString()}"
});
((object)result).Dump();

result = client.Get($"/{result.id}", new
{
  fields = new string[] { "id" }
});
((object)result).Dump();

Facebook의 Graph API가 반환하는 JSON 응답 객체를 Newtonsoft JSON 라이브러리를 이용하여 C# 객체로 변환하면, 이것을 DLR 바인딩에 연결하여 필요한 프로퍼티에 액세스할 수 있습니다. 그리고 이렇게 얻어온 응답 결과를 LINQPad의 내장 Extension 메서드인 Dump 메서드로 시각적으로 잘 정리된 형태의 표로 볼 수 있습니다.

한 가지 아쉬운 점은, DLR 컨텍스트에서는 LINQPad의 Dump 확장 메서드가 제대로 작동하지 않아서, object 타입으로 캐스팅하여 DLR 컨텍스트를 해제한 다음 Dump 메서드를 호출해주어야 합니다. 실행 결과는 아래와 같습니다.

Facebook이 아니어도, Newtonsoft JSON과 HttpClient를 활용하면 비슷한 방법으로 REST API들을 테스트해볼 수 있습니다.

 

[ClouDeveloper News – Azure Edition] 2017년 1월 5일

클라우드 컴퓨팅을 중심으로 관련된 여러 기술과 업계 소식을 매주 전하는 ClouDeveloper News를 시작합니다. 파일럿 프로그램으로 구상하여 운영 중에 있으며 추후 여러 피드백과 의견 수렴을 통하여 프로그램의 틀을 갖추어 나갈 예정이오니 많은 관심과 구독을 부탁드립니다.

이번주 포커스/주요 소식

Saturday Azure Live 1701 (등록 바로가기)

Saturday Azure Live 1701이 1월 14일(토) 오후 2시부터 서울 강남 토즈1호점에서 열립니다. Microsoft Azure Korea 페이스북 그룹에서 진행하는 Saturday Azure Live는 매월 둘째 주 토요일마다 진행하는 Microsoft Azure의 기술 정보를 함께 공유하는 정기 세미나입니다. Azure에 관해 정보를 얻을 수 있을 뿐 아니라, 발표하고 싶은 주제가 있다면 스피커로! 경험담을 공유하고 싶다면 라이트닝 토크까지! 함께 하실 수 있습니다.

Agenda
Overview – 세션 소개 (발표자: Azure MVP 남정현)
Session 1 – Microsoft Conversation as a Service 소개 (발표자: 한국 마이크로소프트, 오일석 에반젤리스트)
Session 2 – Azure WebApp 개념원리 (발표자: (주)바풀 CTO, Azure MVP 김영재)
Session 3 – DevOps와 Hybrid Cloud (발표자: 한국 Azure 사용자 그룹, 김세준)

Azure Functions deprecating preview versions – 구 버전의 Azure Function을 사용하시는 경우 2017년 2월 1일 전에 1.0 버전 이상으로 업그레이드해야 합니다.

General availability: Larger block blobs in Azure Storage – Azure Storage에 더 큰 크기의 Block BLOB 업로드가 지원됩니다. 195GB에서 최대 4.77TB까지 업로드가 가능하며, 모든 Azure 리젼에서 사용할 수 있습니다.

MSRT December 2016 addresses Clodaconas, which serves unsolicited ads through DNS hijacking – Microsoft 악성 코드 제거 도구의 새 버전이 업데이트되면서, DNS 하이재킹을 통한 MITM 공격을 유발할 가능성이 있는 악성 코드를 제거할 수 있는 기능이 새로 추가되었습니다.

Several New Azure Services now available in UK – 영국 Azure 리젼에서 다수의 Azure 서비스를 새롭게 사용할 수 있게 되었다는 소식입니다. 이 중에는 Azure Function, Power BI, Power BI Embedded, DocumentDB 도 포함되어있습니다.

Mark Russinovich Azure CTO에게 Sysinternals를 이용하여 성공적으로 문제를 해결했던 사례를 스크린샷과 로그를 포함하여 보내면, Sysinternals 책을 저자 서명과 함께 배송해주는 이벤트를 진행하고 있습니다. 트위터 전문

커뮤니티 소식

Azure 서비스 공지 사항

아티클, 기고

새로운 제품 및 서비스

활용 및 노하우

웹 캐스트

ClouDeveloper 페이스북 페이지에 댓글로 의견을 남겨주시면 뉴스 발행 및 각종 정보 전달에 반영하도록 하겠습니다. 고맙습니다.

의견 남기기: https://fb.com/cloudeveloper

Ubuntu on Windows 10으로 GTK# 응용프로그램 개발해보기

Windows 10의 대규모 업데이트에서 개발자들에게 주목을 받고 있는 기능들이 여러가지가 있습니다. 그중에서도 Ubuntu on Windows 10에 대한 관심이 많이들 있으실텐데, 이번 아티클에서는 저 나름대로 찾아본 Ubuntu on Windows 10을 이용한 GTK# 기반의 클라이언트 응용프로그램 개발 방법을 소개해보려고 합니다.

왜 Ubuntu on Windows 10인가?

VM을 사용할 때의 이점은 완전히 독립된 환경을 만들 수 있다는 것이지만, 달리 표현하면 관리해야 할 컴퓨터의 숫자가 늘어난다는 것을 의미하기도 합니다. Ubuntu on Windows 10이 돋보이는 이유는 바로 간편성에 있습니다.

Ubuntu on Windows 10은 Subsystem for Linux 라는 새로운 기능 위에서 작동합니다. 과거에 서버용으로는 Subsystem for Unix라는 기술이 있었는데, 이 때와는 다르게 Windows 운영 체제의 환경과는 분리된 샌드박스된 환경 위에서 실행되고, 바이너리 수준의 호환성을 보장한다는 것이 차이점입니다. 그렇기에 실용적으로 기능을 활용할 수 있고, 호스트로 실행되는 Windows 운영 체제의 안정성을 해칠 만한 상황을 최소화할 수 있어 마음놓고 사용할 수 있습니다.

Ubuntu on Windows 10으로 할 수 있는 일

Ubuntu on Windows 10은 실제 Ubuntu Linux와는 다릅니다. 어디까지나 User Mode에서 실행되는 바이너리 파일에 대한 실행 환경만을 보장할 뿐, 프로덕션 환경에서 실행될 서버를 띄우거나, Windows Shell을 대체하기 위한 목적, 혹은 커널 드라이버 개발 등의 목표를 가지고서는 사용이 쉽지 않고 불편합니다.

VM 없이 Ubuntu Linux에서 실행해볼 필요가 있는 응용프로그램을 사용하거나 테스트하기 위한 용도로만 초점이 맞추어져야 하며, 아티클에서 다루는 모든 내용은 “개발과 테스트”를 전제로 합니다.

준비할 사항

Ubuntu on Windows 10을 시스템에 이미 설치하셨다는 것을 전제로 이 아티클을 참조하여 주십시오. 자세한 설치 방법은 이곳을 참조하여 주십시오.

이 글을 작성한 2016년 8월 현재, Windows 10의 1주년 업데이트가 정식으로 나온 현 시점까지도 Ubuntu on Windows 10과 서브 시스템은 베타 상태에 있습니다. 그리고 이와 관하여 한국어 지원 역시 완전하지 않습니다.

Subsystem을 설치한 후에 Ubuntu on Windows 10을 lxrun으로 처음 설치하실 때에는 Windows 사용자 계정 이름이 영어로 되어있는 것을 춴합니다. 또한 콘솔에서 한국어 출력이 자연스럽지 않은데, 개인적으로는 로캘 설정을 시스템 기본 설정 대신 영어와 UTF-8 인코딩 셋으로 변경하시는 것을 권해드립니다. 변경하려면 bash 셸을 실행한 다음 아래 명령어를 입력합니다.

sudo update-locale LANG=en_US.UTF8

입력한 다음 bash 셸을 종료하고 다시 시작하면 모든 표시 언어가 미국 영어로 변경되어 나타나게 될 것입니다.

Mono 설치하기

.NET Core의 런타임이 RTM이 출시되었지만 그동안 크로스플랫폼 기반 .NET 개발의 중추적인 역할을 담당하고 있었던 것은 Mono 프레임워크였습니다. 현재까지도 우리가 필요로 하는 대다수의 기능은 .NET Core가 아니라 여전히 Mono 기반이며, .NET Core에서도 자체 런타임 대신 전체 버전의 .NET Framework가 필요한 경우 Mono을 사용하므로 여기서는 Mono의 설치를 먼저 다루도록 하겠습니다.

Ubuntu on Windows 10에 제공되는 Ubuntu Linux는 14.04 (trusty) 버전이며, 버전을 확인해보면 다음과 같습니다.

root@DESKTOP-R1OP5CI:/mnt/c/Users/rkttu# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:        14.04
Codename:       trusty

14.04 버전을 기준으로 Mono를 설치하는 과정을 진행해보도록 하겠습니다. Mono 최신 버전은 운영 체제가 제공하는 패키지 저장소가 아닌 자체 저장소를 통해서 다운로드해야 설치가 가능한데, Ubuntu 계열 운영 체제를 위한 저장소를 사용한 설치 방법 안내 페이지는 이곳을 참조합니다.

아래 명령어를 실행하여 외부 패키지 저장소를 시스템에 등록합니다.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
sudo echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo echo "deb http://download.mono-project.com/repo/debian wheezy-apache24-compat main" | sudo tee -a /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get update

그 다음, mono-complete, referenceassemblies-pcl, monodevelop 그리고 xinit 패키지를 아래 명령어를 실행하여 설치합니다. X-Windows 환경도 이 과정에서 종속성 체인에 의하여 모두 설치가 이루어지므로 디스크 공간 사용량이 크게 늘어나니 주의해야 합니다.

sudo apt-get install mono-complete referenceassemblies-pcl monodevelop xinit -y

긴 설치 과정이 모두 끝나면 다음 명령어를 실행하여 mono와 mcs 컴파일러가 최신 버전으로 설치되었는지 확인합니다.

rkttu@DESKTOP-P834HKI:/mnt/c/Users/rkttu$ mono --version
Mono JIT compiler version 4.4.2 (Stable 4.4.2.11/f72fe45 Fri Jul 29 09:58:49 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
rkttu@DESKTOP-P834HKI:/mnt/c/Users/rkttu$ mcs --version
Mono C# compiler version 4.4.2.0

MonoDevelop 실행을 위한 설정

이제 개발 환경의 준비는 모두 마무리했고, X Window를 실행하기 위한 준비를 해야 합니다. Windows OS에서는 Xming 서버라는 X Window 호환 서버를 설치할 수 있으며 Ubuntu on Windows에서 쉽게 연결할 수 있습니다.

https://sourceforge.net/projects/xming/ 에서 최신 버전의 Xming 서버를 우선 설치하도록 합니다. 설치 후에는 직접 Xming 서버를 한 번 실행하여 아래 그림과 같이 트레이에 실행 중인 모습을 확인해야 합니다.

Xming 서버와 연결하는 설정을 현재 세션에서만 사용하려면 터미널에서 다음 명령어를 입력하면 됩니다.

export DISPLAY:=0

그리고 위의 명령어를 현재 로그인한 사용자에 대해서만 항상 적용하려면 아래 명령어를 실행하여 bashrc 파일에 내용을 저장하고 bash 셸을 다시 시작합니다.

nano ~/.bashrc

설정을 적용한 다음에는 아래 명령어를 실행합니다.

monodevelop

잠시 기다리면 아래 그림과 같이 Windows 10에서 리눅스 버전으로 실행되는 MonoDevelop의 화면이 보입니다.

계속하기 전에, 사용 상의 편의를 위하여 단축 키 바인딩과 글꼴을 Visual Studio에 가깝게 변경해보겠습니다. Edit – Preference 메뉴를 선택한 다음, Environment – Key Binding에 가서 Visual Studio 템플릿을 선택하고, Font에서 원하는 서체와 크기를 지정합니다.

만약 나눔고딕코딩 같은 서체가 필요하다면 다음의 명령어를 실행하고 MonoDevelop을 다시 실행하여 서체 목록을 보면 목록에 표시될 것입니다. D2Coding과 같은 서체는 수동으로 OTF나 TTF 파일을 설치하는 방법을 설명하는 가이드를 참고하시면 되겠습니다.

sudo apt-get install fonts-nanum fonts-nanum-coding -y

첫 GTK# 프로젝트 만들고 실행해보기

MonoDevelop이 실행되었으니 GTK# 프로젝트를 한 번 만들어보겠습니다. Visual Studio를 사용하시는 것이 어느정도 익숙하다는 전제에서 출발하겠습니다.

새 솔루션 만들기 메뉴를 선택하면 다음과 같이 화면이 나타날 것입니다. GTK# 2.0 프로젝트 템플릿을 선택합니다. (VB.NET 언어는 제대로 지원되지 않습니다.)

프로젝트 생성 시 Location에서 사용자 홈 디렉터리 아래로 경로를 한 번 선택해주는 것이 좋습니다.

프로젝트를 만든 다음에는 User Interface 트리 아래의 MainWindow를 더블 클릭하여 엽니다.

그러면 디자이너가 열립니다. 여기서 화면 오른쪽의 Toolbox 탭을 더블 클릭하면 우리가 아는 Windows Forms나 WPF 디자이너와 마찬가지로 팔레트가 나타납니다.

GTK#은 Windows Forms와는 다르게, 혹은 WPF처럼 컨테이너라는 부모가 있는 것을 전제로 하며, Windows Forms 처럼 디자인하려면 우선 Fixed 컨테이너가 배치되야 합니다. Fixed 컨테이너를 배치하고 그 위에 버튼을 올려보면 위의 그림과 비슷하게 됩니다.

버튼을 선택하고, Properties 탭을 더블 클릭한 후, Signals 탭을 선택하면 버튼에 대해 지정할 수 있는 이벤트들이 표시됩니다. Button Signals를 펼치고 Clicked 항목을 더블 클릭하면 코드 비하인드에 자동으로 지금 선택한 버튼에 대한 처리기 메서드가 추가됩니다.

이제 디자이너 하단의 Sources 버튼을 클릭하고, 방금 추가했던 이벤트 처리기에 코드를 작성합니다. (메서드 이름은 상황에 따라 다를 수 있습니다.)

  protected void OnButton2Clicked (object sender, EventArgs e)
    {
        MessageDialog md = new MessageDialog (null, DialogFlags.Modal, MessageType.Info, ButtonsType.Ok, "test");
        md.Run ();
        md.Destroy ();
    }

이제 F5키를 눌러 프로젝트를 빌드하고 디버거에 연결합니다. 화면이 나타나면 버튼을 클릭했을 때 다음과 같이 표시될 것입니다.

덤으로, 지금 이 상태가 작업 관리자에서는 어떻게 표현되고 있을까요? Mono 4.x 이후부터 공식적으로 채택된 SGEN을 런타임으로 사용하기 때문에 macOS에서 mono 기반 응용프로그램을 돌릴 때와 마찬가지로 mono-sgen 프로세스가 실행 중인 상태인 것을 볼 수 있습니다.

결론

Windows 10에 Linux 서브 시스템이 도입되었다는 것은 시사하는 바가 무척 많으며, 보신 것과 같이, GTK#을 Windows OS로 포팅하지 않고, 네이티브 리눅스와 유사한 환경에서, MonoDevelop으로 쉽게 개발할 수 있는 상태가 되었습니다.

MonoDevelop은 GTK# 만이 아니라 콘솔 프로그램, 그리고 ASP.NET 개발 환경도 지원합니다. 애석하게도 XSP4는 지금 이 아티클을 작성하는 시점에서 제대로 작동하지 않고 있지만 곧 업데이트가 이루어질 것이라고 생각합니다.

또한 MonoDevelop은 NuGet 패키지 설치도 지원하므로 필요한 패키지가 있으면 쉽게 설치할 수 있습니다.

이후에 TCP Listener를 기반으로 하는 서버 애플리케이션이나 ASP.NET Core 실행 사례도 추가 아티클 상에서 살펴보겠습니다.

Electron으로 크로스 플랫폼 데스크톱 앱 만들기 #1 – 프로젝트 스캐폴딩

요즈음 모바일 앱은 Xamarin, Cordova 등 다양한 프레임워크를 이용하여 개발하는 사례가 매우 많습니다. 하지만 상대적으로 Desktop App은 이제 막 크로스플랫폼 앱 개발에 대한 논의가 시작되는 단계여서 상대적으로 정보가 많이 적고, 사용할 수 있는 리소스가 모바일 크로스플랫폼 개발에 비해서는 적은 편입니다.

연속되는 아티클 시리즈를 통하여 데스크톱 앱을 크로스플랫폼으로 개발하려고 할 때 시작할 수 있는 유용한 선택지인 Electron과 EdgeJS의 결합 시나리오에 대해 살펴보려고 합니다. 이번에는 그 중 가장 기초가 되는 처음 Electron 프로젝트를 만드는 과정을 살펴보려고 합니다.

Electron에 대하여

Electron은 Github의 크로스플랫폼 에디터인 Atom을 위하여 처음 개발되었고, 그 이후로 많은 발전을 거쳐 여러 애플리케이션의 기반 프레임워크로 현재는 널리 사용되고 있습니다. 최근 큰 주목을 받고 있는 Visual Studio Code는 물론, Slack, 잔디 등 국내외 여러 최신 소프트웨어들이 Electron을 기반으로 하이브리드 + 크로스플랫폼 소프트웨어를 개발하고 있습니다.

Electron의 생태계

Electron은 기술적으로 NodeJS의 기능과 Chromium의 렌더링 엔진을 모두 사용할 수 있습니다. 이 덕분에 Node Package Manager (NPM)과 Bower의 기능을 모두 사용할 수 있어 UI는 익숙하게 사용할 수 있는 jQuery, jQuery UI 및 jQuery Mobile이나 최근 유행하고 있는 Angular 2, React 등을 택할 수 있고, 비즈니스 로직 부분은 TypeScript나 CoffeeScript 등을 활용하여 개발할 수 있습니다.

Electron의 확장성은 여기서 그치지 않고 .NET과의 상호 운용 기능을 제공하는 EdgeJS와도 연동도 제공하고 있습니다. EdgeJS는 Windows에서는 .NET Framework 4.5 이상, Linux와 macOS에서는 Mono 4.x 이상의 프레임워크와 연동되며, C#, F# 등 다양한 언어와의 바인딩과 기존 클래스 라이브러리의 재사용을 모두 소화할 수 있습니다. 기존에 개발했던 Windows Forms나 WPF 기반의 Desktop App을 크로스플랫폼으로 전환하는 것을 염두에 두고 계시다면 현실적인 선택지 중 하나가 될 수 있습니다.

마지막으로, 데스크톱 앱을 수익화하기 위한 방법에서도 Electron은 이제 완벽한 선택지라고 할 수 있습니다. Windows의 경우 이 글을 작성하는 현재 2016년 여름에 Windows 10 Anniversary Update를 통하여 Native App을 스토어에 공식적으로 게시할 수 있게 됨에 따라 Electron App을 스토어에 등록할 수 있고, Linux의 경우 다양한 경우의 수가 있겠지만 데스크톱에서 가장 널리 쓰이는 Ubuntu Software Store에 등록할 수 있으며, Mac App Store로의 Electron App 등록은 이전부터 계속 가능했습니다.

이러한 생태계 아래에서 기존의 Native Application이나 .NET Managed Application을 Electron을 기반으로 리뉴얼을 고려해보실 수 있습니다.

첫 Electron 프로그램 만들기

Electron 기반의 개발 환경은 Windows, Linux, macOS 플랫폼이면 쉽게 구축이 가능합니다. 그 중에서도 이번 아티클에서는 Visual Studio Code를 기반으로 구축하는 예를 들어보려고 합니다.

Visual Studio Code, NodeJS, NPM, Bower를 시스템에 이미 설치한 상태임을 가정하고 진행해보도록 하겠습니다.

작업 디렉터리를 새로 하나 만들고, 해당 디렉터리에서 아래 명령을 실행하여 package.json과 bower.json을 만들어 프로젝트 기준점을 잡도록 합니다.

npm init
bower init

그 다음, electron-prebuilt 패키지를 개발 종속성 패키지로 설치하여 개발 과정 중에 Electron에 연동하여 사용할 수 있게 합니다.

npm install --save-dev electron-prebuilt

Bower를 이용하여 jQuery Mobile 패키지를 설치하겠습니다. 패키지 이름이 jquery-mobile-bower인 것을 설치해야 즉시 사용 가능한 jQuery Mobile 패키지가 설치되니 이름에 주의하여 주십시오.

bower install --save jquery-mobile-bower

이제 Electron 엔진을 사용하여 창을 띄우고 첫 UI를 표시하도록 코드를 조금 추가해보겠습니다.

package.json 파일을 만들 때, 시작점이 되는 JavaScript 파일의 이름을 따서 새 JavaScript 파일을 만듭니다. 예를 들어, package.json 파일이 아래와 같이 되어있다면 index.js 파일을 새로 만듭니다.

{
  "name": "sample",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "electron-prebuilt": "^1.2.2"
  },
  "dependencies": {
    "electron-edge": "^5.0.3-pre1"
  }
}

index.js 파일을 다음과 같이 만듭니다.

const electron = require('electron');
// Module to control application life.
const {app} = electron;
// Module to create native browser window.
const {BrowserWindow} = electron;

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let win;

function createWindow() {  
  // Create the browser window.
  win = new BrowserWindow({width: 800, height: 600});

  // and load the index.html of the app.
  win.loadURL(`file://${__dirname}/index.html`);

  // Emitted when the window is closed.
  win.on('closed', () => {
    // Dereference the window object, usually you would store windows
    // in an array if your app supports multi windows, this is the time
    // when you should delete the corresponding element.
    win = null;
  });
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.on('ready', createWindow);

// Quit when all windows are closed.
app.on('window-all-closed', () => {
  // On OS X it is common for applications and their menu bar
  // to stay active until the user quits explicitly with Cmd + Q
  if (process.platform !== 'darwin') {
    app.quit();
  }
});

app.on('activate', () => {
  // On OS X it's common to re-create a window in the app when the
  // dock icon is clicked and there are no other windows open.
  if (win === null) {
    createWindow();
  }
});
위의 코드에서 index.html 파일을 로드하도록 하였으므로, index.html 파일을 아래 코드와 같이 만듭니다. 아래 코드의 자세한 내용은 jQuery Mobile 튜토리얼을 참고하시면 이해하기 쉽습니다. (맥락을 정확하게 유지하기 위하여 jQuery Mobile에 대한 내용은 다루지 않겠습니다.)
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Hello World!</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="Stylesheet" media="all" type="text/css" href="bower_components/jquery-mobile-bower/css/jquery.mobile-1.4.5.css" />
    <style type="text/css" media="all">
    body { cursor: default; }
    </style>
    <script type="text/javascript" src="compat.js"></script>
    <script type="text/javascript" src="bower_components/jquery/jquery.min.js"></script>
    <script type="text/javascript" src="bower_components/jquery-mobile-bower/js/jquery.mobile-1.4.5.min.js"></script>
</head>
<body>
    <div data-role="page" id="start">
        <div data-role="header">
            <h1>Welcome To My Homepage</h1>
        </div>
        <div data-role="main" class="ui-content">
            <p>I Am Now A Mobile Developer!!</p>
            <a href="#lastStep">Go to Next Page</a>
        </div>
        <div data-role="footer" data-position="fixed">
            <h1>Footer Text</h1>
        </div>
    </div>
    <div data-role="page" id="lastStep">
        <div data-role="header">
            <h1>Welcome To My Homepage</h1>
        </div>
        <div data-role="main" class="ui-content">
            <a href="#confirmDialog">End</a>
        </div>
        <div data-role="footer" data-position="fixed">
            <h1>Footer Text</h1>
        </div>
    </div>
    <div data-role="page" data-dialog="true" id="confirmDialog">
        <div data-role="header">
            <h1>Welcome To My Homepage</h1>
        </div>
        <div data-role="main" class="ui-content">
            <a href="#start">Go to Start page</a>
        </div>
    </div>
</body>
</html>
앞의 단락에서 이야기한 것처럼, Electron은 NodeJS와 통합된 실행 환경을 사용하고 있습니다. 이렇게 하면서 module 프로퍼티가 일반 웹 브라우저와는 다르게 미리 정의가 되는데, 이 때문에 jQuery가 전역 객체로 설정되지 않습니다. (https://blog.outsider.ne.kr/1170 아티클의 내용을 보고 도움을 얻을 수 있었습니다.)
이런 동작은 버그가 아니고 By-Design 사항입니다. 물론 필요에 따라 Chromium의 JavaScript 컨텍스트만 사용하도록 제한할 수 있지만 이렇게 할 경우 Electron의 강력한 기능을 활용할 수 없으므로 이 방법 대신 아래 코드를 compat.js로 저장하여 HTML 페이지에서 먼저 참조하고 그 다음에 jQuery를 로드하도록 수정하여 jQuery와 NodeJS 모듈을 동시에 사용할 수 있게 하려고 합니다.
window.nodeRequire = window.require;
window.nodeExports = window.exports;
window.nodeModule = window.module;
delete window.require;
delete window.exports;
delete window.module;
위의 코드를 사용하여 require, exports, module 프로퍼티를 nodeRequire, nodeExports, nodeModule로 이동시키고, jQuery가 정상적으로 초기화될 수 있게 합니다. 나중에 electron과 연동을 할 때에는 새 이름으로 정의된 객체를 사용하도록 하여 어렵지 않게 연동이 가능하게 됩니다.
이렇게 코드를 구성하고, 아래와 같이 명령을 작업 디렉터리 내에서 실행하면 앱이 실행됩니다.
node_modules/.bin/electron .
001
Production 버전으로 패키지를 만든 것이 아니고, 메뉴 등이 그대로 표시되므로 Developer Tool을 이용할 수 있습니다. Developer Tool을 View – Toggle Developer Tool 메뉴로 켜고 끌 수 있으며, 실행하면 창 하단/우측에 붙어서 나오거나 아래 그림처럼 별도의 창으로 띄울 수도 있습니다.
002

다음 아티클에서는

다음 아티클에서는 Visual Studio Code와 통합 디버깅 환경을 설정하는 방법과 JavaScript 디버깅을 손쉽게 수행할 수 있는 방안을 살펴볼 에정입니다.

IDisposable 패턴의 올바른 구현 방법

.NET Framework에서 새로운 클래스를 만들 때 여러가지 메모리 관리 디자인 패턴과 기법을 적용할 수 있지만, 한시적으로 사용해야 할 필요가 있는 자원들을 묶어서 관리할 때에는 IDisposable 패턴을 적극적으로 활용하는 것이 매우 유용합니다.

하지만 생각보다 IDisposable 패턴을 제대로 구현해서 사용하는 것은 쉽지 않으며 잘못 구현하기 쉽습니다.

이 아티클에서는 IDisposable 패턴을 구현하는 몇 가지 일반적인 전략들을 소개합니다. 잘못 설명된 부분이 있거나 보충이 필요한 부분은 댓글로 피드백을 자세히 남겨주시면 적극 반영하겠습니다.

IDisposable 인터페이스에 대한 이해

IDisposable 인터페이스가 제공하는 Dispose 메서드는 명시적이고 코드 작성자가 직접 호출할 수 있는 finalizer로, 이 메서드가 불리면 가비지 컬렉터에 의하여 나중에 호출되는 finalizer의 역할을 대체하도록 되어있습니다. 물론, 메모리 상에 할당된 메모리 블록의 해제까지 건너뛴다는 의미는 아닙니다.

그리고 무엇을 Dispose 메서드에서 제거해야 하는지 기준을 세운다면 객체에 대한 소유 권한을 정의하는 것이 필요합니다. 적어도 다음의 경우에는 확실히 Dispose 메서드 내에서 정리가 되어야 합니다.

  • 해당 객체를 Dispose 하게 되면 외부에서 더 이상 사용하는 것이 의미가 없는 객체 (예를 들어 클래스 내부에서 사용하던 파일 입출력 관련 객체, 비동기 작업을 위하여 만들어 놓은 스레드 관련 객체)
  • 외부에서 전달받은 객체이지만 객체의 생명 주기를 위탁하여 관리하도록 지정한 객체 (예를 들어 StreamReader나 StreamWriter가 객체 생성 시 인자로 Stream을 받는 사례)

가장 기본이 되는 IDisposable 구현 패턴

.NET 은 finalizer에 해당되는 멤버를 재정의할 수 있습니다. 하지만 finalizer가 언제 호출이 될 것인지 기약할 수 없으므로 이 finalizer를 대신하여 좀 더 이른 시기에 명시적으로 소멸자와 동등한 효과를 낼 수 있도록 만든 것이 바로 IDisposable.Dispose 메서드가 되겠습니다.

IDisposable 패턴을 처음 구현할 때에는 다음의 사항들이 핵심이 됩니다.

  • protected virtual void Dispose(bool disposing) 메서드를 추가합니다. sealed 클래스에 대해서는 private void Dispose(bool disposing)으로 바꾸어 정의합니다.
  • 객체가 dispose 처리가 이루어진 상태인지를 관리할 수 있는 boolean 필드를 하나 추가하고 이 필드는 기본값을 false로 설정합니다.
  • Dispose(bool disposing) 호출 시 다음의 로직을 구현합니다.
    • 만약 객체가 dispose 상태인 경우에는 함수를 종료합니다.
    • 객체가 dispose 상태임을 필드에 지정합니다. (true로 설정)
    • disposing 매개 변수의 상태와 관계없이 P/Invoke 등을 활용하여 메모리 할당을 받은 나머지 모든 리소스들에 대해 할당을 해제하는 코드를 추가합니다.
    • disposing 매개 변수가 true로 전달되는 경우는 명시적으로 Dispose 메서드를 호출한 경우이며, 이 때에 다른 모든 IDisposable을 구현하는 객체들을 Dispose 처리합니다.
  • IDisposable.Dispose 메서드 구현 시 Dispose(true)를 호출하고 finalizer 호출을 건너뛰기 위하여 GC.SuppressFinalize(this)를 호출합니다.
  • 소멸자에서는 Dispose(false)를 호출합니다.

다음은 코드 예시입니다.

public class DisposableSample : IDisposable
{
    public DisposableSample()
    { }

    ~DisposableSample()
    {
        this.Dispose(false);
    }
    
    private bool disposed;

    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed) return;
        if (disposing)
        {
            // IDisposable 인터페이스를 구현하는 멤버들을 여기서 정리합니다.
        }
        // .NET Framework에 의하여 관리되지 않는 외부 리소스들을 여기서 정리합니다.
        this.disposed = true;
    }
}

IDisposable 객체의 컬렉션에 대한 소거

소켓, 스레드 풀, 혹은 커넥션 풀 같은 컬렉션을 객체 내부에 보관해야 하는 경우도 있습니다. 이러한 경우에도 컬렉션 내의 모든 IDisposable 객체에 대해서 정리를 하는 것이 필요합니다.

  • 컬 렉션 내의 모든 요소가 IDisposable 인터페이스를 구현하고 있다면 Dispose(bool disposing) 메서드에서 disposing이 true일 때 정리를 하면 됩니다. 그렇지 않은 경우, disposing 매개 변수의 상태에 무관하게 정리합니다.
  • Dispose 작업 도중 새로운 항목이 추가되는 것을 방지하기 위하여 disposed 필드를 확인하도록 하는 코드를 추가해야 할 수 있습니다.
  • 컬렉션 내의 모든 요소를 배열에 복사하여 Immutable Collection으로 변환한 다음 하나씩 방문하여 Dispose를 진행하고, 최종적으로 컬렉션의 요소들을 모두 제거합니다.

다음은 코드 예시입니다.

public class DisposableSample : IDisposable
{
    public DisposableSample()
    {
        this.items = new List<IDisposable>();
    }

    ~DisposableSample()
    {
        this.Dispose(false);
    }
    
    private bool disposed;
    private List<IDipsosable> items;

    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed) return;
        if (disposing)
        {
            // IDisposable 인터페이스를 구현하는 멤버들을 여기서 정리합니다.
            IDisposable[] targetList = new IDisposable[this.items.Count];
            this.items.CopyTo(targetList);
            foreach (IDisposable eachItem in targetList)
            {
                eachItem.Dispose();
            }
            this.items.Clear();
        }
        // .NET Framework에 의하여 관리되지 않는 외부 리소스들을 여기서 정리합니다.
        this.disposed = true;
    }
}

Dispose 메서드 내의 예외 처리

만약 Dispose 메서드를 실행하는 도중에 예외가 발생한다면, CA1065의 지침에 따라 명시적인 Dispose 호출이었든 아니었든 예외를 전파하지 않도록 처리하는 것이 필요합니다. 다만 명시적으로 Dispose를 호출하면서 예외가 발생했다면 예외를 전파하지 않는 대신 적절한 예외 처리는 필요합니다.

이 부분에 대한 자세한 내용은 https://msdn.microsoft.com/ko-kr/library/bb386039.aspx 페이지의 내용을 참고하시면 도움이 될 것입니다.

컬렉션 내의 모든 요소들을 Dispose 하는 코드를 조금 더 보강하면 다음과 같이 고쳐쓸 수 있겠습니다.

public class DisposableSample : IDisposable
{
    public DisposableSample()
    {
        this.items = new List<IDisposable>();
    }

    ~DisposableSample()
    {
        this.Dispose(false);
    }

    private bool disposed;
    private List<IDisposable> items;

    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed) return;
        try
        {
            if (disposing)
            {
                // IDisposable 인터페이스를 구현하는 멤버들을 여기서 정리합니다.
                IDisposable[] targetList = new IDisposable[this.items.Count];
                this.items.CopyTo(targetList);
                foreach (IDisposable eachItem in targetList)
                {
                    try { eachItem.Dispose(); }
                    catch (Exception ex) { /* 예외 처리를 수행합니다. */ }
                    finally { /* 정리 작업을 수행합니다. */ }
                }
                this.items.Clear();
            }
            try { /* .NET Framework에 의하여 관리되지 않는 외부 리소스들을 여기서 정리합니다. */ }
            catch { /* 예외 처리를 수행합니다. */ }
            finally
            {
                /* 정리 작업을 수행합니다.  */
                this.disposed = true;
            }
        }
        finally { /* 정리 작업을 수행합니다. */ }
    }
}

소유하고 있는 객체들에 대한 Dispose 또는 정리 작업들을 각각 try, catch, finally 블록안에 두어 예외가 발생하면 적절한 예외 처리를 할 수 있게 하고, Dispose 메서드 전체에 대해서 try, finally 블록 안에 두어 예외가 전파되지 않도록 하였습니다.

결론

.NET Framework 기반의 응용프로그램이 안정적으로 장시간 실행될 수 있게 만들어야 할 때 고려해야 할 요소들 가운데에서 가장 비중있게 다루어야 할 부분이 바로 메모리 관리입니다. IDisposable 인터페이스를 통한 명시적인 finalizer 호출은 적절하게 활용하면 응용프로그램의 메모리 관리를 단순하게 만드는데 큰 도움을 줍니다.

IronPython으로 Windows NT 서비스 만들어서 띄우기

안녕하세요. Windows Azure MVP 남정현입니다.

IronPython은 이제 다른 Python Implementation과 어깨를 나란히 할 수 있는 수준까지 완성도가 개선되었습니다. Python을 이용해서 흔히 기대하는 NumPy, SciPy 같은 수학 및 공학용 라이브러리는 당연히 쉽게 처리할 수 있고, 이를 기반으로 하는 NLTK (Natual Language Tool Kit) 라이브러리도 약간의 불편함이 따르기는 하나 종속성을 충족하면 자연어 처리도 원활하게 수행합니다.

그리고 당연하다면 당연한 이야기이지만 Windows NT 서비스를 IronPython으로 구현하는 것도 생각해볼 수 있습니다. Windows NT 서비스를 관리 언어를 이용하여 개발하는 것 자체는 그렇게 새로울 것이 없습니다만, 한 가지 많이 오해를 하는 부분이 있는데 Visual Studio가 제공하는 템플릿이 아니면 만들 방법이 없는 것 처럼 여겨지는 것 같습니다. 그러나 실제로는 전혀 그렇지 않으며, .NET Framework의 실행 모델을 처리할 수 있는 프로그래밍 언어는 모두 간편하게 System.ServiceProcess.dll 어셈블리가 제공하는 SCM 상호 작용 컴포넌트를 쉽게 이용할 수 있습니다.

그렇다면 IronPython을 이용해서 Windows NT 서비스를 개발하려면 어떻게 해야 할까요? 생각보다 단순합니다. 준비물은 이 글을 쓰는 현 시점에서 최신 버전인 IronPython 2.7 패키지와 관리자 권한만 있으면 됩니다. 만약 sc.exe 유틸리티가 없다면 이 유틸리티가 이번 강좌에서는 꼭 필요하므로 Windows SDK를 찾아보시기 바랍니다.

초간단 IronPython 기반 Windows NT 서비스 코드 살펴보기

글을 쓰는 것이 무안할 정도로 정말 초간단합니다.

import clr
clr.AddReference(‘System.ServiceProcess’)
from System.ServiceProcess import ServiceBase

class MySvc(ServiceBase):
  def OnStart(self, args):
    ServiceBase.OnStart(self, args)
    print args
  def OnStop(self):
    ServiceBase.OnStop(self)

svc1 = MySvc()
ServiceBase.Run(svc1)

코드의 각각의 줄을 하나씩 살펴보도록 하겠습니다.

우선 처음의 세 줄은 CLR 모듈을 로드해서 System.ServiceProcess 어셈블리를 현재 IronPython의 스코프에서 사용할 수 있도록 준비하는 과정입니다. 관리되는 언어로 Windows NT 서비스를 등록하고 SCM과 상호 작용하기 위해서 필요한 모든 코드가 이 어셈블리에 들어있다고 보시면 되겠습니다.

그리고 Windows NT 서비스의 API를 객체 지향 방식으로 모델링한 ServiceBase 클래스를 상속받는 새로운 클래스를 하나 만들어야 합니다.

Python 문법에 익숙하지 않은 분들을 위하여 부연 설명을 더하면, 현재 스코프에 ServiceBase라는 클래스가 있고, 이 클래스를 상속받는 MySvc 클래스를 정의하고 있습니다. 그리고 따로 지시자는 없지만 이름이 같게 설정된 메서드는 Python 세계에서는 자동으로 메서드를 재정의한 것이 됩니다. 이에 따라, OnStart과 OnStop 메서드가 SCM에 의해서 자동으로 호출되는 메서드가 되는데, 서비스 시작 시 서비스가 잘 작동하고 있음을 알리기 위해 부모 클래스인 ServiceBase 클래스의 OnStart 메서드를, 그리고 프로세스 종료를 해도 괜찮음을 알리기 위해 OnStop 메서드를 호출합니다. 그리고 self라는 인자는 인스턴스 메서드임을 설명하는 것이며 동시에 여기에 인스턴스 참조가 전달됩니다.

그리고 따로 시작점이 있는 것이 아니라 Python 코드는 그 자체가 즉시 실행 가능한 Main 메서드 역할을 합니다. 그래서 곧바로 MySvc 클래스를 인스턴스로 만들어 ServiceBase.Run 메서드를 호출합니다.

SCM을 이용하지 않고 실행할 경우

ServiceBase.Run 메서드는 기본적으로 SCM과 상호 작용을 시작하기 위해서 필요한 기능들을 미리 제공합니다. 그런데 위의 코드를 일상적으로 사용하는 IronPython 콘솔에서 실행하면 어떻게 결과가 나타날까요? 아래와 같은 메시지가 나타납니다.

“명령줄 또는 디버거에서 서비스를 시작할 수 없습니다. 먼저 installutil.exe를 사용하여 Windows 서비스를 설치한 다음 서버 탐색기, Windows 서비스 관리 도구 또는 NET START 명령을 사용하여 시작해야 합니다.”

이런 오류 메시지가 나타납니다. 그런데 제가 하고 싶은 이야기는 정말 installutil.exe를 사용해야만 관리 언어로 만든 NT 서비스를 등록할 수 있는가에 대한 부분입니다. 결론부터 말하면 “아니오”입니다. installutil.exe를 사용하여 NT 서비스를 설치하기 위해서는 위의 코드 말고도 사실 설치 관리자 컴포넌트를 따로 구현해야 하는데, 이것을 Visual Studio Professional 이상의 버전에서는 템플릿으로 제공하고 있고 설치 프로젝트와 연계해서 만들 수 있도록 해주는 것입니다. 그러나 개인적으로는 이러한 설정을 마음에 들지 않습니다. 좀 더 간단하게 갈 수 있는 방법도 많으니까요.

그러면 installutil.exe를 대신할 도구가 있을까요? 바로 sc.exe입니다. sc.exe 자체는 개발된지 오래된 유틸리티이지만, 관리 언어로 만든 Windows NT 서비스까지도 매우 유연하게 지원합니다. 바로 EXE 파일로 만들어지는 NT 서비스에 한해서 그 진가가 십분 발휘됩니다.

SC.EXE 유틸리티를 사용하여 NT 서비스 등록하기

이제 SC.EXE 유틸리티를 사용하여 NT 서비스를 등록해보겠습니다. 그러나 SC.EXE 유틸리티로 서비스를 등록하려면 시스템 관리자 권한이 필요하므로 명령 프롬프트를 관리자 권한 또는 권한 상승 모드에서 시작해주셔야 합니다. 만약 설치 프로그램에서 구동한다면 설치 프로그램 초입에 권한 상승이 동반되므로 따로 신경쓸 것은 없습니다.

SC.EXE 유틸리티의 문법은 사소한 부분에서 실수하기 쉬우므로 문자그대로 아래와 같이 정확하게 입력해야 함을 유의하기 바랍니다.

sc create <서비스 이름> binPath= “<ipyw64.exe의 절대 경로> <IronPython 스크립트 파일의 절대 경로>”

sc create mysvc binPath= “C:Program FilesIronPython 2.7ipyw64.exe c:usersrkttu_000desktopservice.py”

다른 것보다도 binPath= 부분에 유의합니다. binPath = “~” 도 아니고 binPath =”~”도 아니며 오로지 binPath= “~” 로 해야만 올바른 문법으로 인지됩니다. binPath 옵션에 IronPython Non-Console 인터프리터의 경로와 함께 실제 구현 코드를 포함하는 IronPython 스크립트 파일을 지정했습니다.

주의할 것은 여기에 서술하는 모든 경로는 절대 경로로 서술해야 합니다.

서비스 테스트하기

정상적으로 서비스가 설치되었다면 “[SC] CreateService 성공” 이라는 메시지를 볼 수 있습니다. 그리고 서비스의 시작을 위해서 아래와 같이 명령어를 실행하거나 서비스 관리자에서 여러분이 등록한 서비스를 찾아 시작시킵니다.

C:Windowssystem32>net start mysvc
mysvc 서비스를 시작합니다..
mysvc 서비스가 잘 시작되었습니다.

그리고 서비스 중지도 잘 되는지 확인합니다.

C:Windowssystem32>net stop mysvc
mysvc 서비스를 멈춥니다..
mysvc 서비스를 잘 멈추었습니다.

팁 한가지

IronPython을 이용하여 Windows NT 서비스를 만들 수 있으므로, 복잡한 템플릿에 의존하거나 유틸리티를 사용하는 일 없이 기존 서버 로직을 얼마든지 NT 서비스로 옮길 수 있는 것은 참 바람직합니다. 하지만 NT 서비스는 디버깅하기 매우 불리한 구조를 가지고 있는데, 이를 극복할 방법이 없을지 고민을 해보게 됩니다.

Microsoft의 기술 자료 (http://msdn.microsoft.com/ko-kr/library/7a50syb3(v=vs.90).aspx) 의 내용을 참고하여 직접 서비스를 디버깅하는 것이 널리 알려진 방법입니다. 이 방법은 정말 살아있는 실제 서비스를 대상으로 디버깅을 하는 것이므로 보안 권한을 포함한 모든 사항이 가장 실제 운영 환경에 근접한 것입니다.

그러나 좀 더 단순하게 서비스 로직 자체에 대한 디버깅이나 검증이 필요하다면 다른 접근 방법이 더 좋을 수 있습니다. NT 서비스로 만들기에 앞서 보통의 콘솔 응용프로그램으로 띄울 수 있도록 핵심 로직만 발췌해서 가지고 오도록 하면, NT 서비스로 배포하기에 앞서서 핵심 로직 자체만 따로 평가할 수 있으므로 더 유용할 것입니다.

그리고 프로그램에 전달된 인자를 활용하여 -service 같은 문자열이 전달된 것을 확인할 때에만 ServiceBase.Run 메서드를 호출한다면 NT 서비스가 아닌 상태와 NT 서비스인 상태를 동시에 지원할 수 있어 더욱 유용할 것입니다.

AutoResetEvent? ManualResetEvent? 뭐가 다를까?

안녕하세요. Windows Azure MVP 남정현입니다. 이번에 살펴볼 내용은 비동기 프로그래밍에서 중요한 컨셉 중 하나인 스레드 동기화에 약방의 감초처럼 쓰이는 AutoResetEvent와 ManualResetEvent에 대해 간단한 포스팅을 준비해보았습니다. 알아두시면 유용하게 활용할 수 있을 것입니다.

StackOverflow에 있는 글을 읽어보다 재미있는 내용이 있어서 Facebook에도 포스팅을 했었습니다.

정말 알기쉽고 명료하게 비유한 글이군요. ManualResetEvent는 수동문이고 AutoResetEvent는 지하철 개찰구 내지는 자동문과 같지요. 🙂

Yes. It’s like the difference between a tollbooth and a door. The ManualResetEvent is the door, which needs to be closed (reset). The AutoResetEvent is a tollbooth, allowing one car to go by and automatically closing before the next one can get through.

출처: http://stackoverflow.com/questions/153877/what-is-the-difference-between-manualresetevent-and-autoresetevent-in-net

그런데 정말로 그런지 알아보고 싶어서 샘플 코드를 멋대로 만들어보았습니다. 다중 스레드나 이런게 아니라 그냥 단일 스레드 상에서도 차이점이 나타나는지 알아보고 싶었는데, 확실히 특징이 보였습니다. 아래의 샘플 코드가 그렇습니다.

[#M_더보기|접기|

using System;

using System.Threading;

static class Program

{

    static void Main(string[] args)

    {

        Console.Write(“[A]utoResetEvent or [M]anualResetEvent, which one? “);

        EventWaitHandle waitHandle = null;

        switch (Char.ToLower(Console.ReadKey().KeyChar))

        {

            case ‘a’:

                waitHandle = new AutoResetEvent(false);

                break;

            case ‘m’:

                waitHandle = new ManualResetEvent(false);

                break;

            default:

                waitHandle = null;

                break;

        }

        if (waitHandle == null)

            return;

        Console.WriteLine();

        waitHandle.Set();

        Console.WriteLine(“Set”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Set”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Set”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Set”);

        waitHandle.WaitOne(1000);

        waitHandle.Reset();

        Console.WriteLine(“Reset”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Reset”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Reset”);

        waitHandle.WaitOne(1000);

        Console.WriteLine(“Reset”);

        waitHandle.WaitOne(1000);

    }

}

_M#]

키보드의 M키를 눌러서 시작하면 ManualResetEvent를 사용하여 로직을 실행하는데, 이러한 경우 처음에 Set Flag가 켜진 상태 (Set 호출)에서 WaitOne 메서드를 4번 호출하게 되는데 Flag가 켜진 상태이므로 대기하지 않고 매번 호출이 빠져 나가게 됩니다. 그러나 Reset을 호출하여 Set Flag를 끈 상태에서는 WaitOne 메서드에 지정한 대기 시간만큼 실제로 대기하게됩니다.

반면 AutoResetEvent는 Set을 처음 한번 호출했을 때만 WaitOne 메서드가 무시되고 그다음부터는 계속 WaitOne 메서드에 지정한 대기 시간만큼 실제로 대기하게 됩니다. 앞서 설명했던 것 처럼 Set 메서드를 부르고 나서 이후에 벌어지는 일에 차이가 있는 셈입니다.

AutoResetEvent의 Auto란 즉, 자동으로 Reset을 호출한다는 의미이므로 비유에서처럼 톨 부스, 지하철 개찰구같은 아날로지에 대응이 가능한 것이고, ManualResetEvent의 Manual이란 방문을 열어놓고 직접 밀어서 닫지 않는 한 문이 계속 열려있는 상태의 아날로지에 대응이 가능한 것입니다.

ClickOnce의 문서화되지 않은 비관리 API 활용하기

안녕하세요. Windows Azure MVP 남정현입니다.


오늘 소개해드리려고 하는 내용은 ClickOnce용 패키지를 만들었을 때 유용하게 활용하실 수 있는 팁입니다. 보통은 같이 만들어지는 setup.exe 프로그램을 통해서 ClickOnce 패키지가 시작되도록 배포하는 것이 일반적이겠지만, 이 setup.exe를 대신하여 여러분만의 고유한 Bootstrapper를 제작할 수 있는 방법이 있습니다. 바로 ClickOnce의 주요 핵심 DLL인 DFSHIM.DLL 파일의 API 2개를 활용하는 것인데요, 지금 소개하려는 API를 보통은 rundll32.exe 프로그램을 이용해서 호출하는 것으로만 구글의 검색 결과에 보통 열거됩니다. 그러나 이 기능을 rundll32.exe 프로그램에 의존하지 않고 직접 프로그래밍 코드에서 호출할 수 있는 방법은 없을까요?


rundll32.exe로 호출하는 API에 대한 특성 이해하기


rundll32.exe 프로그램은 약간의 트릭과 암묵적인 규칙을 기반으로 동작하는 시스템 유틸리티로 다소 게으른(?) 면이 있습니다. 특수한 경우를 제외하고 일반적으로 DLL 파일은 직접 실행할 수 없고 반드시 다른 EXE 파일에 동적이든 정적이든 링크되어 사용되야만 합니다. 프로그램 개발 공수 관점에서 보면 DLL에 중요 컨텐츠를 포함시켜놓았을 경우 번번히 이런 컨텐츠를 위해서 별 의미없는 EXE 파일을 빌드해야 하는 셈인데, 이러한 낭비적 요소를 제거하기 위해서 일반화된 DLL 호스트 및 실행 프로그램을 넣게 됩니다. 그러나 잘 아시겠지만, 사실 이는 잠재적으로 보안 위협이 되는 부분도 있습니다.


다행히도 rundll32.exe는 무분별, 무절제하게 아무렇게나 들어오는 입력을 모두 받아들이는 것이 아닙니다. 이에 대한 상세한 규칙은 Microsoft KB164787 문서 (http://support.microsoft.com/kb/164787) 에 상세하게 기록되어있으며 내용을 요약하면, RUNDLL32.EXE로 호출할 수 있는 함수 시그니처는 대강 아래와 같은 형태로 제약됩니다.



  • void __stdcall <Function>W(HWND hwnd, HINSTANCE hinst, LPCWSTR lpszCmdLine, int nCmdShow);

  • void __stdcall <Function>(HWND hwnd, HINSTANCE hinst, LPCSTR lpszCmdLine, int nCmdShow);

  • void __stdcall <Function>(void);

이 글을 작성하는 현 시점에서 16비트 운영 체제는 일상적으로 사용되지 않고, 32비트 및 호환 운영 체제 가운데에서도 NT 커널을 계승하는 운영 체제가 주로 사용됨을 감안하였을 때, 보통 위와 같이 시그니처들이 있다고 볼 수 있습니다. W라는 접미사가 붙는 것은 세 번째 매개 변수가 문자열 버퍼를 포함하고 있기 때문에 적용되는 Windows 프로그래밍 환경에서의 Convention입니다. 이와 같이 Wide String을 지원하는 함수가 있다면 가장 적극적으로 먼저 쓰이게 됩니다. 그리고 해당되는 함수가 없다면 Ansi String을 지원하는 두 번째 후보가 차선책으로 쓰이게 됩니다. 만약 별도의 파라미터가 없이 불린다면 세 번째 시그니처에 해당되는 함수가 채택됩니다.


DFSHIM.DLL의 문서화되지 않은 API 두 가지


DFSHIM.DLL은 .NET Framework 2.0과 함께 배포되는 ClickOnce의 핵심 기능을 포함하는데, 확장자가 .application인 파일을 실행해주거나 ClickOnce와 직접 확장자를 연결시킬 경우 연결 프로그램으로서 실행해주는 등의 기능, 그리고 ClickOnce 캐시 저장소 초기화 등의 기능을 담당합니다. 인터넷 자료를 검색해보면 대개는 COM 기반의 API나 제한된 몇 종류의 API만을 이야기하는 것으로 이야기가 잘 보입니다.


그러나 공식적으로 사용되면서도 정확하게 문서화되어있지 않은 API가 두 종류가 있으며 사실은 더 사용하기 쉬운 API가 두 종류가 있습니다. 바로 ShOpenVerbApplication(W), CleanOnlineAppCache에 관한 것인데, 양쪽 모두 rundll32.exe로 실행하는 방법은 아래와 같다고 나오지만 실제 프로그래밍 언어에서 다루는 방법에 대한 문서가 거의 없습니다.



  • %windir%system32rundll32.exe dfshim.dll,ShOpenVerbApplication <.application 파일의 경로나 URL>

  • %windir%system32rundll32.exe dfshim.dll,CleanOnlineAppCache

위와 같이 실행하는 방법 말고 더 간단한 방법은 없을까요? 앞에서 소개한 내용을 바탕으로 시그니처를 대입하면서 맞추어보니 아래와 같이 정의할 수 있었습니다.



  • typedef void (WINAPI *ShOpenVerbApplicationWProc)(IN HWND, IN HINSTANCE, IN LPCWSTR, IN int);

  • typedef void (WINAPI *ShOpenVerbApplicationAProc)(IN HWND, IN HINSTANCE, IN LPCSTR, IN int);

  • typedef void (WINAPI *CleanOnlineAppCacheProc)(VOID);

위의 함수 포인터에 대한 선언을 활용하여 _UNICODE 매크로 선언 여부에 따라 동적으로, 그리고 선택적으로 호출할 수 있도록 만들 수 있었습니다. (Visual C++ 컴파일러 기준)


// 함수 포인터 선언
typedef void (WINAPI *ShOpenVerbApplicationWProc)(IN HWND, IN HINSTANCE, IN LPCWSTR, IN int);
typedef void (WINAPI *ShOpenVerbApplicationAProc)(IN HWND, IN HINSTANCE, IN LPCSTR, IN int);
typedef void (WINAPI *CleanOnlineAppCacheProc)(VOID);

// 조건부 매크로 선언
#ifdef _UNICODE
 #define ShOpenVerbApplicationProc ShOpenVerbApplicationWProc
 #define ShOpenVerbApplicationName “ShOpenVerbApplicationW”
#else // _UNICODE
 #define ShOpenVerbApplicationProc ShOpenVerbApplicationAProc
 #define ShOpenVerbApplicationName “ShOpenVerbApplication”
#endif // _UNICODE

// 변수 선언
 HINSTANCE hLibrary;
 ShOpenVerbApplicationProc pProc;
 CleanOnlineAppCacheProc pClearProc;

 // DLL 로드 시도 및 함수 검색 (DLL 로드에 실패한 경우 .NET Framework 설치를 유도할 수 이
 BOOL LoadDFSHIM(void) {
  hLibrary = LoadLibrary(_T(“DFSHIM.DLL”));

  if (hLibrary == NULL)
   return FALSE;

  pProc = (ShOpenVerbApplicationWProc)GetProcAddress(
   hLibrary,
   ShOpenVerbApplicationName);

  pClearProc = (CleanOnlineAppCacheProc)GetProcAddress(
   hLibrary,
   “CleanOnlineAppCache”);

  if (pProc == NULL || pClearProc == NULL) {
   pProc = NULL;
   pClearProc = NULL;
   FreeLibrary(hLibrary);
   return FALSE;
  }

  return TRUE;
 }


 // 프로그램 종료 시 호출하여 자원 할당을 해제
 VOID UnloadDFSHIM(void) {
  if (pProc)
   pProc = NULL;

  if (pClearProc)
   pClearProc = NULL;

  if (hLibrary)
  {
   FreeLibrary(hLibrary);
   hLibrary = NULL;
  }
 }


// ClickOnce application 시작 시 호출
if (this->hLibrary != NULL && this->pProc != NULL)
{
  this->pProc(NULL, NULL, _T(“ClickOnce .application 파일 경로 또는 URL”), SW_SHOW);
}

// 기존 Online 전용 App의 Cache를 삭제할 때 호출 (설치 시 문제가 있을 경우 활용 가능)
if (this->hLibrary != NULL && this->pClearProc != NULL)
{
  this->pClearProc();
}

위와 같이 C/C++ Application에서 간단하게 ClickOnce Online App 및 Offline App 설치를 호출할 수 있고, Online App Cache를 초기화할 수 있습니다.


결론


Windows Desktop App 가운데에서도 .NET으로 배포하는 App의 경우 설치 도입부부터 특별한 사용자 경험을 제공하기 위한 목적으로 위의 기능을 활용하면, setup.exe 파일 대신 여러분이 직접 디자인한 Setup Bootstrapper를 만들어 배포할 수 있고, 혹은 rundll32.exe 프로그램을 그대로 이용하여 바로가기 아이콘을 만드는데 활용할 수도 있습니다.


이 글에 대한 프리뷰 이미지 출처: http://hummingbird.tistory.com/3614