'ASP.NET'에 해당되는 글 46건

  1. 2018.11.08 [ASP.NET Core] 최신 버전에서 React+Redux+Javascript+TypeScript 를 사용하는 방법
  2. 2016.02.28 ASP.NET WebForm 에서 Dependency Injection 사용하는 방법
  3. 2013.09.24 [마이크로소프트의 몰락] .NET 개발자가 .NET 플랫폼을 떠나는 이유 (53)
  4. 2013.05.20 memcached, 분산 캐시를 이용하여 분산 Session 성능 향상 (1/2)
  5. 2011.06.17 [Visual Studio 2010 SP1] HTML5, CSS3 지원
  6. 2011.06.16 [Visual Studio 2010 SP1] ASP.NET DEPLOYABLE DEPENDENCIES
  7. 2011.06.15 [Visual Studio 2010 SP1] Razor 지원 및 WEB PLATFORM INSTALLER 통합
  8. 2011.06.14 [Visual Studio 2010 SP1] IIS EXPRESS 기능 추가
  9. 2011.06.13 [Visual Studio 2010 SP1] 실버라이트 성능 프로파일 지원
  10. 2011.05.30 Visual Studio Korea 팀의 무료 온라인 백서 공개 (1)
  11. 2011.01.10 2011년 .NET 개발자의 생존전략 (3)
  12. 2010.07.07 ASP.NET 의 WebMatrix & Razor 신 기술 소개 (1)
  13. 2010.03.12 UMC 와 함께하는 ASP.NET 해킹하기 #1
  14. 2009.10.19 ASP.NET Web Test 중 Favicon 다운로드 문제
  15. 2009.03.02 ASP.NET 서버 모델의 성능에 대한 고찰 [1] (2)
  16. 2009.03.02 ASP.NET 서버 모델의 성능에 대한 고찰 [2] (2)
  17. 2008.08.27 외부 라이브러리에서 Javascript 인텔리센스 활성화 하기
  18. 2008.08.07 Virtual Earth Server Controls 소개
  19. 2008.07.04 Umc.Core.Web.HttpCompression 소스 코드 공개
  20. 2008.06.20 실전 HTTP Compression 2 - 리소스 압축을 통해 웹 사이트에 진정한 날개를..
  21. 2008.06.20 실전 HTTP Compression 1 - HTTP 압축의 위험과 해결 방안
  22. 2008.06.16 실전 ASP.NET Session [4] - 세션상태 마이그레이션
  23. 2008.06.09 실전 ASP.NET Session [3] - 다양한 세션 관리 방법
  24. 2008.06.07 실전 ASP.NET Session [2] - 상태관리의 종류
  25. 2008.05.25 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성
  26. 2008.04.13 RewritePath 와 포스트백(Postback) 문제와 해결 방법
  27. 2008.04.06 ASPX 확장명 변경과 Visual Studio 에 적용하기
  28. 2008.01.20 웹서버의 MIME Type 등록 없이 Silverlight 의 XAML 파일 호스팅하기
  29. 2007.11.10 웹사이트를 웹 응용 프로그램으로 변환하기 (2)
  30. 2007.07.29 FTP 자격인증을 저장하는 방법

ASP.NET Core 2.1 또는 그 이상의 버전에서 dotnet new reactredux 템플릿에서 TypeScript 를 지원하지 않는다. 오직 Javascript 템플릿만 지원한다. 본 내용에서는 React+Javascript 를 React+TypeScript+Javascript 를 지원하는 환경으로 구성하는 방법을 알아본다.

1. 프로젝트 생성하기

다음의 명령을 입력하여 ASP.NET Core 의 React+Redux 프로젝트를 생성한다.

dotnet new reactredux -o aspnetcore-react-redux

프로젝트 생성이 성공하였다면 cd aspnetcore-react-redux 디렉토리로 이동한다.

2. package.json 파일 업데이트

ClientApp 디렉토리는 React+Redux 보일러플레이트가 설치된 경로이다. cd ClientApp 디렉토리로 이동한다.

ClientApp 디렉토리에 있는 package.json 파일에는 Spa 웹에서 사용할 npm 패키지를 설정할 수 있다. 이 파일을 열어 다음의 패키지를 추가한다.

package.json 파일

{
  "name": "aspnetcore_reactredux_typescript",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "bootstrap": "^3.3.7",
    "react": "^16.0.0",
    "react-bootstrap": "^0.31.5",
    "react-dom": "^16.0.0",
    "react-redux": "^5.0.6",
    "react-router-bootstrap": "^0.24.4",
    "react-router-dom": "^4.2.2",
    "react-router-redux": "^5.0.0-alpha.8",
+    "react-scripts": "1.0.17",
    "redux": "^3.7.2",
    "redux-thunk": "^2.2.0",
    "rimraf": "^2.6.2"
  },
+  "devDependencies": {
+    "react-app-rewired": "^1.6.2",
+    "react-scripts-ts": "^3.1.0",
+    "typescript": "^3.1.6",
+    "@types/jest": "^23.3.9",
+    "@types/node": "^10.12.2",
+    "@types/react": "^16.0.0",
+    "@types/react-dom": "^16.0.0",
+    "@types/react-router-bootstrap": "^0.24.4",
+    "@types/react-router-dom": "^4.2.2",
+    "@types/react-router-redux": "^5.0.0"
+  },
  "scripts": {
+    "start": "rimraf ./build && react-app-rewired start --scripts-version react-scripts-ts",
+    "build": "react-app-rewired build --scripts-version react-scripts-ts",
+    "test": "react-app-rewired test --env=jsdom --scripts-version react-scripts-ts",
+    "eject": "react-scripts eject"
  }
}

누락된 부분이 없는지 확인 후 다음의 명령으로 npm 패키지를 설치한다.

npm i

3. tsconfig.json 파일 생성

{
  "compilerOptions": {
    "baseUrl": ".",
    "module": "es2015",
    "moduleResolution": "node",
    "noUnusedParameters": false,
    "noUnusedLocals": true,
    "noImplicitAny": false,
    "target": "es6",
    "jsx": "react",
    "sourceMap": true,
    "skipDefaultLibCheck": true,
    "strict": true,
    "allowSyntheticDefaultImports": true,
    "experimentalDecorators": true,
    "strictNullChecks": true
  },
  "exclude": [
    "bin",
    "node_modules"
  ]
}

4. tslint.json 파일 생성

{
  "defaultSeverity": "error",
  "extends": [
    "tslint:recommended"
  ],
  "jsRules": {},
  "rules": {
    "interface-over-type-literal": false,
    "quotemark": false,
    "ordered-imports": false,
    "object-literal-sort-keys": false,
    "arrow-parens": false,
    "one-variable-per-declaration": false,
    "only-arrow-functions": false,
    "semicolon": [
      true,
      "ignore-interfaces"
    ],
    "no-console": false,
    "member-ordering": false,
    "variable-name": [
      true,
      "ban-keywords",
      "allow-leading-underscore"
    ],
    "member-access": false,
    "comment-format": false,
    "no-var-requires": false,
    "max-line-length": false,
    "jsx-alignment": false,
    "jsx-curly-spacing": [
      true,
      "never"
    ],
    "jsx-no-lambda": true,
    "jsx-no-multiline-js": true,
    "jsx-no-string-ref": true,
    "jsx-self-close": true
  },
  "rulesDirectory": []
}

5. config-overrides.js 파일 생성

/* config-overrides.js */

module.exports = function override(config, env) {
    //do stuff with the webpack config...
    return config;
}

6. 파일 확장자 변경

이제 Javascript 를 사용할지, TypeScript 를 사용할지 결정하여 파일 확장자를 다음과 같이 변경하면 된다. (단, 파일 확장자를 변경하지 않아도 무방하다)

  1. js -> jsx
  2. js -> tsx


자세한 소스 코드는 이 링크를 참고하기 바란다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

개요

ASP.NET WebForm 에서 Dependency Injection 을 사용하는 방법을 소개한다. IoC Container 를 이용하여 System.Web.UI.Page 를 상속하는 페이지에서 Injection 을 해야 하는데, 이를 위해 IHttpHandlerFactory 를 사용하는 방법을 소개한다.

여기에서는 필자가 꾸준히 만들어 온 Unity ContainerWindsor Castle 을 기반으로 하는 Umc.Core 프레임워크를 사용한다.Umc.Core 프레임워크에는 Unity Auto Registration 기능등이 모두 포함하기 때문에 프로젝트 셋업에 편리하다는 장점도 있다.

샘플 프로젝트는 필자의 github 에서 다운로드 받을 수 있다.
https://github.com/powerumc/WebForm-DependencyInjection 

프로젝트 셋업

먼저 프로젝트를 만들고, nuget 을 이용하여 umc.core 프레임워크를 설치한다.

nuget install umc.core

그리고, Umc.Core 에 구현에 놓은 IHttpHandlerFactory 를 샘플 프로젝트에 추가해 놓았다. 이를 web.config 에 추가해 주면 된다.

<system.webServer>
    <handlers>
      <add name="WebFormPageHandlerFactory" verb="*" path="*.aspx"  type="WebForm_DependencyInjection.FrameworkContainerPageHandlerFactory"/>
    </handlers>
</system.webServer>

FrameworkContainerPageHandlerFactory 클래스의 구현은 아래의 코드를 참고하면 된다. 다만, 아래 구현 코드에서 BuildManager.CreateInstanceFromVirtualPath 를 대신 사용하면 절대 안된다.

public class FrameworkContainerPageHandlerFactory : IHttpHandlerFactory
{
    public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
    {
        var handler = BuildManager.GetObjectFactory(url, false).CreateInstance();
        if (handler.GetType().ToString().StartsWith("ASP."))
        {
            var container = context.Application["container"] as IFrameworkContainer;
            return container.Resolve(handler.GetType().BaseType) as IHttpHandler;
        }

        return handler as IHttpHandler;
    }

    public void ReleaseHandler(IHttpHandler handler)
    {
    }
}

웹 응용프로그램 Bootstrap

그 다음 할 일은 어떤 컴포넌트들을 IoC 에 등록하고 이를 Composition 할 지 코드를 통해 구현한다. ASP.NET WebForm 에서는 Global.asax.cs 의 Application_Start 메서드에 구현하는 게 가장 적절하다.

그러나 이는 RELEASE 용 빌드인 경우가 그렇고, 개발 중인 경우, 즉 DEBUG 모드 빌드인 경우 Session_Start 에 구현해 놓는 것도 좋을 것 같다.

public class Global : System.Web.HttpApplication
{
  private static IFrameworkContainer container;

  protected void Application_Start(object sender, EventArgs e)
  {
      container = new FrameworkContainerForUnity();

      var catalog = new FrameworkAssemblyCatalog(Assembly.GetExecutingAssembly());
      var visitor = new FrameworkDependencyVisitor(catalog);
      var resolver = new FrameworkCompositionResolverForUnity((FrameworkContainerForUnity)container, visitor.VisitTypes());
      resolver.Compose();

      Application.Lock();
      Application["container"] = container;
      Application.UnLock();
    }
  }

FrameworkAssemblyCatalogFrameworkCatalog를 구현한 클래스로 컴포넌트를 등록하는 방법을 구현하는 클래스다.

FrameworkDependencyVisitor 는 catalog 에서 검색된 컴포넌트들을 구석 구석 방문해서 Comsoition 을 위해 객체 그래프를 그리는 클래스다.

FrameworkCompositionResolverForUnity 는 객체 그래프를 IoC Container 에 등록하는 클래스다.

이렇게 몇 줄의 코드로 Auto Registration 과정이 모두 끝난다.

서비스 구현

간단하게 Dependency Inection 을 테스트하기 위해서 IEmailService 인터페이스와 이를 구현한 코드다.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Web;
using Umc.Core;

namespace WebForm_DependencyInjection.Services
{
    public interface IEmailService
    {
        bool Send(string to, string contents);
    }

    [DependencyContract(typeof(IEmailService))]
    public class EmailService : IEmailService
    {
        public bool Send(string to, string contents)
        {
            HttpContext.Current.Response.Write("Send email.");
            return true;
        }
    }
}

페이지 구현

이제 모두 다 됐다. Dependency Injection 이 필요한 프로퍼티에 [DependencyInjection] 특성을 선언하면 Index 페이지 인스턴스가 생성될 때 컨테이너에 등록된 컴포넌트가 주입된다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Umc.Core;
using WebForm_DependencyInjection.Services;

namespace WebForm_DependencyInjection
{
    public partial class Index : System.Web.UI.Page
    {
        // Here.. Injection for IEmailService.
        [DependencyInjection]
        protected IEmailService EmailService { get; set; }

        protected void Page_Load(object sender, EventArgs e)
        {
            EmailService.Send("", "");
        }
    }
}


Posted by 땡초 POWERUMC

댓글을 달아 주세요

.NET 플랫폼이 나오고 십 여년 동안 마이크로소프트(Microsoft)는 .NET 플랫폼 시장을 개척하고 활성화 하기 위해 많은 투자를 아끼지 않았다. 많은 사람들이 주저 없이 .NET 개발에 뛰어 들었고, 비주얼 스튜디오(Visual Studio) 편리한 개발 도구는 .NET 플랫폼 개발에 필수 도구가 되었다.

하지만, 이제 한 때 과거의 이야기가 되어가고 있다. .NET은 새로 익히기 꺼려지는 플랫폼 중 하나가 되었고, 사회에 진출하는 새로운 .NET 개발자는 더 이상 예전처럼 양성 되지 않고 있다. 여기에 근거하는 사실을 매우 구체적으로 적고 싶으나 단순히 구체적인 한 두 가지의 문제라기 보다 복합적인 문제이므로 이를 읽는 독자는 넓은 시야로 가볍게 읽어주길 바란다.



[출처] 링크


그리고 본문에 잘못된 내용이나 사실에 근거를 대라고 지적하시는 것도 좋으나 그 정보는 직접 찾아 보고 반론을 제기해 주면 필자가 굳이 구구절절 같은 설명을 할 필요가 없어지므로 발전적인 토론이 될 것이라 생각한다.

1. .NET 플랫폼에 너무 많은 투자를 한 것

그야말로 .NET 개발 언어 중 대표적인 C#은 많은 다양한 프로그래밍 언어의 장점을 수용했다. 루비(Ruby), 파이썬(Python), 스몰 토크(Smalltalk)와 오브젝트 C(Objective C), 리스프(Lisp) 등의 프로그래밍 언어의 장점을 C# 언어에 녹아냈다. 이로써 C# 2.0, C# 3.0 시절엔 .NET 플랫폼의 춘추전국시대라고 해도 과언이 아닐 정도이다. (좋게 말하면 개방적인 언어가 되겠고, 나쁘게 말하면 줏대 없는 잡탕이라고 볼 수 있겠다.) 그와 함께 WCF(Windows Communication Foundation), WPF(Windows Presentation Foundation) 등 새로운 기술의 쏟아내는 기염을 토해냈다.

하지만 다른 측면에서 다른 분야의 기술과 그걸 밥벌이 하는 개발자들은 결국 소외될 수 밖에 없다. 그리고 그런 기술들은 기술 발전이 정체 되고, 지원이 끊기거나 지원 규모가 작아지게 된다. 대표적으로 비주얼 베이직(Visual Basic)과 ASP(Active Server Page), 실버라이트(Silverlight) 등이 사망 선고를 받게 된다.

다음은 각각 사망할/사망한 날짜이다.

최근 .NET 개발마저 침체기임이 틀림없다. .NET 플랫폼의 기본은 .NET 프레임워크(.NET Framework)이지만, 이 기본 라이브러리마저 파편화가 되고 있다. 엄밀히 말해 실버라이트, 윈도우 RT(Windows Runtime), .NET 프레임워크는 전혀 다른 메모리 공간에 로드 되는 외형만 비슷한 라이브러리이다. 자바처럼 JRE, JVM을 기초로 모든 코드가 실행되는 것과 다르다. 따라서 실버라이트, 윈도우RT, .NET 프레임워크는 각각 코걸이, 귀걸이 등 물리적으로 전혀 다른 구성 요소로 본다. 이는 마이크로소프트가 1년 앞도 염두하지 않고 급하게 설계하고 개발한 것이며, 아직 까지도 이런 릴리즈가 꾸준히 계속 되고 있다. 이는 뭔가 새로운 버전이 출시할 때마다 하위 호환성을 버리는 악순환이 된다.

2. 네이티브(Native)를 죽여버린 것

지난 수 십여년간 네이티브(Native) 기술의 암흑기였다. 더 이상 Visual C/C++ 6.0 컴파일러는 멀티 코어 CPU에 대응하기 힘들어지고 울며 겨자 먹기로 상위 버전으로 업그레이드를 할 수 밖에 없었다. VC 6.0에서 VC 2008/2010으로 약 십여년의 시간적인 격차가 벌어진 개발 도구와 개발 환경으로 옮겨야 했다.

UPDATE 2013-10-04
참고로 'Visual C/C++'이라 표기한 것은 C 언어 프로그래밍과 C++ 프로그래밍이 모두 가능하다는 의미이다. 아시다시피 Visual C/C++ 의 컴파일러는 다음처럼 Microsoft C/C++ Compiler 라고 표기되어 있기 때문에, 이를 통용하여 Visual C/C++이라고 표현하였다. 'Visual C 라는 것은 없다'고 하시는 분이 계셔서, 이 부분에서 오해의 소지가 없도록 하였으면 한다. 

또한, MSDN 의 일부 문서는 C/C++ 언어를 모두 다루는 문서가 있으니 MSDN의 C/C++ Languages 섹션을 참고하면 된다. 정확한 표기는 'Microsoft C/C++'로 표기하는 것이 정확하지만, Visual Studio IDE와 연관된 부분은 'Visual C/C++'이라 표기하는 것이 더 어울리지 않을까 생각한다.

참고: C 프로그램 컴파일 - http://msdn.microsoft.com/ko-kr/library/bb384838(v=vs.90).aspx

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

simple.c
Microsoft (R) Incremental Linker Version 9.00
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:simple.exe
simple.obj

업그레이드는 컴파일러 뿐만 아니라 개발 도구마저 상위 버전으로 바꾸는 것은 매우 불합리하다. 컴파일러만 바꾸면 되지만 개발 도구까지 상위 버전으로 바꾸어야 하는 비합리적인 개발 환경은 오직 Visual C/C++ 밖에 없을 것이다. (그 외 윈도우 폰, 윈도우 8 앱 개발 환경도 마찬가지다)

그렇게 .NET 플랫폼이 춘추전국시대를 맞이하는 동안 마이크로소프트의 대부분의 SDK의 APIs 들은 .NET 용으로만 제공되었다. Visual C/C++로 만들고 싶어도 만들 수 없는 것이 더 많아지게 되었다. 아니, 만들 수는 있겠지만 ‘만들고 싶지 않다’는 표현이 맞을 것이다.

3. 실험적인 기술을 너무 서둘러 릴리즈 한 것

웹 2.0과 함께 떠오른 ASP.NET 기술 중 AJAX.NET 이 되겠다. 당시 AJAX 대표 라이브러리 중 prototype과 script.aculo.us 등이 대세임에도 불구하고 ASP.NET 서버 랜더링 모델을 고수하는 AJAX.NET을 내놓았다. 결국, 채 2년도 되지 않고 ASP.NET 웹 프레임워크는 jQuery를 공식적으로 지원하고 기존의 AJAX.NET은 어떤 언급도 없이 그렇게 버려졌다.

실버라이트(Silverlight). 이 기술은 애당초 세상에 나오지 말았어야 하는 기술이라 본다. 돌이켜보면 실버라이트 3.0 버전을 실버라이트 1.0 버전으로 나왔어야 경쟁력이라도 있었고 시장에서 기술적인 신뢰를 얻을 수 있었다. 물론 마이크로소프트(Microsoft)는 서둘러 어도비(Adobe)를 따라잡고 싶은 심정은 십분 이해된다. 하지만 이 실버라이트 기술 하나 믿고 시작한 개인과 회사는 시간, 인력, 기타 리소스의 금전적인 규모가 치명적인 타격을 주기에 충분하다. 한 마디로, 실버라이트 쇼크(shock)다.

실버라이트는 아직 까지 윈도우 폰 개발, (그 외 쉐어포인트(SharePoint))에 필요한 기술이다. 아직까지 실버라이트 개발을 하고 있는 분들에겐 미안하지만, 브라우저를 기반으로 하는 실버라이트 응용 프로그램은 거의 모조리 자취를 감췄다.

윈도우 폰 7. 조심스러운 부분이다. 다만 필자의 생각은 이 윈도우 폰 7이 정상적인 스마트 폰인지, 아니면 프로토타입 폰인지 아직도 구분하기 힘들다. 그리고 필자는 후자라고 생각한다. 다음의 인용을 보면 윈도우 폰 7은 Windows CE/Compact 7 커널 기반이지만, 윈도우 폰 8은 Windows NT 커널을 사용한다.

Windows Phone 7 is based on the Windows Embedded CE kernel – the next generation of the Windows Embedded CE platform will be Windows Embedded Compact 7 when released, and the current version is Windows Embedded CE 6.0 R3. Although Windows Phone 7 was built on the Windows Embedded CE kernel at its core, the Windows Phone team has incorporated innovative features and functionality on top of the platform to develop an OS specifically designed to meet the needs of mobile phone manufacturers. [2]

여기서 예상할 수 있는 것은 윈도우 폰 7은 이미 버린 카드이다. 왜냐하면, 윈도우 폰 7은 윈도우 폰 7.8 버전까지 업데이트를 할 수 있는데, 윈도우 폰 7과 8은 서로 전혀 다른 커널을 사용하므로 윈도우 폰 7 사용자는 윈도우 폰 8 운영체제로 업데이트를 할 수 없기 때문이다. 한 가지 재미있는 것은, 업데이트 ‘7.8’ 버전 번호를 보고 유머러스 한건지, 약올리는 건지 분간이 안된다. ㅎ

윈도우 8. 윈도우 8의 앱 개발 기반은 진흙 위에 빌딩을 세우는 것과 같을 정도로 안정적이지 못한 릴리즈이다. 결국 윈도우 8.1에서는 또 윈도우 8과 하위 호환성을 상당 부분 포기해야 했다. 이는 윈도우 폰 8도 마찬가지다. 윈도우 8 앱의 기반은 WinRT(Windows Runtime)인데, 이 WinRT도 완성도 면에서 프로토타입이라고 확신한다. 여기에 대해서는 아래의 필자의 글을 참고하기 바란다.

4. 플랫폼 사용자를 플랫폼에 가두는 것

물리적인 측면에서 .NET 플랫폼의 확장은 돈으로 직결되고 돈으로 귀결된다. 아주 간단한 예로 .NET 플랫폼이 클라우드에서 동작 가능한 Auto Scaling 환경이라고 치자. 서비스에 부하가 가중되면 필요에 따라 이를 분산하기 위해 스케일 아웃(scale out)이 필요할 때가 있는데, 이때 당장 윈도우 라이선스 부과라는 문제부터 해결해야 할 것이다.

마이크로소프트 윈도우즈(Windows) 서버 제품을 사용하는 순간부터 마이크로소프트의 제품을 사용해야 하는 처지에 놓이고 만다. 다음과 같이 말이다.

  • LDAP, Authentication, Certification -> 엑티브 디렉토리,(Active Directory)
    DNS -> 윈도우즈(Windows) DNS 서버
  • 웹 서버 -> IIS(Internet Information Services)
  • 가상화 -> Hyper-V
  • 응용 프로그램 서버 - COM+, WCF(Windows Communication Foundation)
  • 스크립트 언어 -> PowerShell

.NET 플랫폼과 매우 친숙하게 어울릴 수 있는 구성 요소들이다. 물론, 반드시 선택하지 않아도 되는 차선책은 있지만, 그렇게 되면 아름다운 아키텍처를 절대 만들 수 없게 된다. 솔루션 도입에서도 마찬가지로 사내 클라우드(Private Cloud) 구축에 Hyper-V과 결합하는 System Center 제품군은 최선책이고, 차선책은 없다.

위의 경우는 단적인 일부 예일 뿐이다.

.NET 플랫폼 또한 '그들만의 리그(League)' 일 뿐이다. 그들만의 리그 속에서는 환상적인 조합이지만, 조금만 밖에서 지켜보면 하나의 당이 모든 것을 통제하는 공산당 아키텍처와 다를 바가 없다.

5. 개발자를 경청하지 않는 마이크로소프트의 By Designed 철학

마이크로소프트의 모든 최종 답변은 이것으로 통한다. 바로 “BY DESIGNED-의도된 설계”.

섣부른 릴리즈(Release), 구조적인 아키텍처의 결함, 비효율적인 사용자 경험(UX) 등의 고객이나 사용자의 이의에 대해 마지막 (비)공식적인 마이크로소프트의 답변은 "by designed-의도된 설계" 라고 한다. 로드맵(roadmap)에서는 보여주지 않는 By designed 때문에 개발자와 회사들을 곤란한 상황에 빠트린다.

재미있는 일이 벌어졌는데, 마이크로소프트는 일방적으로 Microsoft SQL Server 라이선스 기준을 변경했다. 필자는 이것도 큰 범주에서 "By Designed" 철학과 전혀 무관하지 않다고 본다. 원래 CPU 라이선스(per cpu license)를 코어 라이선스(per core license)로 일방적으로 변경하는 바람에 SQL Server를 사용하는 멀쩡한 회사들을 불법 사용자로 취급 되어 라이선스가 부과되고, 이를 뒤늦게 안 영세(?)한 곳에서는 마른 하늘에 날벼락이 떨어지는 꼴이다. 합법적인 절차라 하더라도 충분히 고객들에게 분노를 살 수 있을 것이다. 이 라이선스 정책에 대해서는 다음의 링크를 참고하기 바란다.

"BY DESIGNED", 오리발 내밀기에 최고의 답변이자 최악의 답변이다. 필자도 이 말을 (불리할 때?) 쓰는 것을 좋아하지만, 반대로 또 가장 싫어 한다.

6. 개발자의 스스로 성장할 자생력을 죽여버린 것

제국 마이크로소프트는 개발자 생태계를 너무나 심각하게 교란 시킨다. 모든 개발 환경은 통제된 환경 하에서만, 그리고 통제된 방법으로 사용되길 원한다.

.NET 플랫폼 환경은 최선책은 있지만 차선책은 없다. 웹 개발만 예를 들어 보아도 자바(Java)는 스트럿츠(Struts), 스프링 MVC(Spring MVC), 플레이 프레임워크(Play Framework) 등 충분히 시장에서 검증된 웹 개발 프레임워크가 있다. 여기에 자바 언어보다 더 심플하고 강력한 언어인 스칼라(Scala), 그루비(Groovy)를 결합하면 폭발적인 생산력을 낼 수 있다.

하지만, ASP.NET은 ASP.NET MVC 이외에 차선책은 없다. 참고로 ASP.NET 웹 폼은 최선도, 차선도 아니다. 자세한 이야기는 다음의 필자의 글을 참고하기 바란다. 더불어 필자가 2009년에 쓴 글임을 감안하고 읽어 주길 바란다.

ASP.NET 웹 폼을 제외한 이유는 ASP.NET 웹 폼은 생산성 향상을 할 수 있는 기능 요소를 보여주기 위한 ASP.NET이 제공하는 기능의 일부이다. 그러므로 ASP.NET 웹 폼이 ASP.NET 전체 아키텍처에 영향을 주는 요소가 절대 아니므로 ASP.NET 웹 폼을 ASP.NET 웹 플랫폼과 동일 선상에서 비교하는 오류를 범하면 안되는 것을 당부한다. 즉 ASP.NET은 반드시 ASP.NET 웹 폼으로 개발하지 않아도 된다. 이 웹 폼은 사용자 정의 컨트롤로 구현된 컨트롤에 불과한 것이다. 자세한 내용은 MSDN 링크를 참고 하기 바란다. [3]

따라서 자바 플랫폼 웹 개발자들을 만나게 되면 다양한 기술과 경험에 대한 이야기를 들을 수 있고 충분히 토론할 만한 주제가 있는데 반면, .NET 웹 개발자들의 주요 관심사는 ASP.NET MVC 코드 조각을 찾아서 해결한 문제나 트러블 슈팅하는 팁 공유가 대부분이다. 그러므로 일반적인 .NET 웹 개발자는 자바 웹 개발자의 열린 사고 방식을 따라갈 수 없다고 결론을 내렸다.

뽀송뽀송한 .NET 플랫폼 테두리에 갇혀 있다면 우물 안의 물이 원래 당연히 썩는다고 생각할 거다. 하지만, 테두리 밖에서 바라보면 우물 안의 물이 원래 썩는 게 아니라 흐리지 않기 때문에 썩는 다는 걸 깨닿게 될 것이다.

7. 모든 것을 심각하게 통합한 것

.NET 개발자는 비주얼 스튜디오(Visual Studio) 없이는 단 한 줄도 코드를 만들어 내지 못한다. 단 한 줄, 과장된 표현이긴 하지만 비주얼 스튜디오(Visual Studio) 이외에 다른 대안이 없다.

통합은 곧 깡패다. 팀 파운데이션 서버(Team Foundation Server)에 체크인(Checkin)된 소스 코드를 받으려면 어이없게도 비주얼 스튜디오가 반드시 필요하다. 팀 탐색기(Team Explorer)가 설치된 비주얼 스튜디오 쉘(Visual Studio Shell)이 없으면 TFS Power Tools 같은 것도 무용지물이다. 왜냐하면 TFS 클라이언트 도구는 팀 탐색기에 포함된 필수 런타임이 반드시 필요하기 때문이다. 그 외 더 자세한 내용은 다음의 필자의 글을 참고 하기 바란다.

만약 마이크로소프트가 망한다면 기술의 기반, 개발 환경, 기타 솔루션 등 모든 것은 그저 한 줌의 재가 될 것이다. 소스 코드를 공개한다고 해도 그 일부는 더 장래가 밝은 1인자에게 기부될 것이다.

현재까지 100년 이상 된 IT 기업은 전세계에도 없다.  "영원히 위대한 기업, 영원히 호황을 누리는 산업은 없다. 다만 영원히 뛰어난 전략적 움직임만 존재할 뿐이다." [4] 마이크로소프트가 100주년이 된다면 IT 기업이 아닌 애플에 부품을 대주는 ‘제조업’ 회사일 수도, 플레이 스테이션을 유통 시키는 ‘무역업’ 회사일 수도, 그 아무도 모른다.

UPDATE 2013-10-04
IT 기업 중 100년 이상이 된 기업은 IBM으로 2011년도에 100주년이 되는 해였다. 댓글로 정보를 제공해 주셔서 감사합니다.

언젠가 (차선책이 없는) 통합된 제품을 쓰는 이들은 엄청난 대수술을 받아야 할 지 모른다. 마치 흔들리는 이빨만 뽑을 수 없고 잇몸 전체를 들어내야 할 수도...


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. 지나가던사람 2014.08.19 15:36 Address Modify/Delete Reply

    글 잘 읽었습니다.
    닷넷 개발만 10년넘게 하다가 최근 1년정도 php, java, python 등등 하고 있는 사람인데,
    저는 잘 모르겠습니다. 방금 언급한 언어들이 아직은 닷넷보다 미숙한 탓도 크겠지만,
    vs에 비해 개발 툴(이클립스, 인텔리제이)에서 느껴지는 답답함과 생산성, 유지보수의 불편함
    개발 프레임워크의 복잡성,, 이런 것들이 너무 크게 자리잡고 오히려 이런 것들이 쌓이니
    개발이 재미가 없어지고 있습니다.
    너무 닷넷에(편한 개발환경에) 익숙해져 말씀하신대로 변화에 적응력이 떨어진 거 같은 생각도 듭니다.
    닷넷이 망한(?) 원인은 여러 설명을 해주셨지만 제가 보기엔 기술의 흐름(ria, 오픈소스)에 대한 대응이 실패한 것이 크고 플랫폼 독립성이라는 주제에 대해 간과한 점, MS 제품군에 종속성을 유지하려 한점,
    라이센스에서의 독재성(?) 뭐 이런것들이 주요 원인이라 생각이 드네요.
    전 그래도 닷넷을 사랑합니다.
    10년넘게 개발해 오면서 닷넷이 아닌 다른 걸 선택했다면 쓸데없는 스트레스를 너무 많이 받았을 거 같네요..ㅎ 그만큼 닷넷이라는 기술에 있어서는 자바나 다른 언어들과 비교해도 뛰어나다고 생각합니다.

  3. 일단 공감, 그리고. 2014.08.24 22:32 Address Modify/Delete Reply

    MS는 MS DOS / Windows로 굳어진 OS 개발회사라는 틀을 벗어나는 것이 가장 시급하지 않은가라고 생각합니다. 90년 초반 MS-DOS를 사용하다 DR-DOS로 옮겨가던 사람들이 오피스 때문에 다시 Window 3.1를 다시 돌아보던 기억이 납니다. 그 때도 많은 사람들이 MS 욕은 엄첨 했었지만, 그건 특정 업체에만 국한되었던 것은 아니었죠. MS에서 느끼는 답답함은 그 시절과 크게 다르지 않은 것 같습니다. 오히려 닷넷때문에 이미지가 호전되었었다고나 할까요. :-) IBM, Oracle... 모두 다 사활을 건 생존경쟁에 서 있는 "업자"들일 뿐. 회사는 솔루션에 적합한 개발 플랫폼을 고르면 그만, 개발자는 회사에서 선택한 플랫폼이 머든 제발 리펙토링이라도 제대로 했으면 하는 쿨럭 -ㅁ- ㅋ

  4. 흠.. 요즘에는.. 2014.09.29 00:23 Address Modify/Delete Reply

    아주 새로운 데에서 닷넷이 풀리고 있습니다.
    혹시라도 닷넷을 망해가는 언어로 생각해서 더이상 배우는 사람이 나오지 않을까 몇 자 적어봅니다.

    마이크로소프트 닷넷 프레임워크를 멀티 플랫폼에서 돌릴 수 있도록 변환하는 작업이 오픈 진행되고 있습니다.

    Xamarin Studio 가 대표적인데, 닷넷으로 구현된 프로그램이 안드로이드, IOS, 윈도우 모두 돌아갈 수 있도록 합니다. 그 언어는 C#이고요..

    그 Xamarin studio 의 기본 툴이 MonoDevelop인데, 이건 요즘 각광받는 유니티에서 사용되고 있습니다.
    닷넷 관련 소스 및 커뮤니티도 상당히 크고요.

    MS가 전면에 나서서 하지는 못하지만 (회사 특성상) 멕시코 개발자가 시작한 MonoDevelop은 큰 반향을 일으키고 있습니다.

  5. feel 2014.11.14 11:19 Address Modify/Delete Reply

    어제자 발표입니다.
    우리의 목소리를 MS가 들은 걸까요? 이제 정신차리려고 하나 봅니다.

    http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/

  6. 병팔이 2015.04.14 00:11 Address Modify/Delete Reply

    내용 중 7번에 공감 100% 입니다. SDK만 가지고 IDE 없이 빌드를 해보고자 했으나 너무나 큰일이더군요. 스케줄 빌드 같은 것은 대체 어떻게 하란 말인지? 그리고 SDK 설치했는데 나오는 경로명에 Visual Studio 뭐 이런 게 왜 섞여 나와야 하는건지. .NET 설치하는데 SQL Server 공짜로 깔아줘서 고맙다고 박수칠 줄 알고 넣어준건지. 하여간 너무 바보같고 monolithic한 덩어리를 만들어버렸습니다. 더 이상 기술향상은 안해도 좋으니 하루라도 빨리 깨끗이 나눠만 줬으면 좋겠습니다.

  7. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  8. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  9. hewon 2015.06.21 16:13 Address Modify/Delete Reply

    2015년 6월에 이 컬럼을 보는데 정말 정확하게 찍어보신것 같습니다.
    특히 윈도우폰이나 RT의 미래에 대해서는요.
    닷넷 개발하는 개발자 입장에서는 자기가 개발했던 제품이 언제 단종되나 두근두근하면서 개발하고 있습니다.

  10. MonoDevelop 2015.08.08 19:34 Address Modify/Delete Reply

    MonoDevelop 한글판이 익숙치 않아 영어로 놓고 있었는데 언제부터인가 언어 설정을 english로 해도 계속 한글이 튀어나와서 아주 괴롭습니다. 이거 어떻게 방법 없을까요?

    • 땡초 2015.08.09 00:17 Address Modify/Delete

      맥 버전을 사용하신게 맞나요?
      확인 차 여쭤봅니다.

  11. Yuhan 2016.04.05 11:22 Address Modify/Delete Reply

    옛날 게시물이니 그려려니하다 2015년도 글도 보여서 얕은 지식과 의견 몇자 적어봅니다.

    상당히 MS를 까기위한 편견만 가지고 접근하시는듯 한 부분이 많이 보입니다만.

    언어적인 측면에서는 2015년에는 이미 C#이 Java를 뛰어넘었다고 볼 수 있습니다.

    LINQ, Lambda Expression 등 현재는 Java가 언어적인 측면에서 오히려 .Net을 따라가고 있는 인상을 주고 있죠.

    사실 저도 원래 .Net 개발자이지만, 최근들어 Java로 프로젝트를 계속 진행하고 있습니다.

    Java가 좋아서도 아니고, 그저 국내 시장에 자바를 선호하는 경향이 강할 뿐 사실

    자바 4~5년 / 닷넷 6년 개발 해본 입장에서 어마어마하게 많은 중괄호와

    인터페이스 오히려 간결하지 못한 코드, 뭐 할려고만 하면 추가해야되는 플러그인이나

    아주 사소한것까지 추가해야되는 다양한 프레임워크로 스트레스 많이 받습니다.

    (StringUtils라는 클래스가 몇개의 라이브러리에 중복되어 섞여있습니까.)

    괜히 Groovy가 나왔겠습니까.

    그렇다면 Java를 버리고 Groovy를 배우는게 맞을까요? 이러면 자바 개발자가 아닌게 되는건가요?

    언어적 완성도 측면에서는 Java는 더이상 C#의 상대가 되지 않습니다. 2013년에도 말이죠.

    C#을 쓰지 않아도 배워야 하는 이유는 이것 하나만으로도 충분합니다.

    4번 제외하고는 사실상 진짜 닷넷에 대해 편파적으로 바라보는 자바개발자가 쓴 글 처럼 느껴지는데.

    이거랑 똑같이 자바도 단점 끄집어 내면 한도 끝도 없습니다.

    • 땡초 POWERUMC 2016.04.05 13:44 신고 Address Modify/Delete

      맞는 말씀입니다.
      굉장히 편파적으로 바라보면서 쓴 글입니다.

      하지만 자바 진영은 오픈 커뮤니티로 합의에 의해 주도되지만,
      MS는 상업적 기업이니 같은 시각으로만 바라보기 힘들기도 합니다.

      좋은 의견 주셔서 고맙습니다.

  12. 설마 2016.06.17 01:21 Address Modify/Delete Reply

    MS가 이 글을 본걸까요.. 3년이 지난 지금은 이 글에서 꼬집은 문제점이 대부분 해결되었다는 점이 신기하네요 ㄷㄷ

  13. John 2016.07.08 13:46 Address Modify/Delete Reply

    많은부부에서 공감을 얻고갑니다 자바 개발로 시작해서 현재 닷넷 개발을 하고있는데 위에 말씀하신분이 적으신것 처럼 언어적 편의성 은 C# 이 훨씬 우월하긴 합니다 , 그 편의성때문에 가끔 가독성이 떨어질때에도 있는데 작성하는 입장에서는 엄청 좋기도하고,, 그리고 닷넷이 정확히는 CORE 닷넷출시하면서 위에 말씀하시는 모든 문제들을 대부분 해결하거나 제안을 제시했습니다 마소가 좋은녀석들이라서 그런것은 아니고 , 시장경쟁력에서 워낙 많이 밀리고 또 대세가 그러하니 변경한것 같습니다 좋은 글 잘읽고 갑니다

  14. 요원009 2016.10.27 15:31 신고 Address Modify/Delete Reply

    엔지니어 출신 이사들 내쫓음 -> MBA 출신들 데려옴 -> 말아먹은 게 한 두개가 아님.

    말아먹은 것들이 저 위에 다 나오네요. 정신차리고 엔지니어 출신들 다시 모셔오니 정상 궤도로 올라오는 느낌입니다. 요즘 C# 너무 강력해요 ㅎㅎㅎ

  15. 나그네 2017.02.05 21:45 Address Modify/Delete Reply

    요즘 Java가 마소 보다 악질인 오라클 놈들 때문에 정나미가 떨어져서 C#으로 왔습니다. 나중에 ClojureCLR 프로젝트에나 참여하고 싶네요. 요즘 마소가 제공하는 자료도 너무나 많고(MSDN, Visual Academy 등) 리눅스 지원에 오픈소스 프로젝트도 많이 해서 진짜 많이 변한 것 같네요. 그놈의 윈도우의 괴상한 구조(특히 레지스트리)는 변함이 없지만 윈10이 마지막이라고 하니 다음 OS는 제발 개발자나 서버 관리자들에게도 일반 유저에게도 편리한 OS로 나오길...

  16. 얌전맨 2017.06.20 09:53 Address Modify/Delete Reply

    MS가 정말로 이 글을 읽고 반성한것처럼 저 시기 이후로 많이 달라졌습니다. 글 쓰신분의 예리한 통찰력에 감탄하구요. 자마린이 통합된 VS2017 출시로 다시 한번 C#에 희망을 걸어봅니다.

  17. 지나가다 2017.07.15 18:56 Address Modify/Delete Reply

    잘 읽었습니다.
    그런데, 외국을 보면 Java 가 우리나라 처럼 이렇게 융성하지도,
    .Net 이 한국처럼 저조하지도 않아요.

    이유는 딱 하나입니다.
    자기 돈 아닌 돈으로 프로젝트 하는 공무원들과
    국가 공인 프레임웍을 Java 로 만들어 놓은 사람들.

    아마 본인이 회사 사장인데,
    본인 회사 프로젝트를 전자정부 프레임웍을 써서 프로젝트 하라고 하면 하겠습니까?

    그리고, Java 진영에서 떠들던 MVC...
    숙련자들이 모이고, 원활한 커뮤니케이션이 되야
    중급이하의 개발자들이 모여서 대충 개발할 수 있는
    PHP, .Net 언어들만큼의 퍼포먼스가 나온다고 한다면...

    이건 공무원이 자기 돈 아닌 자금으로 진행하고,
    업자들은 그 열매를 받아 먹는 구조에서만 가능한겁니다.

  18. ㅇㅇ 2019.03.05 15:27 Address Modify/Delete Reply

    비교하려면 객관적인 도표자료는 필수인데 내용이 너무 주관적이고, 정보 신뢰도 그닥..
    실버라이트가 2021년에 사망이라.. 2010년에 이미 개발중단입니다. 2021년에는 웹브라우저에서 지원이 중단되는겁니다.
    사람들이 여기서 논쟁을 많이 하는 이유는 글을 이따구로 써놓으셔서 인거 같습니다.
    그럼 20000

    • 땡초 POWERUMC 2019.03.05 16:16 신고 Address Modify/Delete

      객관적인 자료는 본문 중에도 링크에 있습니다.
      https://support.microsoft.com/ko-kr/lifecycle/search/?ln=en-us&c2=12905
      2011년 12월에 출시한 SL5 가 있는데 2010년에 개발 중단이라뇨.
      그리고 10년이면 강산도 변한다고 하는데, 이미 6년이나 지난 글에 너무 큰 의미를 두지 않으셨으면 합니다.

  19. 그럼 글을 내리거나 수정하시는게 낫지 않나요? 2019.03.27 13:32 Address Modify/Delete Reply

    그럼 글을 내리거나 수정하시는게 낫지 않나요?

    분쟁 유도글 같아 보여서 올려봅니다.

    • 해구름 2019.04.08 12:40 신고 Address Modify/Delete

      2013년에 작성된 글이니 감안하고 보면 될 것 같습니다. 저도 2013년에는 마소에 대해 감정이 좋지 않았습니다. 폐쇄적이고 멋대로인데다가 제대로 되는 것도 별로 없었거든요. 샤티아 나델라가 지금의 마이크로소프트로 만들지 못했다면, 이 글은 좀더 공감 받았을지도 모르죠.

  20. 천하귀남 2019.04.18 10:19 Address Modify/Delete Reply

    최근 닷넷을 시작하면서 과거와 현재의 차이가 많아 뭐가 뭔지를 이해하기 힘들었는데
    당대의 상황을 이해 가능하게 해주는 글이라 많은 도움 받았습니다.

    문제를 언급하는것도 훌륭한 자료입니다. 불편하다고 지운다면 자료가 아니지요.

  21. 공부중입니다 2019.04.24 19:53 Address Modify/Delete Reply

    지금은 닷넷 전망을 어떻게 생각하시나요??

필자는 일전에 이와 관련되어 상당한 분량의 포스팅을 올린 적이 있다. 총 5회의 아티클 중 마지막 회를 모두 작성하지는 못했지만, 지금 이 내용이 그 마지막 회의 내용과 어느 정도의 내용과 유사하다고 보면 된다.


그 중, 4회 아티클 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]5’의 내용은 본 아티클의 내용에서 매우 중요한 기초 내용이 된다. 이 글을 읽고 있는 독자 중 잘 이해가 되지 않는다면 필자가 이전에 작성한 포스팅을 반드시 읽어보기를 바란다.

그리고 위의 필자가 작성한 링크의 아티클은 5년전에 작성된 글임을 인지해 주길 바란다. 그 때는 필자가 지금보다도 더 실력이 형편 없었을 뿐더러 현재 추구하는 웹 개발의 트랜드와 상이한 면이 있을 수도 있을 것이다. .NET Framework 버전과 개발툴의 버전도 지금 사용하는 버전과는 한참 예전 버전이었다. 하지만 5년이 지난 글임에도 기초적인 내용은 모두 탄탄하게 짚고 넘어가므로 한번씩 보는 것도 나쁘지 않다.

ASP.NET이 지원하는 분산 세션 상태(Session State)

일반적으로 1대 1의 물리적인 관계는 분명 분산환경이긴 하지만 분산 환경이라고 말하지 않는다. 어떤 물리적인 환경에 배치하든, 통계학의 분산에 대한 기대값이나 편차의 해는 변하지 않기 때문이다.

분산 환경에서 더 나은 성능을 내기 위한 알고리즘과 휘발성인 메모리 안에서 데이터가 유실되지 않도록 원자성(Atomicity)을 유지할 수 있는 방법을 제공해야 한다. 또 웹 서버의 세션이라는 특징은 매우 빈번하게 엑세스 되고, 업데이트와 삭제 작업도 매우 많이 발생한다.

하지만, 안타깝게도 memcached[1]는 ‘get’ 명령의 원자성(Atomicity)를 보장하지 않는다고 한다.

A series of commands is not atomic. If you issue a 'get' against an item, operate on the data, then wish to 'set' it back into memcached, you are not guaranteed to be the only process working on that value. In parallel, you could end up overwriting a value set by something else.


하지만 괜찮다. 웹 서버의 세션은 동시다발적인 병렬 작업으로 요청이 들어올 수 없는 구조이다. 웹 서버로 사용자의 요청이 들어올 때, 사용자의 웹 브라우저에 가진 쿠키 값이 신원보증을 하는 값, 또는 해시된 세션의 키 값이다. 그러므로 한 세션에 대해 동시에 여러 클라이언트(사용자 웹 브라우저)의 요청은 있을 수 없는 일이다.

하지만 불가능한 것도 아니다. 예전에는 자바스크립트가 허용되는 게시판이나 이와 유사한 환경에서 악성 스크립트를 심어 놓으면, 그 글을 보는 누군가는 브라우저의 쿠키 값을 취득하여 해커에게 보내고, 해커는 세션이 만료되는 20분(일반적인 세션 만료 시간) 전에 취득한 세션 값으로 재 요청을 하게 되면 다시 세션이 연장되고, 세션이 로그인된 상태인 경우 해커도 로그인된 상태로 입장하는 것이 가능하다

때문에 완전히 같은 해시된 세션의 키 값으로 여러 클라이언트(사용자의 웹 브라우저)의 요청이 온다는 것은 사용자의 세션 값이 털려서, 누군가 악용하고 있다고 보는 것이 맞다.

그러므로 아주 정상적이고 일반적인 환경에서 원자성을 제공하지 않는 ‘get’ 명령은 전혀 문제가 되지 않으며, 오히려 원자성을 보장할 수 없는 문제로 더 좋은 Read 성능을 낼 수 있기 때문에, memcached 가 세션 서버로 사용하기에 redis[2] 보다 더 좋을 수 있다.

ASP.NET이 제공하는 세션 관리 요약

아무런 설정이 없다면 In-Proc, 즉 로컬 머신의 메모리를 사용하게 된다. 만약 불행히도, Win32 DLL을 참조하는 웹 응용 프로그램이라면 웹 서버의 메모리의 크기 따윈 무시하고 최대 2GB 밖에 사용할 수 없게 된다.

이를 극복하는 방법으로 윈도우 서비스로 백그라운드로 실행되는 ASP.NET Session State Service 서비스를 사용하면 좋다. 여러 웹 응용 프로그램이 하나의 Session State Service에 연결되더라도 웹 응용 프로그램마다 고유의 Identity Key(Guid)가 할당되고, 이를 Primary Key로 구분하게 된다. 이 NT Services가 다운되거나 재시작하지 않는 이상 웹 서버의 세션은 항상 유지할 수 있다.

긴급한 패치로 웹 응용 프로그램을 업데이트 해야 하는 경우, IIS가 재시작 되는 경우가 발생할 수 있는데 이 때 Worker Process에 의해 구동되는 In-Proc 세션 정보는 모두 초기화된다. 웹사이트에서 뭔가를 구매하려는 사용자가 있었다면 큰 사고로 이어질 수 있지만, Session State Service에 세션 정보가 저장이 되므로 IIS 재시작 후에도 웹 응용 프로그램은 세션 정보를 모두 안전하게 유지할 수 있다.

보통 웹 서버와 Session State Service간에 통신을 하기 위해 방화벽의 특정 포트를 개방해야 하고, 내부적으로 서로 간에 소켓 통신에 사용되는 전용 프로토콜이 존재하므로 Session State Service를 확장하기란 쉽지 않을 것이다.

이런 경우, ASP.NET에서 MS SQL Server를 이용하여 세션 정보를 저장하는 방법을 제공해 준다. 세션 정보에 추가하고 싶은 정보나 DB상에 기록되어질 특정 필드를 추가하여 사용할 수 있고, Oracle 또는 MySQL을 사용하여 세션 상태를 저장할 수도 있다.

위의 링크 중 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]13’에 예제로 구현된 Oracle Session Store Provider 예제가 있으니 참고하길 바란다.

memcached를 이용하는 세션 저장소

memcached를 세션 저장소로 이용하는 것은 ASP.NET Session State Services의 역할과 구현만 다를 뿐이지 매우 유사하다. memcached도 메모리를 저장소로 이용하여 빠르게 캐시하고 요청에 빠르게 응답할 수 있는 간결한 구조로 구현된 오픈소스이다.

특히 memcached를 이용할 경우 ASP.NET Session State Services로 불가능한 클러스트링이 가능하기 때문에 수평적으로 세션 서버를 확장할 수 있다. 한 대의 세션 서버만 있는 경우보다 로드벨런싱의 자유도가 더 높고, 세션 서버의 장애에도 대처가 가능하다. 또 하나의 장점이라면 저가형 장비를 병렬로 구성이 가능하기 때문에 세션 서버를 구성하기 위한 금전적이거나 물리적인 많은 제약이 사라지게 된다.

memcached와 redis, 두 가지 오픈소스를 고려하고 있었는데, 세션 서버에 memcached가 더 적합하다고 생각하여 memcached만 다룬다. memcached의 소스 코드가 더 가볍고 취향이나 요구사항에 따라 코드를 변형하기에 더 적합하지 않을까 생각한다. 그리고 자칫 복잡해질 수 있는 구조적인 아키텍처를 좀 더 간결한 memcached로 표현하는 것이 글을 보는 입장이나 쓰는 입장에서 편하다고 믿는다.

memcached는 C언어로 구현이 되어있고, GNU C 표준 라이브러리를 사용하므로 여러 운영체제에서 사용이 가능하다. (ASP.NET Session State Services는 윈도우 환경에서만 사용이 가능하다) 물론 필자는 맥킨토시, 리눅스, 윈도우에서 memcached를 컴파일, 구동이 잘 됨을 확인하였다.

간단하게 사용자의 세션 정보를 저장할 클래스를 하나 간단하게 만들었다. 외부에서는 오직 참조만 하여 사용할 수 있도록 internal 생성 메서드를 하나 가지고 있다.


다음은 ASP.NET MVC 프로젝트로 만든 간단한 예제이다.

web.config
1
2
3
4
5
6
<sessionState mode="Custom" customProvider="MemcachedSessionStateStore">
    <providers>
        <add name="MemcachedSessionStateStore"
             type="Umc.Core.Web.SessionState.Memcached.MemcachedSessionStateStore, Web.SessionState.Memcached, Version=1.0.0.0, PublicKeyToken=eed8f2bc3bfc4c7a, Culture=neutral"/>
    </providers>
</sessionState>

  

HomeController.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class HomeController : Controller   
{
   private static readonly string KEY_OF_USER_SESSION = "__USER_SESSION_KEY__";
   public UserIdentity SessionStore
    {
        get { return (Session[KEY_OF_USER_SESSION] as UserIdentity) ?? UserIdentity.Empty; }
        set { Session[KEY_OF_USER_SESSION] = value; }
    }
 
 
    public ActionResult Index()
    {
        Session[KEY_OF_USER_SESSION] = UserIdentity.New("POWERUMC"
                                                        , "Junil, Um"
                                                        , "powerumc at gmail.com");
 
 
         /*
          // 맴버쉽 사용자 인증 설정 생략...
        var ticket = new FormsAuthenticationTicket(...);
        var user = new GenericPrincipal(new FormsIdentity(ticket), ... )
         * */
 
 
        return View();
    }
}

 

위와 같이 클라이언트의 세션 키를 이용하여 memcached의 서버에 세션 키를 이용하여 세션 값을 저장한다.

telnet 'get' 명령 결과
MPOWERUMC:~ powerumc$ telnet 192.168.0.23 11211
Trying 192.168.0.23...
Connected to 192.168.0.23.
Escape character is '^]'.
get laaymm13uyu03bofhdydi4iq
VALUE laaymm13uyu03bofhdydi4iq 0 477
AAEAAAD/////AQAAAAAAAAAMAgAAAF1XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZCwgVmVyc2lvbj0xLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWVlZDhmMmJjM2JmYzRjN2EFAQAAAEpVbWMuQ29yZS5XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZC5NZW1jYWNoZWRTZXNzaW9uU3RhdGVTdG9yZStTZXNzaW9uRGF0YQQAAAATPElkPmtfX0JhY2tpbmdGaWVsZBg8TG9ja0FnZT5rX19CYWNraW5nRmllbGQYPEV4ZmlyZXM+a19fQmFja2luZ0ZpZWxkFzxMb2NrSWQ+a19fQmFja2luZ0ZpZWxkAQAAAgwNAgAAAAYDAAAAGGxhYXltbTEzdXl1MDNib2ZoZHlkaTRpcQC8oGUBAAAAAPAWAzAi0IgJAwAAAAs=
END

 

 

ASP.NET의 세션이 실제로 저장이 되었는지 확인해보자. telnet을 통해 memcached 포로토콜의 명령을 입력하여 확인하면 된다.

현재 브라우저에서 연 세션 값은 쿠기에 저장이 되어 있다. 쿠키에 저장된 세션의 키 값은 ‘laaymm13uyu03bofhdydi4iq’ 이다.


telnet에 접속하여 memcached에 저장된 세션 키의 값을 조회된다.

memcached 세션 저장소로써 활용

memcached 오픈 소스 솔루션을 이용하여 메모리 캐시를 이용하여 ASP.NET 세션 상태를 저장할 수 있도록 구성해 보았다. 이제 얼마나 좋은 성능을 낼 수 있는지 측정이 필요한데 본 아티클에서는 memcached를 세션 서버로 활용할 때에 대한 성능의 문제는 다음에 기회가 되면 더 심도있게 다루어 보도록 하겠다.

그리고 ASP.NET 뿐만 아니라, JSP 또는 Servlet, 그 외에 여러 웹 개발 프레임워크에서 쉽게 사용할 수 있다. memcached는 C#, Java, Python 등 여러가지 언어로 memcached서버에 연결할 수 있는 클라이언트 라이브러리를 어렵지 않게 찾을 수 있다.

이번 아티클에서는 MemcachedSessionStoreProvider 소스 코드를 제공하지 않았다. 물론, 필자의 위 코드를 실행하기 위해 MemcachedSessionStoreProvider 소스 코드가 있어야 한다. 이 코드는 다음 아티클에서 조금씩 작성해 나갈 예정이다.

memcached 에 대한 자세한 내용은 아래 링크의 구글 코드에 들어가면 컴파일 및 실행 방법과 유지관리 방법에 대한 위키가 있다.

memcached wiki, https://code.google.com/p/memcached/wiki/NewStart



[1]: C언어로 구현된 고성능 분산 메모리 객체를 캐시하는 서버. Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

[2]: 키/값을 저장할 수 있는 분산 서버로 데이터의 구조체 뿐만 아니라 문자열, lists, 빠른 검색을 위한 hashes 등을 지원. Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain stringshasheslistssets and sorted sets.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

처음 Visual Studio 2010 릴리즈 되었을 때는 HTML5 기능이 추가가 되지 않았습니다. 그래서 XML Schema 를 이용하는 방법으로 HTML 텍스트 에디터에서 HTML5 구문을 사용하기도 하였습니다. 하지만 이번 Visual Studio 2010 SP1에는 정식으로 HTML5 인텔리센스와 유효성을 검사할 수 있는 기능이 추가가 되었습니다.

이 기능을 활성화하기 위해서 도구->옵션의 텍스트 에디터->HTML->유효성에서 HTML5 유효성 검사를 지정할 수 있습니다.

 

HTML5가 지원하는 여러 구문을 인텔리센스에서 자연스럽게 보여줍니다.

 

더불어 CSS3 를 완벽하게 지원하지는 않지만, 일부분 CSS3를 지원해 줍니다. CSS3 기능은 앞으로 그 기능을 보강할 수 있는 확장 기능으로 Visual Studio Gallery 에서 배포가 되길 기대해봅니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

배포 가능한 종속성(Deployable Dependencies) 는 이번 Visual Studio 2010 SP1 에서 새롭게 추가된 기능입니다. 웹 응용 프로그램을 서버로 배포하기 위해서는 필수 구성 요소들이 설치가 되어 있어야 하는데, 배포 가능한 종속성 기능을 이용하면 웹 응용 프로그램이 동작에 필요한 일부 컴포넌트를 바로 배포할 수 있도록 도와줍니다.

웹 응용 프로그램에서 마우스 오른쪽 버튼을 클릭하여 컨텍스트 메뉴를 활성화하면 다음과 같은 메뉴 항목이 추가가 되어 있습니다.

 

메뉴 항목을 선택하면 아래와 같은 창이 나타납니다. 이 창에서는 ASP.NET MVC3 에서 사용하는 Razor 컴포넌트와 SQL Server Compact 를 선택할 수 있습니다.

 

위와 같이 배포 시 포함할 종속된 어셈블리/컴포넌트를 선택하여 확인 버튼을 클릭하면, 다음과 같이 웹 응용 프로그램 프로젝트에 _bin_deployableAssemblies 폴더가 생성이 되고, 이 하위에 관련된 어셈블리가 추가가 됩니다.

 

웹 응용 프로그램을 게시를 하게 되면, 위의 _bin_deployableAssemblies 폴더의 어셈블리는 웹 응용 프로그램의 bin 폴더로 배포가 됩니다.

 

물론, 웹 배포 패키지로 .ZIP 파일로 생성을 하여도 종속성을 추가한 어셈블리는 BIN 폴더에 추가가 되며, 이 패키지를 이용하여 배포할 서버에 컴포넌트의 설치 없이 바로 배포할 수 있습니다.

 

다만 현재는 여러 가지 배포 어셈블리/컴포넌트를 지원하지 않고 아래의 3개지의 컴포넌트만 배포를 지원해 줍니다.

  • ASP.NET Web Pages / Razor
  • SQL Server Compact 4.0
  • ASP.NET MVC 3
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Razor 지원

ASP.NET MVC3 가 릴리즈 되면서 이에 발맞추어 Visual Studio 2010 SP1이 개발 도구에서 ASP.NET MVC3를 지원합니다. 특히 ASP.NET MVC3 Beta 버전에서는 지원하지 않았던, ASP.NET MVC3의 중요한 기능 중의 하나인 Razor View Engine인데, Razor View Engine의 Syntax 및 Intellisence 도 함께 지원합니다.

새로운 프로젝트를 만들 때 ASP.NET MVC3 프로젝트 템플릿에서 Razor 뷰를 선택하면 Razor View Engine을 사용할 수 있습니다.

 

 

더불어 일반 ASP.NET MVC3의 ASPX 페이지 또한 새로운 뷰를 추가할 때 Razor 뷰로 추가하면, 기존 ASP.NET MVC3의 Razor Engine을 그대로 사용할 수 있습니다.

 

Web Platform Installer 통합

Visual Studio 2010과 Web Platform Installer(WPI) 가 통합이 되었습니다. Visual Studio 2010에서 WPI를 바로 실행할 수 있는 툴바가 추가 되었습니다.

 

WPI를 통해 아래의 최신 제품을 다운로드 받을 수 있습니다.

  • SQL Server Compact 4.0
  • IIS 7.5 express
  • ASP.NET MVC3
  • WebMatrix
  • 기타…

 

  

Posted by 땡초 POWERUMC

댓글을 달아 주세요

기본적으로 웹 응용 프로그램을 개발할 경우 로컬에서 동작하는 ASP.NET Development Server 가 활성화가 됩니다.

그림 1 로컬 ASP.NET Development Server 가 동작하는 화면

웹을 개발할 때 Visual Studio가 제공하는 로컬에서 동작하는 ASP.NET Development Server 로 충분히 어려움 없이 개발을 할 수 있으나 웹 개발의 여러 가지 상황을 고려해 보면 기능이 충분하지는 않았습니다.

예를 들면, 기존의 로컬에서 동작하는 ASP.NET Development Server는 특정 웹 페이지나 XML 웹 서비스, WCF 서비스가 SSL(Secure Sockets Layer)로 동작한다거나 WCF의 NET.TCP, NET.PIPE 등의 바인딩을 사용할 수 없었습니다.

이런 여러 가지 기능적으로 IIS Express 를 사용할 경우 얻을 수 있는 이점이 많고, 기존 웹 응용 프로그램을 IIS Express에서 동작하도록 변경하기 위한 절차 또한 매우 간단합니다.

IIS Express가 설치되어 있다면, 웹 응용 프로그램에서 마우스 오른쪽 버튼을 클릭하여 IIS Express 사용을 선택하면 즉시 IIS Express 에서 웹 응용 프로그램이 동작하도록 할 수 있습니다.

 

그리고 다음의 확인 메시지에서 '예'를 클릭하면 바로 IIS Express로 웹 응용 프로그램을 개발할 수 있습니다.

 

IIS Express는 윈도우의 알림 영역에서 찾을 수 있으며 이 아이콘을 이용하여 여러 개의 호스팅 되고 있는 웹 응용 프로그램을 관리할 수 있습니다.

 

IIS Express를 사용하여 Visual Studio 2010에서 여러 가지 설정을 즉시 변경해 줄 수 있습니다.

그림 2 IIS Express 설치시 웹 응용 프로그램 속성

그림 3 기존 ASP.NET Development Server 속성

 

 

 

IIS 7과 IIS Express 버전의 비교표:

Area

IIS 7

IIS Express

Shipping mechanism

Ships with the OS.

Ships out-of-band. It is automatically included with WebMatrix but can also be installed separately.

Supported Windows editions

Limited number of Windows Vista and Windows 7 editions

Most editions of Windows Server 2003, 2008 and 2008 R2

All editions of Windows XP, Vista, Windows 7

All editions of Windows Server 2008 and 2008 R2

Supported .NET Framework versions

v2.0 SP1 and above

v2.0 SP1 and above (.NET 4.0 is required).

Supported programming languages

Classic ASP, ASP.NET, and PHP

Classic ASP, ASP.NET, and PHP

Process model

Windows Process Activation Service (WAS) automatically manages configured sites.

User launches and terminates sites.

Hosted WebCore (aka Hostable Web Core) support

Yes

Yes. IIS Express is implemented as a layer over HWC.

Supported protocols

HTTP, FTP, WebDAV, HTTPS, and WCF (including over TCP, Named Pipes, and MSMQ)

HTTP, HTTPS, and WCF over HTTP

Non-admin support

WAS must run with administrator user rights.

A standard user is allowed to complete most tasks.

Multi-developer support

None

Yes. Configuration files, settings, and Web content are maintained on a per-user basis.

Visual Studio support

Yes

VS 2010 SP1 Beta allows IIS Express to be used instead of Cassini. VS 2008 can also be manually configured to use IIS Express.

Runtime extensions

See http://www.iis.net/download/All for a complete list.

URL Rewrite and FastCGI. These extensions are built into IIS Express.

Management tools

IIS Manager, appcmd.exe

Appcmd.exe. Common IIS Express management tasks are also built into WebMatrix and Visual Studio 2010 SP1 Beta.

System tray support

None

Yes

Includes built-in IIS 7x modules for authentication, authorization, compression, etc.

Yes

Yes

 

참고

IIS Express Overview

http://learn.iis.net/page.aspx/868/iis-express-overview/

 

IIS Express를 설치하기 위해 WPI(Web Platform Installer) 다운로드 페이지

http://www.microsoft.com/web/gallery/install.aspx?appid=iisexpress

 

그림 4 Web Platform Installer 초기 설치 화면

 

그림 5 기본적인 구성 요소인 IIS Express 설치 화면

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

실버라이트 4 이전의 버전에서 Visual Studio에서 성능 프로파일을 지원하지 않은 것은 아닙니다. 다만, 개발 도구에서 지원하지 않았을 뿐이고, Command Line을 이용하여 브라우저를 Attached 하여 성능 프로파일을 할 수 있었습니다.

물론, 예전에도 실버라이트에서 성능 프로파일링을 위해 커맨드 라인으로 프로파일링을 할 수 있었습니다. 아래와 같은 순서대로 커맨드를 실행하면 되었습니다.

  1. VSPerfClrEnv /sampleon
  2. "c:\Program Files (x86)\Internet Explorer\iexplore.exe" C:\Breakout\Breakout\Bin\Release\TestPage.html
  3. VSPerfCmd /start:sample /output:MyFile /attach:<PID of iexplore.exe process>
  4. Run your scenario
  5. VSPerfCmd /detach
  6. VSPerfCmd /shutdown
  7. VSPerfClrEnv /off

 

이번 Visual Studio 2010 SP1에서는 개발 도구에서 직접 성능 프로파일을 지원합니다. 번거로이 Command Line을 사용할 필요 없이, 기존의 성능 프로파일의 사용 경험을 그대로 실버라이트 4에 적용할 수 있습니다.

Visual Studio 2010의 분석->성능 마법사 시작 메뉴를 클릭하여 실버라이트 응용 프로그램을 프로파일링 할 준비를 합니다.

 

아래와 같이 성능 프로파일을 시작하면 성능 마법사 페이지가 실행됩니다.

  • CPU 샘플링
    예를 들어, 많은 데이터 작업이나 UI요소 핸들링에서 CPU에 얼만큼의 부담을 주는지 측정할 수 있는 방법입니다.

  • 계측
    관리되는 응용 프로그램이 런타임에 얼마만큼의 리소스와 실행 시간을 갖는지 측정할 수 있습니다. 모듈/클래스/메서드 수준에서 성능을 측정할 수 있는 방법입니다.

  • .NET 메모리 할당
    관리되는 응용 프로그램이 얼만큼의 메모리를 소비하고, 가비지 컬렉션(Garbage Collection) 되는지 등의 수준 높은 메모리 정보를 제공합니다.

  • 동시성
    운영체제 차원에서 메모리의 교착 및 컨텍스트 스위칭(Context Switching)을 관찰하고 다른 프로세스에 어떤 영향을 받는지 Low Level의 정보를 제공합니다.

     

 
필자는 CPU 샘플링을 선택하였고, 2단계 페이지에서는 어떤 응용 프로그램을 프로파일링 할 지 선택합니다. 만약 솔루션 탐색기에 로드 되지 않은 프로젝트는 실행 파일(.EXE) 형태의 파일을 선택하면 소스 코드 없이 다음 단계로 이동할 수 있습니다.

 

3단계 마법사 페이지는 즉시 프로파일링을 시작할지 여부를 선택합니다. 기본 설정으로 마침을 선택하면 선택한 프로젝트 또는 실행 파일을 실행하고 프로파일링을 시작하게 됩니다.

 

응용 프로그램이 실행되면 다양한 테스트 시나리오로 테스트를 진행하고, 응용 프로그램을 마치면 수집된 프로파일링 정보로 프로파일링 결과 페이지를 볼 수 있습니다.

 

 

화면의 좌측 상단의 뷰를 변경하면서 성능 구간을 다양한 측면에서 분석을 할 수 있습니다.

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

그간 저희 Visual Studio Korea 팀에서 2010년 6월 1일 REMIX10 무료 온라인 백서를 참석 전원에게 드린 적이 있었습니다.

http://vsts2010.net/338
Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요

그리고 지난 2011년 4월 18일, 그 두 번째 온라인 무료 백서를 공개하게 되었습니다.

 

VISUAL STUDIO KOREA 팀의 온라인 백서 다운로드 사이트

http://msdn.microsoft.com/ko-kr/gg620748

Visual Studio 응용 프로그램 모델링 완전 정복 백서

엄준일 MVP (엔씨소프트) – 다운받기

 

"Visual Studio 응용 프로그램 모델링 완전 정복 백서" 개발자에서 뛰어난 개발자로 안내하는 효과적인 백서입니다. 최종 산출물인 동작하는 소스 코드를 위해, 모델링에 대한 배경과 방법을 개발자의 관점에서 설명합니다. 그리고 Visual Studio 2010 이용하여 개발자가 효과적으로 모델링을 있는 환경을 제시합니다.

개발자들이여, 이제는 "개발자는 코드로 말한다" 관념을 버리십시오.현대의 소프트웨어 개발에서는 언제까지 당신의 코드가 나오기까지 기다려주지 않습니다.선택과 집중의 개발 생태계에서 당신이 올바른 방향을 바라보고 발을 내딛는다는 것을 아무도 믿어주지 않습니다.

코드로 말하기 이전에 자신의 목적과 목표를 명확하게 시각화하여 말하는 것이야 말로 우리 시대가 원하는 뛰어난 개발자임이 확신합니다.

 

ASP.NET MVC - M, V 그리고 C 각방생활

박세식 (유니위스) - 다운받기

  

ASP.NET 가려운 곳을 긁어줄 대안의 프레임워크가 나왔으니 바로 ASP.NET MVC 프레임워크입니다. MVC 각각 담당하고 있는 일이 있습니다. 컨트롤러는 사용자 요청의 흐름을 제어하고 그에 따른 모델과 뷰를 선택하는 , 모델은 데이터와 유효성 검사, 비즈니스 로직을 담당하는 , 뷰는 컨트롤러에서 전달받은 데이터를 UI에서 처리하는 일을 합니다. 이렇게 모델, , 컨트롤러로 명확하게 분리된 구조가 여느 복잡한 어플리케이션도 구조적으로 쉽게 개발할 있도록 도와줍니다. 여기 백서를 통해 개발의 도움을 주는 M, V 그리고 C 각방생활을 소개합니다.

남자의 Visual Studio 2010 TDD(Test Driven Development)이야기

강보람 MVP (IT Flow 선임 컨설턴트), 박세식 (유니위스) - 다운받기

  

TDD(Test Driven Development), 테스트 주도 개발은 애자일한 개발을 지원하기 위한 하나의 실천적 도구입니다. 하지만, 단순히 세부적으로 어떻게 해야 되는 것인지를 묻는 'How'만으로는 TDD 제대로 이해할 수가 없습니다. 어째서 TDD 소개되었으며, TDD 통해서 어떤 장점을 얻을 있는지를 이야기 하는 'Why' 'What' 동반되어야 TDD 이해할 있는 기반을 마련하는 것이시죠. 여기 개발자가 TDD 대해 나눈 대화를 흥미롭게 재구성해 기록한 백서가 있습니다. 백서를 통해서 TDD 대한 'Why', 'What' 그리고 Visual Studio 2010 개발에 TDD 적용한 'How' 같이 얻으시기 바랍니다.

  

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 맨날맑음 2011.05.30 08:36 Address Modify/Delete Reply

    좋은 백서 감사합니다^.^

최근 2년 동안 다양한 개발 분야의 기술들이 물망에 오르는 굉장히 뜻 깊은 해였습니다. 2년 전이면 Microsoft 강성재 차장과 함께 처음으로 "Visual Studio 한국 공식 팀"을 창설하면서 http://vsts2010.net 이 탄생한 시기이군요. 2008년 12월에 팀이 창설되고, 2009년 1월 5일이 팀 블로그 2주년이 되는 날이었군요.

바로 저희 "Visual Studio 한국 공식 팀" 블로그에서 한홀 한홀 정성스럽게 작성된 포스트들이 2년 여간의 기술 흐름을 대변해 주고 있으며, 그리고 2011년의 기술도 짐작해 볼 수 있는 짧지만 굵은 변화의 흐름과 함께 여기까지 온 것 같습니다.

우리 팀이 함께 해왔던 핵심 키워드의 태그는 무엇이었을까요?

  • Visual Studio 2010
  • .NET 4.0, .NET Framework 4.0
  • ASP.NET MVC
  • C# 4.0
  • C++0x, C++/CLI
  • Parallel Computing
  • WCF
  • Cloud
  • Application Lifecycle Management

   

그리고 위의 태그들에 대해 더 자세히 살펴보더라도 생소한 기술과 이름, 아키텍처, 환경 등이 2년 동안 격변을 일으키며 변화를 해왔다는 사실입니다.

2011년 이전까지는 여러분들에게 선택권이었던 것들이, 이제는 필수가 되어야 한다고 해도 과언이 아닐 겁니다. 비즈니스 요구사항의 단면을 보면 업무적인 요인, 시대적인 배경 등인데, 이 시대적인 배경에는 트랜드+시장+기술+… 이 있을테고요. 그리고 '우리가 이 시대적인 배경 중 '기술'에 한 배를 타고 흐르고 있는가…?' 에 다시 한번 생각해 볼만 합니다.

예전 2010년 6월 1일 REMIX10 세미나에서 여러분에게 말씀 드린 마지막 문구가 다시금 생각이 나네요.

http://www.techdays.co.kr/2010spring/remix10/session3_1.html

   

여러분의 생존전력은 바로 아래에 해답이 있습니다. 여러분들에게 필요한 것, 그리고 그 가능성이 있다고 판단하시면 2011년 생존을 위하여 달려보는 것은 매우 멋진 2011년 한 해가 될 것입니다.

   

.NET 프레임워크

.NET Framework .NET 의 과거와 현재, 그리고 미래
.NET Framework .NET Framework 4.0 의 특징
.NET Framework .NET Framework 4.0 마이그레이션 이슈
.NET Framework .NET 스마트클라이언트 한계 극복 [1]
.NET Framework .NET 스마트클라이언트 한계 극복 [2]
CLR 1. Hello 世界
CLR 2. CLR! CLR! CLR!
CLR 3. MSCorLib & Metadata
CLR 4. Assembly
CLR 5. Assembly - Strongly named assemblies
CLR 6. Assembly - GAC(Global Assembly Cache)
CLR 7. System.Object
CLR 8. System.Object (2)
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-2. 네이티브 랩퍼 만들기
Managed Extensibility Framework [MEF] 1. Managed Extensibility Framework 이란?
Managed Extensibility Framework [MEF] 2. Parts 와 Contracts 선언
Managed Extensibility Framework [MEF] 3. Export 선언
Managed Extensibility Framework [MEF] 4. Import 선언
Managed Extensibility Framework [MEF] 5. Catalog 사용
Managed Extensibility Framework [MEF] 6. Lazy Exports
Managed Extensibility Framework [MEF] 7. Exports and Metadata
Managed Extensibility Framework [MEF] 8. Strongly Typed Metadata
Managed Extensibility Framework [MEF] 9. Recomposition
Managed Extensibility Framework [MEF] 10. Querying the CompositionContainer
Managed Extensibility Framework MEF Preview 6 공개
Managed Extensibility Framework MEF 는 Generic Type 을 지원하지 않는다!
Managed Extensibility Framework MEF 에 Generic Type 을 지원하기 위해서..?
Managed Extensibility Framework MEFGeneric 코드 플랙스에 공개합니다.

   

애자일 개발

Agile Development [Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
Agile Development [Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
Agile Development [Better Code]Visualize Code Relationships
Agile Development [Testing] TDD (Test-Driven Development-테스트 주도 개발)
Agile Development [Testing] BDD (Behavior-Driven Development?행위 주도 개발)
Agile Development [Testing] Moq.NET (T/B Driven Development)
Agile Development [Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
Agile Development 애자일에 대한 고찰
Agile Development [ALM-Test] 1. 왜 단위 테스트를 해야 하는가?
Agile Development [ALM-Test] 2. 한국적인 애자일 모델의 필요성
Agile Development [협업 1] 협업 도구의 통일성과 협업 인프라 관리
Agile Development [ALM-Test] 3. 테스터에 대한 오해와 진실
Agile Development [ALM-Test] 4. 테스터(SDET) 의 역할
Agile Development [ALM-Test] 5. 테스트 계획
Agile Development [ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
Agile Development [ALM-Test] 7. TDD vs 계약기반 테스트
Architect Development Architect Development ?
Architect Development 몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development 몽당연필과 함께 하는 VSTS 2010 모델링 1/4
Architect Development Windows Server AppFabric - Velocity 란?
Architect Development WCF=SOA 에 대한 고찰

   

ASP.NET 4.0

ASP.NET 4.0 [ASP.NET 4.0] 1. Core Service - Extensible Output Caching
ASP.NET 4.0 [ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(1)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Designer & Deployment
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Core Services
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - New Features in the Microsoft Ajax Library
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(1)
ASP.NET 4.0 Razor in WebMatrix
ASP.NET 4.0 Razor in WebMatrix(2) 코드의 재 사용
ASP.NET 4.0 Razor in WebMatrix(3) ? WebMatrix Helper
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(3)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(4)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(5)
ASP.NET MVC M, V 그리고 C의 각방생활(1) - ASP.NET MVC vs ASP.NET WEB FORM
ASP.NET MVC M, V 그리고 C의 각방생활(2) - ASP.NET MVC와 인사나누기
ASP.NET MVC M, V 그리고 C의 각방생활(3) - 초간단 사이트 만들기(1)
ASP.NET MVC M, V 그리고 C의 각방생활(4) - 유효성 검사
ASP.NET MVC M, V 그리고 C의 각방생활(5) - 초간단 사이트 만들기(2)
ASP.NET MVC M, V 그리고 C의 각방생활(6) - 유효성 검사(2)
ASP.NET MVC M, V 그리고 C의 각방생활(7) - 함께 즐겨요~ jQuery
ASP.NET MVC M, V 그리고 C의 각방생활(8) - jQuery와 탭메뉴 그리고 파샬뷰
ASP.NET MVC M, V 그리고 C의 각방생활(9) - jqGrid 사용해보자
ASP.NET MVC M, V 그리고 C의 각방생활(10) - jqGrid를 이용한 paging과 sorting
ASP.NET MVC ASP.NET MVC 3 Preview 1 이 릴리즈 되었습니다.
ASP.NET MVC M, V 그리고 C의 각방생활(11) - jqGrid로 데이터 추가,편집,삭제해보기
ASP.NET MVC M, V 그리고 C의 각방생활(12) - 테스팅 그거, 아무나 하나?
ASP.NET MVC JailBreak From Controllers and Actions
ASP.NET MVC VSTS2010 에서 Razor 코드 하이라이팅 지원하기

   

C# 4.0

C# [C# 4.0] Named and Optional Parameters
C# [C# 4.0] Duck Typing
C# [C# 4.0] New Extension Method "Zip"
C# [C# 4.0] Generic Covariance And Contra Variance
C# Welcome to Dynamic C#(1) - 첫만남.
C# Welcome to Dynamic C#(2) - Wanna be a polyglot.
C# Welcome to Dynamic C#(3) - 마음이 넒어진 C#
C# Welcome to Dynamic C#(4) - 극과극 비교체험.
C# Welcome to Dynamic C#(5) - Return to Dynamic.
C# Welcome to Dynamic C#(6) - Return to Dynamic (2)
C# Welcome to Dynamic C#(7) - 아낌없이 표현해 주는 나무
C# Welcome to Dynamic C#(8) - DLR이 나무를 사랑하는 이유
C# Welcome to dynamic C# 외전(1) - Generate From Usage.
C# Welcome to dynamic C# 외전(2) - Generic Method.
C# Welcome to dynamic C# 외전(3) - 감시하는 자와 감시당하는 자.
C# Welcome to Dynamic C#(9) - Dynamic Returns Again.
C# Welcome to Dynamic C#(10) - Dynamic Returns Again.(2)
C# Welcome to Dynamic C#(11) - The Phantom of The Dynamic
C# Welcome to Dynamic C#(12) - dynamic은 외로운 아이.
C# Welcome to Dynamic C#(13) - 아직도 가야할 길.
C# Welcome to Dynamic C#(14) - 철지난 만우절에 낚여서 파닥파닥.
C# Welcome to Dynamic C#(15) - A/S for dynamic.
C# Welcome to Dynamic C#(16) - dynamic이라도 이건 안되는 거임.
C# Welcome to Dynamic C#(17) - 필요한 말만 하고 삽시다.
C# Welcome to Dynamic C#(18) - 이름을 붙이면서 벌어진 일들.
C# Welcome to Dynamic C#(19) - 위너 고르기.
C# Welcome to Dynamic C#(20) - 어르신과 대화하는 법.
C# Welcome to Dynamic C#(21) - 인덱스의 힘.
C# Welcome to Asynchronous C#(0) - C#의 전설.
C# Parallel Programming [C# 4.0] Parallel Extension - [1] 병렬 처리
C# Parallel Programming [C# 4.0] Parallel Extension - [2] 병렬 처리 아키텍처
C# Parallel Programming [C# 4.0] Parallel Extension - [3] TPL(Task Parallel Library)
C# Parallel Programming Welcome to Parellel world(1) - Here comes a new challenger!
C# Parallel Programming Welcome to Parallel C#(1) - 굿바이, 그리고 안녕~~?
C# Parallel Programming Welcome to Parallel C#(2) - 계속 되는 개념 찾기.
C# Parallel Programming Welcome to Parallel C#(3) - 작업의 기본.
C# Parallel Programming Welcome to Parallel C#(4) - 작업의 기본 Part 2.
C# Parallel Programming Welcome to Parallel C#(5) - 병렬작업에서 예외가 생기면 어케...?
C# Parallel Programming Welcome to Parallel C#(6) - To be continue...
C# Parallel Programming Welcome to Parallel C#(7) - Excuse me.
C# Parallel Programming Welcome to Parallel C#(8) - 취소 쉽게 하기.
C# Parallel Programming Welcome to Parallel C#(9) - 백지장은 맞들지 말엉.
C# Parallel Programming Welcome to Parallel C#(10) - 이보게, 잠깐 뒤를 돌아보지 않겠나.

   

C++/CLI

C++/CLI C++/CLI는 미운 오리새끼 or 백조
C++/CLI .NET에서의 C++/CLI의 의미
C++/CLI [Step 01] 'C++/CLI가 뭐야?'에 답하기 && 가장 많은 프로그래밍 언어로 만드는 프로그램 만들기
C++/CLI [Step 02-1] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [Step.02-2] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [step.03] 배열
C++/CLI [Step. 04] nullptr, interior_ptr, pin_ptr
C++/CLI [Step. 05] 관리 코드의 array를 비관리 코드에 포인터로 전달
C++/CLI [Step. 06-1] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 06-2] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 07] 비관리 클래스에서 관리 클래스를 멤버로, 관리 클래스에서 비관리 클래스를 멤버로
C++/CLI [Step. 08] 프로퍼티 ( property )
C++/CLI [Step. 09] 델리게이트 (delegate)
C++/CLI [Step. 10] 이벤트 ( event )
C++/CLI [Step. 11] 열거형( enum )
C++/CLI [Step. 12] for each
C++/CLI [Step. 13] parameter array
C++/CLI [Step. 15] static 생성자, initonly, literal
C++/CLI [Step. 14] 인터페이스 ( interface )
C++/CLI [Step. 16] array 클래스에 non-CLI 오브젝트 사용
C++/CLI [Step. 17] 델리게이트에 비관리 함수를 할당하기 그리고 다음 예고
C++/CLI [Step. 18] 순수 가상 함수
C++/CLI [Step. 19] char* -> 관리코드, 관리코드 -> char*
C++/CLI [Step. 20] 닷넷에서 HalfNetwork를 사용하자 - 1
C++/CLI [Step. 21] 닷넷에서 HalfNetwork를 사용하자 - 2
C++/CLI [Step. 22] 닷넷에서 HalfNetwork를 사용하자 ? 3
C++/CLI [Step. 23] 닷넷에서 HalfNetwork를 사용하자 ? 4
C++/CLI [Step. 24] 닷넷에서 HalfNetwork를 사용하자 ? 5
C++/CLI [Step. 25] 닷넷에서 HalfNetwork를 사용하자 ? 6(마지막)

   

C++0x

C++0x [VC++] 1. 큰 변화가 기대되는 Visual C++( VC++ )
C++0x [VC++] 2. C++0x의 auto
C++0x [VC++] 3. static_assert
C++0x [VC++] 4. 우측 값 참조( RValue Reference ) - 첫 번째
C++0x [VC++] 5. 우측 값 참조( RValue Reference ) ? 두 번째
C++0x [VC++] 6. 우측 값 참조( RValue Reference ) - 세 번째
C++0x [VC++] 7. 우측 값 참조( RValue Reference ) - 네 번째
C++0x [VC++] 8. 우측 값 참조( RValue Reference ) ? 다섯 번째
C++0x [VC++] 9. Lambda ( 람다 ) - 첫 번째
C++0x [VC++] 11. Lambda - 두 번째
C++0x [VC++] 12. Lambda - 세 번째
C++0x [VC++] 13. Lambda - 네 번째
C++0x [VC++] 14. decltype
C++0x 대용량 파일 조작을 위한 C++0x의 변화
C++0x nullptr
C++0x VC++ 10에 구현된 C++0x의 코어 언어 기능들
C++0x C++0x 관련 책 "Visual C++ 10과 C++0x"
C++0x "Visual C++ 10과 C++0x" pdf 파일
C++0x [Plus C++0x] 람다(Lambda) 이야기 (1)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (2)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (3)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (마지막회)
C++0x [STL] 1. What's new in VC++ 2010?
C++0x [STL] 2. unique_ptr (1/2)
C++0x [STL] 3. unique_ptr (2/2)
C++0x [STL] 4. make_shared
C++0x [STL] 5. 에 추가된 새로운 함수들 (1/5)
C++0x [STL] 6. 에 추가된 새로운 함수들 all_of, any_of, none_of (2/5)
C++0x VS2010에서 nullptr의 알려진 버그
C++0x RValue Reference에 의한 STL의 성능향상 테스트
C++0x [STL] 7. 에 추가된 새로운 함수들 copy_if, copy_n, find_if_not (3/5)
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [0]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [1]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [2]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [3]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [4]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [5]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [6/7] 완결!
VC++ 10 Concurrency Runtime PPL task를 이용한 피보나치 수 계산
VC++ 10 Concurrency Runtime 인사 및 Multi Core, Multi Thread...그리고 VC++ 10
VC++ 10 Concurrency Runtime Concurrency Runtime
VC++ 10 Concurrency Runtime Parallel Patterns Library (PPL)
VC++ 10 Concurrency Runtime 양보할 줄 아는 Concurrency Runtime의 event
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - Task
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - 병렬 알고리즘
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for_each 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_invoke
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 마지막회
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - combinable
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 2
VC++ 10 Concurrency Runtime Concurrency Runtime(ConcRT)의 디버그 모드에서 메모리 leak 문제
VC++ 10 Concurrency Runtime Asynchronous Agents Library 소개
VC++ 10 Concurrency Runtime Asynchronous Agents Library - agent. 1 ( 상태 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? agent. 2 ( 기능 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library - message 전달 함수. 1 ( 전송 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message 전달 함수. 2 ( 수신 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 1. ( 인터페이스 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 2. ( unbounded_buffer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 3. ( overwrite_buffer & single_assignment )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 4. ( call )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 5. ( transformer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 6. ( choice )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 7. ( join & multitype_join )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 8. ( timer )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 1. ( critical_section & reader_writer_lock )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 2. ( event )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 9. ( custom )
VC++ 10 Concurrency Runtime Concurrency Runtime - 만델브로트 프랙탈 ( Mandelbrot Fractal ) 예제
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 1. ( Scheduler )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 2. ( SchedulerPolicy )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 3. ( ScheduleGroup )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 4. ( ScheduleTask )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 5. ( Context blocking )
Visual C++ 10 About Visual C++ 10
Visual C++ 10 디버깅 모드에서 역어셈블리 코드 보기
Visual C++ 10 Visual C++ 10의 변화
Visual C++ 10 [Upgrade to VC++ 10] _WIN32_WINNT 버전 문제
Visual C++ 10 VS2010 C++ 프로젝트의 디렉토리 설정

   

클라우드 컴퓨팅

Cloud 구름 속의 미래 : Windows® Azure™ Platform [1]
Cloud SQL Azure - CTP1
Cloud SQL Azure 알아보기 (1) - 데이터베이스 개체 생성
Cloud SQL Azure 알아보기(2) ? 데이터베이스 스키마 마이그레이션, 데이터 전송
Cloud 구름 속의 미래 : Windows® Azure™ Platform [2]
Cloud SQL Azure 사용 시 주의점(1) - 방화벽 설정
Cloud SQL Azure 알아보기(3) ?SQL Server 2008 R2 Nov CTP
Cloud SQL Azure 알아보기(4) ? SQL Azure Cloud App
Cloud SQL Azure 알아보기 (5)- SQL Azure 이점과 T-SQL 지원
Cloud [MS@클라우드컨퍼런스] MS 클라우드 기술과 플랫폼
Cloud 클라우드 기반 분산 컴퓨팅을 위한 AppFabric (1) : 아하! App 분산!
Cloud Hello Windows Azure / Windows Azure Platform의 이해
Cloud Hello Windows Azure / Gallery of 'Powered by Windows Azure Platform'
Cloud Hello Windows Azure / Windows Azure 개발 환경의 구축
Cloud Hello Windows Azure / Understanding Windows Azure Development Process
Cloud Hello Windows Azure / Windows Azure Tools for Visual Studio 1.2 출시
Cloud Hello Windows Azure / Windows Azure Platform 최신 소식 업데이트 (종합) [수정]
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #1
Cloud Windows Azure Update: Microsoft Project Code-Named "Houston" CTP 1
Cloud SQL Azure와 Excel 2010의 PowerPivot
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #2
Cloud Windows Azure Update: CloudStorageAccount 클래스 사용 시 주의 사항
Cloud SQL Azure Update: Dynamic Management View
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #3
Cloud Windows Azure Update: myAzureStorage
Cloud SQL Azure 와 SQL Reporting Service
Cloud Windows Azure Update: Windows Azure CDN의 활용
Cloud [작업 중] Windows Azure Update: Adaptive Smooth Streaming with Windows Azure Storage

   

게임 개발

Direct3d Mobile [d3dm 기초] 1. wm6.x 개발환경 세팅
Direct3d Mobile .NET 기반에서 공개소스 게임엔진 포팅하기
DirectX 11 [JumpToDX11-1] 사라진 Direct3D 오브젝트를 찾아서...
DirectX 11 [JumpToDX11-2]DeviceContext...넌 누구냣!!
DirectX 11 [JumpToDX11-3] Feature Level
DirectX 11 [JumpToDX11-4] ID3D11View
DirectX 11 [DX11_#1]D3D Buffer( 1 / 2 )
DirectX 11 [DX11_#2]D3D Buffer( 2 / 2 )
DirectX 11 [DX11_#3]기본적인 설정
DirectX 11 [JumpToDX11-5] 새로운 시대를 여는 DirectX11...
DirectX 11 [JumpToDX11-6] 커맨드(Command)...
DirectX 11 [DX11_#4]텍스트, 버튼 출력
DirectX 11 [JumpToDX11-7] 간편해진 리소스 처리.
DirectX 11 [JumpToDX11-8] Deferred Contexts
DirectX 11 [JumpToDX11-9] Multi-threaded Rendering 을 위한 API.
DirectX 11 [JumpToDX11-10] GPGPU 를 위한 DirectCompute.
DirectX 11 [JumpToDX11-11] DirectCompute 를 위한 한걸음!
DirectX 11 [JumpToDX11-12] DirectCompute 의 절차.
DirectX 11 [JumpToDX11-13] Tessellation 등장.
DirectX 11 [DX11_#5]DirectX11의 활용 사례(1/3)
DirectX 11 [JumpToDX11-14] DirectX9 세대의 테셀레이션( ID3DXPatchMesh 편 )
DirectX 11 [JumpToDX11-15] DirectX9 세대의 테셀레이션( IDirect3DDevice9::DrawXXXPatch편 )
DirectX 11 [알콜코더의 미리 배워보는 DirectX 11 - 입문편] 0. 누구를 위한 연재인가
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #1
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #2
DirectX 11 [JumpToDX11-16] DirectX9 세대의 테셀레이션( D3DXTessellateNPatches편 )
DirectX 11 [알콜코더의 미리 배워보는 DX11 ? 입문편] DX11에서 무엇이 추가되었나?
DirectX 11 [JumpToDX11-17] DirectX9 세대의 테셀레이션( ATI 라이브러리편 )
DirectX 11 [발표자료] 예제로 느껴보는 다이렉트X 11의 매력
DirectX 11 [JumpToDX11-18] DirectX11의 테셀레이션 ( 테셀레이션을 위한 하드웨어의 등장편 )
DirectX 11 [알콜코더의 미리 배워보는DX11 입문편] DirectX 11의 특징들
DirectX 11 [알콜코더의 미리배워보는 DX11-입문편] 1. 튜터리얼01 : 디바이스와 스왑체인의 생성

   

F#

F# Welcome to F#(1) - 첫만남.
F# Welcome to F#(2) - 두번째 만남.
F# Welcome to F#(3) - 사소한 탐색전.
F# Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
F# Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
F# Welcome to F#(6) - 비교본능.
F# Welcome to F#(7) - 클리프 행어.
F# Welcome to F#(8) - 은총알과 엄친아.
F# Welcome to F#(9) - 메이져 데뷰.
F# Welcome to F#(10) - 인도음식 카레.....?
F# Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
F# Welcome to F#(12) - 공동작업 좋치아니항가

   

MFC

MFC [MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개
MFC [MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
MFC [MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
MFC [MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
MFC [MFC/윈도우 7 멀티터치] #2 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #3 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #4 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #5 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #6 : 예제 코드 올립니다

   

RIA

RIA Expression Blend3 preview - 1.인터페이스
RIA Expression Blend3 preview - 2. Photoshop import
RIA Silverlight 3 & Blend 3 RC 공개!!!
RIA Silverlight 4 Beta 공개
RIA .Net Ria Service + IIS6 + Silverlight 4 Troubleshooting!!
RIA 실버라이트 비하인드 코드에서 바인딩하기.
RIA .Net Ria Service 와 Entities 그리고 Stored Procedure 하다가 생긴일..
RIA 실버라이트 프로그래머가 할 수 있는 최소한의 블랜드 디자이너를 위한 배려

   

SharePoint 2010

SharePoint 2010 Visual Studio 2010 에게 바란다 - SharePoint 14 Development
SharePoint 2010 SharePoint 2010 Overview
SharePoint 2010 SharePoint 2010 개발 환경 구성
SharePoint 2010 SharePoint 2010 개발 환경- Hello World 웹 파트 생성 및 배포하기
SharePoint 2010 SharePoint 2010 Web Part 생성
SharePoint 2010 SharePoint 2010 Visual Web Part
SharePoint 2010 SharePoint 2010 Feature
SharePoint 2010 SharePoint 2010 Event Receiver
SharePoint 2010 SharePoint 2010 데이터 기술
SharePoint 2010 SharePoint 2010 Server Object Model
SharePoint 2010 Visual Studio 2010 출시에 따른 SharePoint Developer Tools
SharePoint 2010 SharePoint 2010 LINQ to SharePoint
SharePoint 2010 Client Object Model - .NET
SharePoint 2010 Client Object Model ? Silverlight (1)
SharePoint 2010 Client Object Model ? Silverlight (2)
SharePoint 2010 Client Object Model - Javascript(1)
SharePoint 2010 Client Object Model - Javascript(2)
SharePoint 2010 Client Object Model ? 정리
SharePoint 2010 SharePoint 2010 개발환경 구축 가이드
SharePoint 2010 REST -.NET
SharePoint 2010 REST ? Silverlight
SharePoint 2010 REST - jQuery
SharePoint 2010 SharePoint 2010 프로젝트 디버깅
SharePoint 2010 SharePoint 2010 Developer Dashboard

   

Team Foundation Server

Team Foundation Server Visual Studio Team System 2010 (CTP10) - 작업 항목 링크
Team Foundation Server TFS 2010 설치 하기
Team Foundation Server TFS 2010 Build Service 설치
Team Foundation Server TFS 2010 설치 과정 중에 TF255040 문제
Team Foundation Server Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
Team Foundation Server Team Foundation 트러블 슈팅 가이드
Team Foundation Server Visual Studio Team Foundation Server 2010 를 설치해보자
Team Foundation Server Visual Studio Team Foundation Server 2010 설치 전 할일
Team Foundation Server VS TFS 2010 설치편 - 설치전 IIS, .NET 설치
Team Foundation Server VS TFS 2010 설치편 - 설치 시작
Team Foundation Server VS TFS 2010 구성편 - 설치 후 TFS 구성으로 점심 얻어먹기 편
Team Foundation Server VS TFS 2010 사용편 - SourceSafe? 버려~
Team Foundation Server [HowTo] Team Foundation Server 의 로컬 매핑 캐시 제거하기
Team Foundation Server [HowTo] SharePoint 2010 Beta 깨끗하게 제거하기
Team Foundation Server [HowTo] SCVMM 의 Install Virtual Guest Service 작업 중 2941 오류
Team Foundation Server [HowTo] TFS2010 의 Tfs_Analysis 웨어하우스 데이터베이스가 망가졌을 경우
Team Foundation Server [PPT] 테스트와 가상화의 만남 - 테스트 가상화(Lab Management)
Team Foundation Server Team Foundation Server 2010으로 업그레이드, 마이그레이션, 동기화
Team Foundation Server Visual Source Safe 사용자를 위한 TFS2010 시리즈

   

Visual Studio 2010

Visual Studio 2010 Visual Studio Team System 2010 CTP 만료 해결하기
Visual Studio 2010 Visual Studio 2010 의 특징
Visual Studio 2010 Visual Studio 2010 내부 빌드 최신 동영상: C# 4.0 Language + IDE + WPF Shell + Editor
Visual Studio 2010 Visual Studio 2010 & .NET 4.0 참고 자료들
Visual Studio 2010 Visual Studio 2010 Beta 1 설치부터 살펴보기
Visual Studio 2010 멀티 모니터 사용
Visual Studio 2010 Visual Studio 2010 Beta 2 출시
Visual Studio 2010 Visual Studio 2010 Beta 2 설치 미리 보기
Visual Studio 2010 VS 2010 Beta 2 설치 과정에서 Silverlight SDK 문제
Visual Studio 2010 VS2010 베타2의 WPF & Silverlight 디자이너 성능 향상 팁
Visual Studio 2010 VS 2010 기능 소개 01 인텔리 센스 기능의 변화
Visual Studio 2010 Visual Studio 2010과 Blend Preview for .NET 4 통합 문제
Visual Studio 2010 VS 2010 기능 소개 02 - IDE의 기능 추가
Visual Studio 2010 VS 2010 기능 소개 03 - IDE의 변화
Visual Studio 2010 Visual Studio 2010 출시 일정
Visual Studio 2010 VS 2010 기능소개 04 - Visual C#&VB 개발자 IDE Tips & Tricks 첫번째
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010 RC 공개 임박!
Visual Studio 2010 Visual Studio 2010 RC 공개
Visual Studio 2010 C#에서 IntelliSense가 동작하지 않을 때 문제 해결 방법
Visual Studio 2010 똑똑한 검색을 지원하는 VSTS 2010의 "Navigate To" 검색
Visual Studio 2010 실버라이트4 RC와 블렌드 4 베타 공개
Visual Studio 2010 윈도우폰 7 개발환경 공개
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (2회) - VS IDE
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (3회) - Box Selection
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (4회) - Call Hierarchy
Visual Studio 2010 Visual Studio 2010 출시와 완소 정보 총 정리
Visual Studio 2010 Visual Studio 2010 e-book 무료로 다운로드 하세요
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (5회) - Navigate To
Visual Studio 2010 Visual Studio 2010 RTM 추가 완소 정보
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (6회) - Generate from Usage
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Just for fun! / Visual Studio Express Edition
Visual Studio 2010 왜 Visual Studio 2010 이여야 하는가?
Visual Studio 2010 Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요
Visual Studio 2010 Just for fun! / DreamSpark는 대학생 여러분을 위한 솔루션입니다.
Visual Studio 2010 VS2008 을 VS2010 에서 동시에 개발하기
Visual Studio 2010 VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우
Visual Studio 2010 Introducing Visual Studio LightSwitch! - Enjoy your development
Visual Studio 2010 Visual Studio Hotfix List
Visual Studio 2010 곧 다가올 기술, Microsoft Research [1/2]
Visual Studio 2010 곧 다가올 기술, Microsoft Research [2/2]
Visual Studio 2010 Visual Studio 31 (1) - 시작, 그리고 Intellisense
Visual Studio 2010 Visual Studio 31 (2) - Startpage
Visual Studio 2010 Visual Studio 31 (3) - Temp Project
Visual Studio 2010 Visual Studio 31 (4.1) - Visual Studio 2010 Productivity Power Tools, Part 1
VIsual Studio Extensibility [Blueprints] S+S Blueprints
VIsual Studio Extensibility Visual Studio 2010 SDK 와 Readme
VIsual Studio Extensibility Visual Studio 2010 Extension Manager
VIsual Studio Extensibility [VSIX] 1. What is different from before version?
VIsual Studio Extensibility [VSIX] 2-1. How to start VSIX programming
VIsual Studio Extensibility [VSIX] 2-2. How to start VSIX programming
VIsual Studio Extensibility MousePresentationTracker - MEF 세미나 예제
VIsual Studio Extensibility [VSX] 1. Visual Studio Extensibility,, 그 시작
VIsual Studio Extensibility Visual Studio 2010 확장 모델인 VSIX 버그
VIsual Studio Extensibility VSGesture v2.0 for VS2010 is now available for download

   

우리 블로그 소식

VSTS 2010 팀 블로그 Visual Studio Team System 2010 공식 팀 블로그 맴버소개
VSTS 2010 팀 블로그 Visual Studio Team System 2010 팀 블로그 소개
VSTS 2010 팀 블로그 VSTS 2010 팀 블로그/스터디 맴버를 모집합니다.
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 지원을 마감합니다
VSTS 2010 팀 블로그 Visual Studio Team System 2010 Beta 1 공개
VSTS 2010 팀 블로그 [MSDN 주간 세미나] 발표자료 / .NET Framework와 Visual Studio : 현재와 미래 1, 2
VSTS 2010 팀 블로그 VSTS 2010 팀 3분기 맴버 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 세미나 동영상 - 6월 10일
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 추가 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 트위터를 오픈하였습니다.
VSTS 2010 팀 블로그 TECH DAY 2009 행사 오픈!!!
VSTS 2010 팀 블로그 VSTS 2010 공식 블로그 Viva 2010팀 멤버 추가 모집 공고
VSTS 2010 팀 블로그 [세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나
VSTS 2010 팀 블로그 Visual Studio 2010 팀에서 팀원 모집합니다.
VSTS 2010 팀 블로그 한국 Visual Studio 2010 사용자를 위한 트위터 커뮤니케이션
VSTS 2010 팀 블로그 C++ 개발자와 함께하는 Visual Studio 2010
VSTS 2010 팀 블로그 [무료 세미나] ReMIX 10
VSTS 2010 팀 블로그 6월 1일, 대한민국 웹 컨퍼런스의 지존 ReMIX 10가 개최됩니다!
VSTS 2010 팀 블로그 REMIX10 의 VS2010 팀 후기
VSTS 2010 팀 블로그 6월 1일, REMIX10 세미나 세션 공개
VSTS 2010 팀 블로그 [세미나] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
VSTS 2010 팀 블로그 9월 13일에 개최하는 KGC에서 강연을 합니다.
VSTS 2010 팀 블로그 KGC10에서의 VS2010 스터디 팀의 활약 모습
VSTS 2010 팀 블로그 [VSKOREA] Visual Studio 2010 정보가 한 눈에…
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [후기] C++ & 게임 개발자를 위한 개발 생산성 및 퍼포먼스 향상 전략 세미나

   

WCF

WCF WCF란 무엇인가?
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
WCF WCF의 기본 - Service Contract
WCF WCF의 기본 - Data Contract
WCF WCF 서비스의 동시성(Concurrency) - 1
WCF WCF 서비스의 동시성(Concurrency) - 2
WCF WCF - Serialization
WCF WCF Hosting - WAS를 이용한 Hosting
WCF 도메인을 여러개 등록했을때 WCF 서비스를 호스팅 할수 없어요 ㅠㅠ
WCF WCF Hosting(2) - ASP.NET 호환성(Compatibility)
WCF WCF Hosting (3) - Windows Service를 이용한 Hosting
WCF WCF Security (1) - SSL을 이용한 전송계층에서의 보안 설정
WCF WCF Security (2) - 전송 계층에서의 메세지 인증 (사용자 지정 인증)
WCF WCF Troubleshooting (1)
WCF WCF Service Configuration Editor
WCF WCF Troubleshooting (2)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2011.01.11 00:15 Address Modify/Delete Reply

    대박이군요!

  2. 구조신호 2011.06.03 18:09 Address Modify/Delete Reply

    오 한곳에 다 모여있으니 좋네요~~~~!!!!
    감사합니다!!

오늘 Microsoft 의 Scottgu's Blog 를 통해 WebMatrix & Razor 기술이 소개되었습니다.    

우선 간단하게 용어를 정리해봅시다.

WebMatrix

경량화한 웹 개발 도구

Razor

ASP.NET 의 뷰(View) 엔진

즉, WebMatrix&Razor 는 빠르게 웹 개발 환경을 구성하고 Razor 의 뷰(View) 엔진을 이용하여 신속하게 웹 페이지를 개발하고자 합니다. 웹 환경/웹 개발/데이터베이스/웹 개발 도구 등 WebMatrix&Razor 에 모두 포함이 되어 있습니다.

아마도 처음 웹 개발에 접하시는 분들이 처음 갖는 고민은..? 웹 환경 구성/웹 프로토콜 및 통신의 이해/호스팅 등 복잡했던 초기 작업을 매우 효과적이고 간소화하여 신속하게 작업을 진행할 수 있는 장점이 있습니다.

   

WebMatrix 란 무엇인가요?

WebMatrix 는 약 15MB 의 용량으로 빠르게 웹 개발 환경을 갖출 수 있습니다. (단, .NET Framework 4.0 이 인스톨 되지 않았을 경우 약 50MB). 현재 WebMatrix 는 Beta 버전이며 이 링크를 클릭하시면 다운로드 받으실 수 있습니다.

이 웹 WebMatrix 에는 다음의 구성 요소가 포함이 되어 있습니다.

  • IIS Express
  • SQL Compact Edition
  • ASP.NET Extensions

그리고 Visual Studio 2010 또는 Visual Web Development 2010 Express 개발 도구를 이용하여 웹 개발 또는 커스터마이징을 하실 수 있습니다.

   

WebMatrix 는 쉽게 사용할 수 있게 설계가 되었습니다.

초기 웹 개발 환경은 웹 페이지를 만들기 위해 해야 할 일들이 많았습니다. 환경 구성/개발 환경 구성 등 말이죠.

WebMatrix 는 아래와 같이 매우 심플한 디자인으로 웹 개발의 시작을 빠르고 쉽게 수행할 수 있습니다. Site from Web Gallery 는 오픈 소스 웹 어플리케이션을 바로 설치하여 사용할 수 있고, Site From Template 으로 최적화된 환경에서 개발을 시작할 수 도 있습니다.

Site From Web Gallery 는 온라인에서 인기 있는 다양한 오픈 소스 웹 어플리케이션이 포함되어 있답니다. ASP.NET, PHP 의 오픈 소스 웹 어플리케이션이 포함되어 있으며, 설치나 배포가 매우 간단합니다.


그 중, Scott 님은 BlogEngine.NET 으로 예제를 보여주시네요. BlogEngine.NET 는 이미 예전부터 CodePlex 를 통해 오픈 소스로 공개가 되고 현재도 인기 있는 블로그 웹 어플리케이션입니다.

BlogEngine.NET 을 선택하고 Next 버튼을 클릭하면 이것을 설치하기 위한 컴포넌트를 체크하거나 다운로드 받습니다. 즉, 원클릭(One-Click) 으로 어플리케이션이 동작하기 위한 모든 환경을 스스로 구성한다는 얘기죠^^

PHP 어플리케이션의 경우 WordPress, Drupal, Joomla, Sugar CRM 등은 MySQL 이 필요한데, 개별적인 설치 없이 이런 환경도 자동으로 다운로드 받아 설치를 합니다.

간단하게 소프트웨어 사용권 동의(EULA) 를 클릭하면 바로 설치와 구성 작업을 시작합니다.

   

그리고 금새 설치와 구성이 완료가 되었지요^^

   

모든 구성이 완료되면, 아래와 같은 Overview 페이지가 나타납니다.

   

설치된 BlogEngine.NET 을 실행하기 위해서 아래의 Run 버튼을 클릭합니다. 인터넷 익스플로러, 크롬, 파이어폭스로 실행할 수 있고, Open in all browsers 로 여러 브라우저로 한꺼번에 실행할 수 있습니다.

   

자! 여태까지 클릭 클릭만 했는데, 아래와 같이 BlogEngine.NET 이 설치되고, 구성되고, 모든 구성이 완료가 됩니다.

   

초기 관리자 아이디와 비밀번호는 admin/admin 입니다. 관리자로 로그인 하셔서 블로그의 이름을 달아주시고, 블로그 저자 소개 등을 입력해 주시면, 곧바로 블로그를 운영을 준비하셔도 될 것 같습니다.^^

WebMatrix 는 오픈 소스 웹 어플리케이션을 커스터마이징 할 수 있는 약간의 개발 환경도 제공해 줍니다. 아래와 같이 소스 코드를 변경할 수 도 있고, Files 버튼으로 파일을 편집하거나 추가, 삭제를 할 수 있습니다.

   

이제 블로그를 운영하기 위해 배포와 호스팅을 해야 합니다.

WebMatrix 의 특징은 매우 경량화되었고 작업 환경이 통합된 장점을 갖습니다. 로컬 또는 원격 웹 서버로 배포할 때, FTP 또는 FTP/SSL 또는 Microsoft Web Deploy(MSDeploy) 를 이용하여 쉽게 배포가 가능합니다.

아래의 Publish 버튼을 클릭하면 배포 준비가 시작됩니다.

   

배포 세팅 화면은 아래와 같습니다. 서버의 기본 정보를 입력하고, 데이터베이스의 연결 문자열을 입력한 후에, Publish 버튼을 클릭합니다.

   

모든 준비가 완료되었고, Publish 버튼을 누르면 이제 배포를 시작할 준비가 완료 되었습니다.

   

이하.. 금일 Microsoft Korea 의 김대우 과장님께서 진행하는 WebMatrix&Razor 세미나에 참석하기 위해 이만 줄입니다. 다른 분들께서 더 알차고 재미있게 포스팅 해 주시리라^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 드란 2010.09.03 13:56 Address Modify/Delete Reply

    툴은 vs 를 사용중이니 안부러운데.. 문법강조 색은 좋아보이네요 vs는 그냥 가끔 파랑 녹색 회색 밖에 안보여서 -_-;;
    설정하자니 귀찮고... 구글 어딘가.. 저 색들을 vs에 마춰서 올려줄것도 같은데.. 구글링도 귀찮고 ㅜㅜ;;;

YouTube 로 보기








Daum 의 TV 팟으로 보기


Posted by 땡초 POWERUMC

댓글을 달아 주세요

이 포스트도 예전에 3월 달에 써놓기만 해놨다가 이제서야 Publishing 하게 되었습니다. 워낙 구석 구석 써놓고 관리를 하지 않다 보니 뭐가 어디에 있는지 모르겠네요 ㅡㅡㅋ;

   

웹 테스트 중 Favicon 다운로드로 인한 문제

   

Visual Studio 의 웹 테스트 또는 Fiddler 등을 이용하여 테스트 중에 Internet Explorer 7 에서 문제가 발생하였습니다. 크리티컬한 문제는 아니었습니다만, 테스트 중에 불필요한 Favicon 다운로드가 너무 빈번하게 발생하였습니다.

이런 문제는 실제 테스트에서 오류로 작용하지는 않지만, 성능 관련 테스트나 시나리오가 있는 테스트에서는 의도하지 않는 결과가 나올 수 있기 때문에 올바른 테스트라고 보기가 어렵습니다.

웹 테스트로 Favicon 의 빈번한 다운로드 문제가 발생하여 Fiddler 로 캡처해본 화면 입니다.

   

[그림1] 엄청난 Favicon 을 다운로드하여 testing 을 방해한다

   

문제 해결 방법

Internet Explorer 7 에서의 해결 방법
http://blogs.msdn.com/jeffdav/archive/2007/03/01/why-doesn-t-the-favicon-for-my-site-appear-in-ie7.aspx

FireFox 에서의 해결 방법
http://www.howtogeek.com/howto/internet/firefox/quick-tip-disable-favicons-in-firefox/

Posted by 땡초 POWERUMC

댓글을 달아 주세요



들어가기 앞서…
 
ASP.NET 을 책을 통해 입문하게 되면, 처음 접하게 되는 것이 바로 서버 컨트롤 입니다. 그리고 MSDN 에서도 서버 컨트롤을 남용하면 웹 사이트의 성능을 저하시킬 수 있다고 말합니다. 이러한 서버 컨트롤을 사용하여 개발하는 방법을 ASP.NET 의 서버 모델이라고 합니다. ASP.NET 의 서버 모델은 웹 개발에 있어서 정말 편리하고 복잡한 처리를 단순화 시킵니다.
 
우리가 ASP.NET 을 처음 입문하면 포스트백(Postback) 이라는 용어를 듣습니다. 왜 기존의 서밋(Submit) 이라는 용어를 쓰지 않고, 독자적인 포스트 백(Postback) 이라는 용어를 사용할까요? 궁금하지 않으십니까?
 
ASP.NET 개발자들은 왜 서버 컨트롤이 웹 사이트의 성능을 저하시키는지 잘 알고 있는 사람은 드문 것 같습니다. ASP.NET 의 서버 컨트롤을 사용하는 서버 모델은 ASP.NET 의 성능을 저하시킵니다. 왜일까요?

 
ASP.NET 서버 모델이란?
ASP.NET 의 form 에 runat=”server” 를 사용하는 단일 Form 개발 방법입니다. 단일 Form 개발 방법은 서버 컨트롤을 사용할 수 있게 하며, 이러한 컨트롤에게 자동적으로 상태 유지 기능을 제공합니다.
 
HTML Form 모델이란?
ASP.NET, ASP, PHP, JSP 과 같이 다중 Form 을 이용하여 개발하는 기본적인 웹 개발 방법입니다.
 
MS MVC Framework != HTML Form 모델
HTML Form 개발 방법을 MS MVC Framework 과 동일시 하는 경우가 있는데, HTML Form 과 MS MVC Framework( 또는 MVC) 는 전혀 관련이 없습니다. 서버 모델에서도 MS MVC Framework (또는 MVC) 를 적용할 수 있으며, 윈폼 등 다양하게 적용 가능 합니다.
 
 
서버 컨트롤이 왜 느리죠?
 
서버 컨트롤은 ASP.NET 의 이벤트 기반의 프로그래밍을 가능하도록 하기 위해 독자적인 이벤트를 제공하고, 별도의 랜더(Render) 프로세스를 가집니다. 즉, 서버 컨트롤이 화면에 표시되기 위해 Render 메서드를 재정의(Override) 하여, 화면에 표시되는 HTML 을 생성합니다. 단순한 Label 컨트롤 마져 HTML Span 으로 랜더링되고, 많이 사용하는 그리드 관련 컨트롤은 table 태그를 사용하여 랜더링 합니다.
단순히 HTML Form 모델이라면 바로 스트림에 쓴 후 클라이언트에게 전달할 수 있지만, 서버 컨트롤은 이 과정에서 개별 컨트롤을 랜더링을 하게 됩니다.
 

[그림1] 서버 모델의 랜더링 과정
 
이 랜더링 하는 과정이 새발의 피보다 적은 시간이지만 웹 서버는 결코 혼자 쓰는 서버가 아니라는 점을 명심하세요.
 
이것은 서버 컨트롤을 사용하는 서버 모델의 근본적인 원인이 되어 추후에도 지속적으로 문제가 발생하게 됩니다.
 
 
서버 컨트롤은 적절하게 사용하면 되지 않나요?
 
ASP.NET 서버 모델에서 사용하는 환경에서 적절하게 사용한다는 판단은 팀 개발 환경에서 무척이나 주관적입니다. 이러한 판단은 개발자 주관에 맡길 수 밖에 없으며, 반드시 판단의 기준을 지키리라는 보장을 할 수 없습니다. 더 중요한 것은 적절하게 사용하는게 중요한 것이 아닙니다.
 
서버 컨트롤은 화면에서 사용한 개수도 중요하지만, 서버 컨트롤이 갖는 데이터가 어떤 것인지도 중요합니다. 단 하나의 서버 컨트롤만 사용하더라도 많은 양의 뷰 스테이트(ViewState) 를 갖게 된다면 더 이상 서버 컨트롤의 개수는 중요하지 않습니다.
 
 
뷰 스테이트(ViewState) 의 양이 많으면 왜 느리죠?
 
ASP.NET 의 서버 컨트롤은 상태 유지를 위해 ViewState 를 생성합니다. 뷰 스테이트는 HTML 로 랜더링될 때 히든 필드(Hidden Field) 에 그 값을 저장하고 클라이언트로 보냅니다.
서버 컨트롤을 랜더링 하고 또 상태 유지를 위해 추가적인 개별 컨트롤에 대해 객체 직렬화 과정을 거치게 됩니다.
 

[그림2] 상태 유지를 위한 뷰 스테이트(ViewState)
 
이러한 직렬화 과정이 소량의 데이터일 때 빠르다고 하더라도 데이터의 종류와 양에 따라 수십에서 수백 밀리 세컨드(Milliseconds) 가 느려집니다. 그리고 다시 한번 강조하지만 웹 서버는 혼자 쓰는 서버가 아니라는 점을 생각하면 이 과정이 누적되면 결코 짧은 시간이라고 장담할 수 없습니다.
 
 
컨트롤의 EnabledViewState 를 사용하지 않으면 되지 않나요?
 
특히 그리드 관련 컨트롤은 엄청난 양의 뷰 스테이트(ViewState) 를 생성합니다. 그리고 그리드안에 하위 컨트롤이 추가적으로 들어가있다면 거의 쥐약이나 다름없습니다. 그러므로 컨트롤에 대해 EnabledViewState 를 False 로 설정함으로써 ViewState 을 생성하지 않도록 지정할 수 있습니다.
 
하지만 이것은 근본적인 해결책이 될 수 없습니다. 그리드 컨트롤이 생성하는(기타 서버 컨트롤) HTML 은 컨트롤의 Render 메서드를 통해 HTML 코드를 생성한다고 하였습니다. 만약 tr, td 태그를 한 줄에 배치함으로써 네트워크 트래픽을 최소화 할 수 있지만 서버 컨트롤을 사용하면 이러한 HTML 코드를 직접적으로 제어할 수 없게 됩니다.
 

[그림3] 서버 컨트롤의 랜더링 코드를 제어할 수 없음
 
그리고 EnabledViewState 를 수동적으로 임의로 수정하게 되면 개발의 복잡성이 증가하고 유지 보수성이 저하됩니다. EnabledViewState 속성을 False 로 설정하면 더 이상 상태 유지 기능을 사용할 수 없기 때문에, 코드 비하인드의 로직 마저 수정되어야 합니다. 이러한 문제로 지속적인 성능 개선을 위해 여러 컨트롤에 거쳐 EnabledViewState 를 수정하게 된다면 개발의 복잡성과 유지 보수성 저하와 더불어 추가적인 리소스가 소요됩니다.
 
 
그럼 생산성을 포기하나요?
 
ASP.NET 은 이러한 상태 유지를 자동으로 처리해 줍니다. 그리고 서버 컨트롤의 이벤트 등을 사용하여 보다 빠른 생산성을 보장할 수 있다고 합니다.
 
정말일까요? 단지 이러한 이유 때문에 생산성이 향상됨을 느끼시나요?
 
서버 컨트롤의 그리드를 예로 들게 되면
 
1.     추가적인 디자인 작업이 소요됩니다.
디자이너에 의해 작업된 디자인 HTML 은 다시 한번 서버 컨트롤로 변환되어야 합니다. 차라리 디자이너에게 ASP.NET 의 서버 컨트롤 사용 방법을 알려주는 것이 편할 때도 있고, 실제로 이렇게 하기도 합니다. 하지만 디자이너에게 서버 컨트롤을 강요할 의무가 없으며, 디자이너가 서버 컨트롤을 사용하게 되면 디자이너의 원하는 디자인 작업이 힘들어 집니다.
 
특히 그리드 관련 컨트롤은 디자인된 HTML 을 그리드 관련 컨트롤로 옮기기 위해 더 머리가 아픕니다. 그리드 컨트롤이 개별적으로 랜더링 하기 때문에 1px 이 오차 나거나 디자이너가 원하는 디자인이 아닌 경우가 허다합니다.
 
2.     빌드 하기 전에 오류를 알아낼 수 없습니다.
랜더링 되는 그리드의 결과물이 조건에 따라 변경되어야 한다면, 대부분 그리드의 이벤트를 연결하여 작업합니다. 그리드에 랜더링 되는 상태 데이터를 가져오기 위해 추가적인 코드가 필요합니다.
그리고 이러한 방법은 코드를 다시 빌드하기 전에는 오류의 원인을 알 수 없기 때문에 추가적인 빌드 작업이 필요합니다.
이러한 빌드 작업은 웹 프로젝트의 어셈블리가 변경이 되며 IIS 를 리스타트 하도록 하여 웹 프로젝트 어셈블리가 다시 메모리에 적재됩니다. In-proc 세션을 사용하는 경우라면 세션마저 끊겨져 버립니다.
 
ASP.NET 의 서버 컨트롤 생산성 향상은 단편적이고 제한적인 경우에만 체감적으로 느낄 수 있으며, 상태 유지 또한 HTML Form 에서 그리 복잡한 작업은 아닙니다.
 
아래의 링크에 HTML Form 모델에서의 상태 관리 방법에 대한 글을 보시기 바랍니다.
 
 
그럼 성능 개선 방법은 없나요?
 
있습니다. 웹 사이트 최적화 기법을 통해 사용자의 최종 응답 속도를 향상시킬 수 있습니다. 만약 현재 운영하는 사이트의 성능이 문제가 된다면 다양한 튜닝 포인트를 통해 사용자의 응답 속도를 향상시킬 수 있습니다. 실제 이러한 개선 방안은 많은 서비스 또는 포털이나 도메인(Domain) 에서도 즐겨 사용하는 방법입니다.
 
하지만 이러한 방법은 서버 모델을 최적화하는 관점으로서 HTML Form 모델과 다시 비교하게 되면 더 나은 성능을 보장할 수 없고 근본적인 ASP.NET 의 성능과는 무관합니다.
 

[그림4] ASP.NET 서버 모델의 최적화 한계
 
이러한 최적화 기법을 통해 기존의 성능을 향상시킬 수 있지만, ASP.NET 의 성능 문제는 여전히 해결할 수 없습니다.
 
 
응답 속도가 향상 되었는데 또 뭐가 문제죠?
 
ASP.NET 의 서버 컨트롤은 사용의 편의성과 함께 자동적으로 상태 유지할 수 있는 크나큰 장점이 있습니다. 이러한 문제는 결국 뷰 스테이트(ViewState) 문제이고, 최적화 기법을 통해 기존 성능을 향상할 수 있습니다.
 
하지만 ASP.NET 의 상태 유지는 굉장히 위험한 요소를 가지고 있습니다. 이것은 ASP.NET 의 서버 모델은 단일 Form 밖에 사용할 수 없기 때문에 나타나는 현상입니다. 즉, 포스트 백(Postback) 이 원래 상태로 돌린다는 의미로써 이런 포스트 백(Postback) 처리를 하기 위해 상상할 수 없는 만행을 ASP.NET 이 저지르고 있습니다. 

ASP.NET 의 서버 모델과 HTML Form 모델의 랜더링된 HTML 코드는 상이하게 다릅니다.
 

[그림5] 서버 모델과 HTML Form 모델의 HTML 코드 비교
 
 
자! 뭐가 문제인 것 같나요?
 
서버 모델은 포스트 백(Postback)이 발생할 때마다 form 내에 존재하는 모든 요소를 다시 서버로 전송합니다. 즉, ViewState 가 전송되고 다양한 HTML 태그의 name 속성이 설정된 모든 요소들이 서버로 전송됩니다. ( 대부분의 서버 컨트롤의 명령이 처리되는 컨트롤은 name 속성이 포함됩니다 )
 
즉, 화면의 변경 전의 상태를 ViewState 에 기록하고, 변경 내용을 처리하기 위해 name 속성이 들어간 요소를 전송합니다. 즉, 변경 전, 변경 후 처리를 위해 엄청난 양의 데이터를 서버로 POST 로 전송합니다. 그리고 이러한 ViewState 를 다시 객체로 변경하기 위해 역직렬화 과정을 거치게 됩니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 고래상어 2016.05.27 09:51 Address Modify/Delete Reply

    우연히 보게 되었고 참으로 흥미롭게 읽었습니다.^^
    ASP.NET 개발자인데 부정적인 내용이 많아서 나름의 의견을 적어보았습니다.

    ASP.NET의 패러다임은 웹개발을 CS처럼 하는 것입니다.
    이 편리함이라는 장점을 위해 서버 및 네트웍 자원을 더 많이 사용해야 하는 단점이 있습니다.
    이는 아담의 갈비뼈로 이브를 얻은 것에 비유하고 싶습니다.

    만일 성능이나 트래픽 때문에 ASP.NET이 문제라면 그 기능을 안쓸 수도 있습니다.
    서버태그와 뷰스테이트를 배제하고 기존 ASP나 java servlet과 유사한 구조로 개발하는 것이죠.
    물론 이렇게 해도 java servlet이 성능면에서 더 좋긴 합니다만 넘어가도 될 수준일 듯 하네요.

    결론적으로 ASP.NET 구조는 실패작이 아니라고 말하고 싶습니다.
    편의성과 신속한 개발을 원한다면 ASP.NET을, 성능이 중요한 대규모 사이트 개발이라면 java를 선택하면 것 같습니다.

  2. Pluginn 2018.01.11 16:28 Address Modify/Delete Reply

    잘읽었습니다. 저는 오히려 공감합니다.

    닷넷이 첨나오고 열정적을 공부했던사람으로서,,,

    말씀대로 서버모델 HTML모델, viewstate 등 사용가능하며, 선택 또한 가능합니다..

    문제는.... MS 가 첨부터 서버모델 방식을 너무 지향했다는거죠,
    기존에 HTML 모델 방식보다 닷넷의 서버모델을 따라라...

    HTML 모델방식에 익숙한 개발자로써는, 새로울수도있지만 , 상당히 불편했쬬,,

    또 한 윗글대로 좋을께 하나도 없습니다.


    서버모델방식이, 개발 생산성에서.. 빠르고 , 쉽고 뭐든 좋타고 떠들던 MS 결국 어떻게 되었나요?

    아니다 싶으니, 그냥 급하게 빨리만들어야하는,, 유저 접근 커넥션이 제한적인,,,,
    그래도 백단 만들기에는 편하다,,
    백단을 모두 서버 컨트롤로 만들기 시작했죠,, 왜? 그냥 서버 컨트롤 넣고 더블클릭해서,,,

    코드 넣으면되니까요.. 그러다보니 디테일하게 화면을 구성하기가 복잡해짐,,
    디테일하게 지원하기위해서는 서버 컨트롤에 무한한 속성을들 버전 올리때마다 MS 는 추가해야겟죠

    아니면 서버컨트롤 + 잡기술로 접목 = 결국 코딩이 지저분해짐
    (이는 웹이 CS 프로그램 처럼 서버 단 기술로만 이루어진게 아니기때문이죠_

    비하인드에서 자바스트립을 출력하기위해 서버단 스파게트 코드? 를 만들게 되고,,,
    클라이언트 단에서는. (물론 화면만 깨지지 않으면 되긴하지만) 소스 보기하면 개판이고,,,

    서버단에서 SCRITP ,CSS 지원하려니 MS도 머리터졌겟죠
    지금 결국 각 파트별로 전문적인 프레임워크(정확히는 프레임워크가 아니죠) 장착해서 쓰는듯 하네요

    MS 는 뭐든, 쉽고 ,편하고 , 좋게 만들려고합니다..
    (나쁘게 말하면 본인들이 만든 테두리안에서 편리함을 맛보면 나갈수 없게..)

    기존에 CS 들은가능했으리라 봅니다,
    하지만 웹은 다르죠 엄청 나게 바뀌는 패러다임들을... 따라가려면 버전업을 1년에 2번은 해야할듯,,,

    업그레이드 하면,, 하위호환은 안되며,
    Jquery 를 능가하는 script 프레임워크 node.js 능가하는 서버스크립 ajax 도 잡아야하고
    flash도 다 넣어야하고,,앱 개발도 가능하고,


    MS 서술대로 쓰면 asp.net 은 실패가 맞고요,,

    .net 에.. 나름 본인이 필요한거 빼고 넣고 해서. 쓰면.. 성공이 맞구요,,


 
서버와 클라이언트는 어떤 과정이 반복되나요?
 
ASP.NET 의 서버 모델은 아래의 그럼처럼 반복적인 추가 작업을 하게 됩니다.

[그림6] 서버 모델 프로세스
 
HTML Form 모델은 여러 개의 Form 의 구간을 두어 단지 필요한 데이터만 서버로 전송합니다.
아래 그림처럼 말이죠.

[그림7] HTML Form 모델 프로세스
 
이러한 뷰 스테이트(ViewState) 는 HTTP 파일 업로드가 되듯이 POST 로 서버로 업로드 됩니다. 즉 이 뷰 스테이트(ViewState) 양이 커지게 되면 web.config 에서 요청 데이터 사이즈의 크기를 조절해 주어야 하는 상황까지 벌어집니다.
 
<httpRuntime maxRequestLength="업로드 사이즈" />
 
그리고 우리나라의 인터넷 인프라가 아무리 발달하였다고 하여도 그것은 전적으로 다운로드 속도입니다. 대부분의 경우는 업로드 속도는 다운로드 속도에 못 미치며, 다운로드 속도의 절반도 못 미치는 경우가 대부분입니다.
 
그렇다고 업로드 속도가 해결된다고 모든 것이 해결되는 것은 아닙니다. 서버의 자원은 한정적입니다. 서버의 직/역직렬화 과정 등은 전송된 데이터의 양 만큼의 메모리 자원을 요구하게 됩니다. 즉, 알게 모르게 웹 서버는 스트레스를 받고 있으며 추가적인 코스트(Cost) 가 발생하기도 합니다.
 
이러한 면에서 HTML Form 모델은 기존 ASP.NET 서버 모델에 비해 하나의 서버에서 수십에서 수백 명의 사용자의 접속을 더 허용할 수 있습니다.
 
 
그럼 ASP 와 다를 바가 없는데요? 차라리 ASP 가 빠르겠네요.
 
ASP 와 ASP.NET 은 내부적으로 전혀 다른 구조입니다. 그리고 ASP.NET 은 ASP 의 인터프리터 방식과 비교할 때 더 나은 성능을 낼 수 있습니다.
 
ASP.NET 은 .NET Framework 과 C#(VB.NET 등) 으로 언어적 측면과 프레임워크가 제공하는 기능으로 생산성의 향상을 기대할 수 있습니다. 그리고 ASP.NET 파이프라인(Pipeline) 의 향상된 아키텍처와 보안적 측면에서 기존 ASP 에 비해 향상된 보안 기능을 제공합니다. 그리고 컴파일 언어 측면에서 성능 향상과 한번 컴파일된 어셈블리는 어셈블리 캐시에 적재되어 인터프리터 언어인 ASP, PHP 등에 비해 월등히 빠른 성능을 기대할 수 있습니다.
 

[그림8] ASP.NET 실행 모델
 
즉, ASP.NET 이 제공하는 인프라는 기존 ASP 등과 비교할 때 보다 향상된 아키텍처와 언어적 측면, 보안적 측면, 성능적 측면 등의 이점을 누릴 수 있습니다.
 
ASP.NET 의 서버 컨트롤을 사용하는 서버 모델은 변칙적인 웹 개발 방법에 불과합니다. 즉, 단일 Form 개발 방법을 통해 서버 컨트롤과 상태 유지의 장점 등으로 개발 생산성의 관점에서 시작되었습니다. ASP.NET 서버 모델의 단일 Form 방식은 성능 자체를 최적화할 방법이 없습니다.
 
즉, ASP.NET 을 사용하는 서버 모델은 HTML Form 모델의 성능을 따라갈 수 없습니다. 서버 컨트롤을 남용하는 특정 사람들에 의해 ASP.NET 이 느리다는 편견이 확산된 것이 안타까울 뿐입니다.
 
 
그럼 서버 컨트롤을 쓰지 않는 것이 결론인가요?
 
반드시 그렇게 하지 않아도 됩니다. ASP.NET 의 서버 모델은 HTML Form 방식의 개발 방법보다 여러 가지 처리에 대한 고민을 보다 단순화 할 수 있습니다. 그렇기 때문에 ASP.NET 을 입문하는데 ASP 에 비해 오히려 난이도가 쉽다고 생각합니다. 그리고 다양한 고객 또는 사용자의 요구 사항을 충족하기 위해서는 3-party 제품을 통해 복잡하고 많은 리소스가 투입되는 작업을 서버 컨트롤 하나로 단순화 시킬 수 있습니다.
 
가끔 이런 사람들을 봅니다.
 
서버 컨트롤 사용 못하게 하는 프로젝트도 있나요? 차라리 ASP 로 개발하자고 하세요”
 
서버 컨트롤은 ASP.NET 의 서버 모델이 제공하는 단지 보너스 정도라고 생각합니다. 서버 컨트롤이 ASP.NET 의 전부이며, 서버 컨트롤을 사용하지 않는 것은 ASP.NET 개발이 아니라고 단언하면 안됩니다. 말했듯이 ASP.NET 의 서버 모델이 기본적인 웹 개발과 비교하면 변칙적인 방법에 불과합니다.
 
ASP.NET 을 서버 모델과 HTML Form 모델로 개발하였을 때, 절대 ASP.NET 서버 모델의 개발 방법은 HTML Form 모델로 개발하는 성능의 꽁무니도 못 따라옵니다. 혹시 이견이 있다면 실무 프로젝트에서 같은 사이트를 양측 모두 적용해 보셨나요? 요즘 이런 개그가 있죠. “안 해보셨으면 말을 하지 마세요!”
 
개발하는 프로젝트의 성격과 사용자는 유저에 따라 두 개발 방식의 적절한 선택이 필요하고 두 모델에 대한 이해가 필요합니다. 그리고 ASP.NET 을 바라보는 올바른 안목이 필요합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 천이백 2015.01.28 19:11 Address Modify/Delete Reply

    구글링하다가 우연히 들어오게 되어서 글을 남깁니다. 이 글을 보고 답변을 다실 지는 모르겠지만
    ASP.NET의 서버 모델은 변칙적인 방법에 불과하다는 생각이 지금도 유효하신 건가요?
    ASP.NET에 대한 평가를 하려면 PHP나 JSP 또는 ASP와 비교를 해야지 html 과 비교하는 것 자체가 제가 보기엔 어불성설인 것 같네요.
    http://www.wrensoft.com/zoom/benchmarks.html
    위의 벤치마크에서도 나와 있지만 asp.net은 성능상에도 다른 서버 프로그래밍과 비교해서 뒤처지지 않는 것으로 나오네요. MS의 많은 천재 개발자들이 편법을 이용해서 프로그래밍 언어를 개발할 리도 없다고 생각하고요.
    그리고 또 한가지 국내 최대 쇼핑몰 중의 하나인 지마켓이나 옥션이 모두 asp.net 기반으로 돌아가는 쇼핑몰입니다. 이런 대형 쇼핑몰에서 아무런 문제없이 사용하고 있는 asp.net이 서버 측 성능상의 문제로 트래픽 때문에 서버가 중지된 적이 있다는 소리는 아직 한번도 안들어 본 것 같습니다만....
    웹 개발을 하는 사람이 옥션이나 지마켓보다 훨씬 더 큰 대규모의 사이트를 개발하고 있다면 모를까,단지 서버측의 부하가 좀 생긴다고 해서 여러 장점을 가진 서버 기술을 사용하지 못할 이유는 전혀 없는 것 같습니다.
    그리고 데이터베이스와 연동하는 서버측 기술도 MS에서 제공하는 것이 데이터가 계속 주고 받아야 하는 서버에 상당히 부담을 주는 연동 기술도 있지만 dataset 과 같이 서버의 자원을 가져온 다음에 연결을 끊어 주는 다양한 기술들이 있는데 이런 것만 적절히 사용해도 현재의 컴퓨터 환경에서는 그리 큰 문제가 될 것이라고는 전혀 생각이 안 듭니다.

    • 땡초 POWERUMC 2015.01.29 12:23 신고 Address Modify/Delete

      내용을 모두 이해하시지 못하신 것 같아 재차 설명을 드립니다.

      네트워크 오버헤드를 설명하기 위해 ASP.NET 이 랜더링하는 HTML 의 양을 설명한 것입니다.

      그리고 ASP.NET 을 사용하는 것은 성능 문제가 아니라, ASP.NET + 서버 컨트롤을 사용한 경우 성능 문제를 야기한다는 것입니다.
      이유는 물론 글에 설명되어 있습니다.

      그리고 옥션과 지마켓이 ASP.NET 웹 개발 프레임워크를 쓰는 것이지, ASP.NET + 서버컨트롤 방식을 사용하지는 않습니다.
      ASP.NET + 웹폼 방식으로 개발하면 기대하는 성능을 얻을 수 있습니다.
      최근 유행하는 ASP.NET MVC 도 웹폼 방식이고요.

외부 라이브러리에서 Javascript 인텔리센스 활성화 하기
 
Visual Studio 에서 추가된 기능입니다. 기존에 html(aspx) 페이지에서 <script src=””> 블록을 통해 Javascript 인텔리센스 기능이 제공이 되었지만, 여전히 문제였던 것은 Javascript 파일을 작성할 때, 외부 Javascript Function 의 인텔리센스 기능이 제공이 되지 않았습니다.
 
하지만, Visual Studio 2008 을 설치하시면 외부 Javascript Function 을 인텔리센스 기능으로 사용하실 수 있습니다.
 
크게 설명 드릴것도 없이 아래의 스크린샷 처럼 <reference> 주석을 통해 외부 Javascript Function 의 인텔리센스를 사용하기 위해 Import 할 수 있습니다.
 
[그림1] Jscript1.js 에 Function 이 선언된 모습
 
[그림2] Jscript2.js 에서 Jscript1.js Function 을 인텔리센스 기능으로 사용하는 모습
 
Reference
 
PS) 위 기능은 Visual Studio 2008 에서 추가된 기능인데, Reference 의 블로거는 Visual Studio SP1 에 추가된 기능인 것처럼 설명하네요. 참고하세요.

Visual Studio 2008 SP1 Adds JavaScript Formatting
http://weblogs.asp.net/kencox/archive/2008/08/13/visual-studio-2008-sp1-adds-javascript-formatting.aspx
 
만족합니다.
하지만, 여기에서 저는 한가지 고민을 하게 되었습니다.
 
 
그럼, Web Resources 스크립트는 어떻게 하나요?
 
이 문제로 약 하루 반나절 정도 생각을 해봤습니다. -_-; 물리적으로 URL 를 통해서 Javascript 파일에 접근할 수 있을 경우 위와 같이 사용할 수 있지만, Web Resources 는 이러한 URL 경로가 없기 때문에 위의 기능을 사용할 수 없습니다. 이 문제에 대해서 구글링을 해봐도 Web Resources 를 외부 Javascript 에서 Import 할 수 있는 방법을 없는 것 같습니다.
 
그래서 결론으로 아래와 같이 사용하시면 됩니다.
 
/// <reference path="C:\Documents and Settings\...경로생략...\JScript1.js" />
 
팁이라면 팁이 되겠네요. Web Resources 의 경우 큰 고민마시고, 파일 경로를 쓰시면 될 것 같습니다.
쩝…

2008-09-03 UPDATE ----------------------------------------------------
아래 댓글 달아주신 남정현님 말씀처럼
/// <reference name="xxx" assembly="xxx"/>

이런 방법이 있었네요^^ 감사합니다.

http://blogs.msdn.com/webdevtools/archive/2007/11/06/jscript-intellisense-a-reference-for-the-reference-tag.aspx 

근데 잘 되지 않는군요;; 쩝^^;

Posted by 땡초 POWERUMC

댓글을 달아 주세요

ASP.NET 용 Virtual Earth Server Controls 가 “Windows Live Tools for Microsoft Visual Studio” 라는 이름으로 Release 되었습니다. 기존에 Virtual Earth 를 사용하기 위해 많은 상당히 많은 Javascript 작업을 노가다(?)를 하였으나, 이제는 그럴 필요가 없어 졌네요.
 
간략하게 주요 기능을 살펴보자면,,
l ToolBox
l Drag & Drop
l Server Sides Event
l Adding Shapes
 
더 갖다 붙이자면 많지만, Server Control 로 포팅되면서 Server Control 이 갖는 모든 기능을 갖추었다고 보시면 됩니다.
 
설치를 하고, 웹 프로젝트를 만들면, 제일 먼저 ToolBox 에 다양한 Server Control 들이 추가 됩니다.

[그림1] Windows Live Tools for Microsoft Visual Studio 설치 후 ToolBox
 
하지만!!아래와 같이 더 이상 진행할 수 없는 지경에 이루게 되었습니다.


[그림2] 웹폼에 Virtual Earth Controls 을 추가할 경우 오류 메시지
 
이건 뭐지? 처음에는 영문판 Visual Studio 에서만 되는줄 알았습니다. 그래서 Preview 를 때려치려고 하였지만, 방법은 있더군요.
 
시도방법이 Assembly 를 추가하여, 코드를 통해 Control 을 웹폼에 얹으려고 하였으나, 작동이 되지 않더군요^^; (뭐.. 코드가 잘못되었겠죠?? ㅡ,.ㅡ)
원래, ToolBox 에 등록된 Server Control 은 Drag & Drop 를 하게되면, 페이지 상단에 <%@ Register … %> 지시어가 자동으로 참조가 추가 되면서 컨트롤이 웹폼에 추가됩니다만,, 코드로 Control 을 추가하려고 강제로 참조를 추가해 주니, 웹폼 디자이너에서 Drag & Drop 이 지원되더군요..
 
결국 직접 참조를 추가한 후에, ToolBox 의 Server Control 을 추가하시면 된다는 말이군요 -_-;
 

[그림3] 직접 사용자가 참조를 추가해 주어야 Drag & Drop 이 가능하다.
 
아무튼, Virtual Earth 관련 Extender 와 Window Live 관련 Controls 이 존재하지만, 직접 돌려보니 Virtual Earth Server Control 을 제외하고는 별로 볼 것이 없더군요.
 
재미있는 것은 Virtual Earth 3D 를 설치하면, 3D View 로 전환도 가능합니다. 아무튼 재미있는 컨트롤이 나오게 되어 잘 구경하다가 갑니다 ^^;
 

Posted by 땡초 POWERUMC

댓글을 달아 주세요



지난번 아티클의 HttpCompression 소스 코드를 공개합니다.
 
아직 개선의 여지는 있지만, 필요하신 분들이 많으신 줄 압니다. 코드를 수정하셔서 사용하셔도 무방하나, 상업적 용도나 재배포가 불가능 하오니, 이점 숙지하시기 바랍니다.
 
실제 적용하기 위해서 Umc.Core.Configuration 어셈블리가 필요하지만 조금 수정하시면 자신의 사이트에 맞게 수정하시면 Umc.Core.Configuration 어셈블리는 필요하지 않습니다. 이 부분에 대해선 문의를 받지 않습니다.
 
현재는 매뉴얼이 제공되지 않습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요




 
3. 문제 해결
 
이전 아티클에서 살펴보았듯이, ASP.NET 에서 보다 효과적인 HTTP Compression 을 위해 WebResource 와 ScriptResource 의 압축의 필요성을 알아보았습니다.
 
그럼 하나하나 해결의 실마리를 풀어 보도록 하겠습니다.
 
3.1 WebResource 압축
 
WebResource 는 포함 리소스로 지정된 파일과 WebResourceAttribute 을 통해 리소스의 콘텐츠를 사용할 수 있습니다.
 
 


 
첫번째, 일반적으로 압축 되지 않은 콘텐츠이기 때문에, 임의로 GZip 알고리즘을 이용하여 압축된 바이너리를 사용하여 Response Header 의 Content-Encoding 을 Gzip 으로 해 주셔도 됩니다. 하지만 불편하겠죠?
 
두번째, 요청 파일명이 WebResource.axd 인지를 검사하여, GZip 압축을 수행할 수 있습니다.
 
세번째, ASP.NET 파이프라인에서 요청에 대한 HttpHandler 타입을 검사하는 방법입니다.
WebResource 는 IHttpHandler를 구현하는 System.Web.Handlers.AssemblyResourceLoader 클래스입니다. 그래서 Context 개체의 CurrentHandler 의 개체 타입을 검사하는 방법으로 WebResource 인지 판단할 수 있습니다.
 
하지만, 문제는 여기서 그치지 않습니다. 만약 리소스가 image/jpeg 라고 가정할 때, 이러한 검사방법으로 압축하였음에도 Content-Encoding 이 text/html 로 내보내지게 됩니다. 이미지가 깨진다는 말이죠.
 
구글링을 통해 알아본 봐, 아래와 같은 코드를 사용하면 됩니다. 대략, HttpHandler 에게 현재 요청의 ASP.NET 파이프라인의 Response 개체를 참조하도록 하여, 포함 리소스의 Content-Type 을 참조되도록 한 코드인 듯 합니다.
 
// 맴버 선언
private static FieldInfo _HttpWriterFieldInfo = typeof(HttpResponse).GetField("_httpWriter", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
 
private static FieldInfo _IgnoreFurtherWritersFieldInfo = typeof(HttpWriter).GetField("_ignoringFurtherWrites", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
 
if (context.CurrentHandler is System.Web.Handlers.AssemblyResourceLoader)
{
           HttpWriter httpWriter = (HttpWriter)_HttpWriterFieldInfo.GetValue(context.Response);
       _IgnoreFurtherWritersFieldInfo.SetValue(httpWriter, false);}
 
위의 코드를 사용하여 WebResource 의 정상적인 Content-Type 내보낼 수 있게 됩니다.
 
 
3.2 ScriptResource 압축
 
ScriptResourceAttribute 은 System.Web.Extensions 어셈블리에 정의되어 있고, 이름에서 알 수 있듯이 는 AJAX.NET 이 참조하는 스크립트 리소스 입니다. ScriptResource 는 WebResource 로 정의된 포함 리소스를 ScriptResource 로 변환하여 줄 수 있습니다.
 
MSDN 예제에 다음과 같이 사용하라고 나와 있습니다.
 
[assembly:System.Web.UI.WebResource("LocalizingScriptResources.CheckAnswer.js", "application/x-javascript")]
[assembly:System.Web.UI.ScriptResource("LocalizingScriptResources.CheckAnswer.js", "LocalizingScriptResources.VerificationResources", "Answer")]
 

 
ScriptResource 는 Context.ApplicationInstance.Modules 컬렉션에서 로드된 HttpModule 을 확인할 수 있습니다.
 
ScriptResource 는 ScriptResourceHandler 를 구현한 Handler 이며, 다음과 같은 코드로 타입을 알 수 있습니다.
 
if (context.CurrentHandler is System.Web.Handlers.ScriptResourceHandler)
{
       // 처리
}
 
하지만, 위 방법은 그다지 권장하지 않습니다. AJAX.NET 을 사용하지 않는 웹 프로젝트도 타입 검사를 위해 System.Web.Extensions 어셈블리를 참조를 한다는 것은 그다지 좋은 방법이 아니기 때문에, Type.GetType() 을 이용하여 타입 검사를 하는 것이 바람직 합니다.
 
ScriptResource 를 압축하기 위해 WebResource 보다 좀 더 이슈가 많은 놈입니다.
 
해결 방법을 보기 앞서, 이러한 리소스를 호출하는 URL 은 참 독특하게 생겼습니다.
 
http://localhost:11762/ScriptResource.axd?d=OPgKDvRlavpQaVqOD0g1boX7qB-1ghFWxrumbN3vsX9V6HIuwC8ttnL5kS-GN-I8lyEsM4Cv4jlmkKjiWk5FpbGKpocj2jsQpab1931xYKi73VoRqj6NfhWnGtvW1Qk00&t=633419587306805934
 
위와 같이, QueryString 의 d 라는 키값이 가지는 알 수 없는 문자들이 덕지덕지 붙어 있습니다. 이 문자열은 암호화되어 인코딩된 문자입니다. 이 문자열은 System.Web.Page 클래스의 EncryptString 과 DecryptString 이라는 internal 로 선언된 정적 메서드를 통해 암복호화를 수행합니다. 그리고 암복호화에 사용되는 토큰키는 HttpHandler 에 PublicKeyToken 에 정의되어 있습니다.
 
위의 d 쿼리스트링을 복호화 해보면
 
ZSystem.Web.Extensions,3.5.0.0,,31bf3856ad364e35|MicrosoftAjaxWebForms.debug.js|ko
 
이러한 알아봄직한 단어들이 나옵니다. 바로 맨 앞의 Z 로 ScriptResource 가 GZip 압축 되었다는 것을 의미합니다. a u 는 압축이 되지 않았다는 것을 알려주기도 합니다.
 
그리고 t 쿼리스트링은 어셈블리의 DateTime 의 Tick 입니다. 캐시에 동작하기 위해 어셈블리의 날짜를 URI 에 포함됩니다.
 
그럼 어떻게 압축 여부를 판단하는지 알았습니다. ScriptResource 의 압축 여부를 판단하기 위해 다음과 같은 코드를 만들 수 있습니다.
 
string param = context.Request.QueryString["d"];
string decrypt      = HttpUtil.DecryptString(param);
if( decrypt.ToUpper().StartsWith("Z") )
       return;
 
코드는 쿼리스트링의 d 값을 PublicKeyToken 을 이용하여 복호화하여 Z 로 시작하면 이미 압축된 콘텐츠 이므로, 압축을 수행하지 않도록 return 하는 코드입니다.
 
만약 위의 코드로 ScriptResource 의 이미 압축었는지의 여부를 체크하지 않으면, 서버는 압축된 콘텐츠를 다시 한번 GZip 압축하기 때문에, 브라우져는 GZip 압축을 해제하였지만 콘텐츠는 깨져버립니다. ( 두 번 압축하였으니, 두 번 풀어줘야 정상적인 콘텐츠가 되겠죠? )
 
 
4. 웹 사이트에 진정한 날개를…
 
자신이 개발하거나 운영하고 있는 웹 사이트가 있고, AJAX.NET 이나 다양한 컴포넌트를 이용하였다면 반드시 웹 캡춰 툴을 이용하여 확인해 보시기 바랍니다. 그리고, 자신이 그러한 웹 사이트를 개발하거나 관리한다면 위의 방법을 이용하여 적용해 보시기 바랍니다. text/html 이나 text/javascript 와 더불어 트래픽의 부하를 가져오는 다량의 WebResource 와 ScriptResource 가 가벼워지면서 획기적으로 줄어든 트래픽을 확인할 수 있을 것입니다.
 
그리고, 직접 개발하기 벅차신 분을 위해 개발중인 Umc.Core.Web.HttpCompression 어셈블리를 함께 드리도록 하겠습니다. 전체적으로 개발이 완료되지 않았으므로 테스트 용도로만 사용시면 됩니다. (어떠한 버그도 책임지지 않는답니다^^;)
 
아래의 내용을 각각 맞는 Config Section 에 추가해서 넣으시면 동작합니다. 그럼 오늘도 좋은 하루 되세요 …
 
<configSections>
       <sectionGroup name="Umc.Core" type="Umc.Core.Configuration.UmcConfigSectionGroup, Umc.Core.Configuration">
             <section name="Umc.Core.Web" type="Umc.Core.Configuration.UmcWebConfigSection, Umc.Core.Configuration" />
             <section name="Setting" type="Umc.Core.Configuration.UmcSettingConfigSection, Umc.Core.Configuration" />
       </sectionGroup>
</configSections>
 
<system.web>
       <httpModules>
             <!-- HttpModule 매핑-->
             <!--<add name="UmcHttpModule" type="Umc.Core.Web.UmcHttpModule, Umc.Core.Web" />-->
             <add name="UmcHttoCompressionModule" type="Umc.Core.Web.HttpCompression.HttpCompressionModule, Umc.Core.Web.HttpCompression" />
       </httpModules>
</system.web>
 
<Umc.Core>
       <!-- DefaultExtension 웹폼이사용하는기본확장자입니다.-->
       <Umc.Core.Web DefaultExtension=".aspx">
             <RewritePath Enabled="True" /> <!--웹사이트의 rewritepath 적용할지여부-->
             <HttpCompressionFile>
                    <add Name="/\.(gif|jpg|jpeg|png)$/i" Type="GZip" Enabled="False"  NameType="RegexExpression"></add>
             </HttpCompressionFile>
             <HttpCompressionMime>
                    <!--디폴트속성들입니다-->
                    <add Name="text/html" Type="GZip" MinimumLength="512" Enabled="True"/>
                    <add Name="text/css"/>
                    <add Name="text/javascript"/>
                    <add Name="application/x-javascript"/>
                    <add Name="image/bmp"/>
             </HttpCompressionMime>
       </Umc.Core.Web>
</Umc.Core>
 
 
참고 URL
 
Posted by 땡초 POWERUMC

댓글을 달아 주세요



 
 
1.    서론
 
HTTP Compression 은 웹사이트의 응답 성능을 향상 시키는데 많은 일조를 합니다. 압축 정도와 데이터의 타입에 따라 압축율은 다르지만, 최소 30% 이상의 체감 속도의 향상을 가져온다고 합니다. 제가 운영하고 있는 [Umc Projects/Umc Blog] - [UmcBlog] 블로그 소스 다운로드 의 메인화면의 HTML 만해도 101,430 Bytes 지만, GZip 압축을 적용한 결과 15,450 Bytes 로 7배 정도로 작아진 트래픽이 발생합니다.
 

[그림1] Umc Blog 메인 화면을 HTTP 압축한 비교표
 
위 압축은 ShartZipLib 를 이용하여 최고 압축율로 압축한 결과 입니다.
자~ 어떻습니까? 이제 HTTP 압축을 자신의 사이트에 도입해 보려고 한다면, 우선 다음의 강좌를 참고하여 선수 지식을 익히시기 바랍니다.
 
최고의 가이드 문서인 유경상님의 HTTP 압축 (1) : 성능 향상을 위한 다른 접근 기법
서동진님의 [1000원짜리] GZip 이용한 웹 페이지의 압축 전달
 
제가 아는 포스팅은 이것 뿐인지, 아니면 제가 못 찾는 것인지 모르겠지만, 어쨌든 왜 써야 하며, 어떻게 구현하는지는 보셔야 다음 내용을 이해할 수 있습니다.
 
 
2.    문제 제기
 
위 내용 중 특히 유경상님의 문서에서 볼 수 있듯이 HTML 과 XML Web Service 에서 압축방법과 압축해제 방법을 너무나 잘 설명해 주셨습니다. (쵝오!) .NET Framework 가 버전업이 되면서 편리한 API 와 옵션들이 추가되어 깊은 이해보다 코드 한 줄로 해결할 수 있는 방법들이 너무나 다양해 졌습니다.
 
좋습니다. 어찌되어건, HTTP Compression 은 서버의 CPU 가 가져가는 부하가 경미하기 때문에 보다 훨씬 많은 이점이 있습니다. 그렇기 때문에, 웹 사이트는 특별한 상황이 아니라면 HTTP Compression 을 활용하도록 해야 합니다.
 
IIS HTTP Compression 을 사용하지 말아야 할 때
IIS 서비스 압축은 기본적으로 DLL 도 GZip 압축 하도록 되어있습니다. 스마트클라이언트 시나리오에서는 클라이언트가 GZip 압축된 어셈블리(*.dll) 등을 다운로드 하였을 때 다운로드 된 클라이언트는 GZip 압축을 복호화 하지 못합니다. 유경상님의 HTTP Compression (III) : IIS Support 을 참고 하세요.
 
자.. 문제는 여기서 부터입니다. HTTP Compression 의 구현은 쉽지만, HTML(CSS/JS) 이나 XML Web Service 에 국한된 포스팅 입니다. 특히, 클라이언트 어플케이션일 경우 의 GZip 압축의 범위가 XML Web Service 에 국한됩니다. 하지만, 불특정 다수의 웹 서비스 사이트를 생각한다면 HTML Compression 만으로 부족한 것을 알 수 있습니다.
 

[그림2] HTML 뿐만 아니라 다양한 데이터를 클라이언트는 내려받습니다 (클릭하면 확대 됩니다)
 
우리가 웹 사이트를 접속하였을 때, 보여지는 것은 HTML/CSS/JS 만 있는 것이 아닙니다. 수십 개의 콘텐츠 중 고작, 10여개의 텍스트 용량을 줄였다고 체감속도가 향상 되었다는 것은 억지에 불과합니다.(그나마 안하는 것보다는 나은듯^^;) 왜냐하면, 웹 사이트를 접속할 때 XML, BMP 등과 같은 압축되지 않은 다양한 콘텐츠도 다운로드 되기 때문 입니다.
 
물론, HTTP Compression 을 하느냐 안하느냐도 중요합니다. 하지만 압축이 전부는 아닙니다. 자신이 개발하거나 관리하는 사이트가 이런 문제로 고민을 한다면 다양한 웹 사이트 최적화 기법을 통해서 빠른 응답을 기대할 수 있습니다.
 
웹 사이트 최적화 튜닝 방법
 
ASP.NET 개발 환경을 무척 편리해 졌습니다. .NET Framework 2.0 부터 추가된 WebResource 와 ScriptResource 를 이용하여 컴포넌트 배포시에 별도의 스크립트 파일이 없이도 동작하도록 어셈블리의 리소스에 포함시킬 수 있게 되었습니다. 무척 배포가 쉬워졌지요.
 
하지만, ASP.NET 웹사이트로 구축된 기업의 인트라넷의 경우 다양한 컴포넌트를 사용하여 개발하게 될 때, 수십여 개의 WebResource 와 ScriptResource 를 뱉어내게 됩니다. 이 리소스들은 압축되었다는 보장을 할 수 없고, 실제로 압축되지 않은 리소스들이 더 많습니다. 이런 웹 사이트의 성능 저하 주 원인이 바로 리소스입니다.
 
문제는 여기에서 생깁니다. 어떻게 이 리소스들을 압축하시겠습니까?
AJAX.NET 의 ScriptManager 컨트롤은 3개의 ScriptResource 를 포함합니다. ScriptResource 는 아무런 작업을 하지 않아도 gzip 압축이 되는데, 특정 컴포넌트의 ScriptResource 는 gzip 압축을 하지 않습니다.
 

[그림3] 아무 작업 없이도 ScriptResource 는 압축이 되기도 합니다.
 
특히 ScriptResource 의 경우는 아무런 생각 없이 압축을 수행하다가는 이미 압축된 리소스가 추가적으로 GZip 압축이 되어, 브라우져는 중복 압축된 콘텐츠를 제대로 복호화 하지 못합니다. 결국 사이트는 바보가 됩니다.
 
Next… (다음 아티클)
Posted by 땡초 POWERUMC

댓글을 달아 주세요



[.NET/ASP.NET] - 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성
[.NET/ASP.NET] - 실전 ASP.NET Session [2] - 상태관리의 종류
[.NET/ASP.NET] - 실전 ASP.NET Session [3] - 다양한 세션 관리 방법
[.NET/ASP.NET] - 실전 ASP.NET Session [4] - 세션상태 마이그레이션

 

 

제목에는 세션상태 마이그레이션 이라고 했지만, 보다 구체적으로 언급하면 세션 공급자를 구현하는 단원입니다. 이전에 보았던 아래의 그림과 같이 ASP.NET 이 제공하는 몇 가지의 세션상태 저장소가 있지만, 상황에 따라서 사용할 수 없는 경우도 생길 수 가 있습니다. .NET Framework 3가지의 세션 공급자를 제공해 주지만 어떠한 경우는 이 3가지 모두 쓸 수 없기 때문입니다.

 

[그림1] ASP.NET 이 제공하는 기본적인 세션 공급자

 

만약, ASP.NET 프로젝트가 MS-SQL 데이터베이스 기반으로 구축이 된다면 SQL Server 를 이용한 세션 관리가 가능하지만, Oracle 데이터베이스 기반일 경우 .NET Framework Oracle Session Provider 를 기본으로 제공하지 않기 때문에 세션관리에 이슈가 있다면 프로젝트 착수 단계부터 개발 플랫폼의 선택의 기회에 제외될 수 있기도 합니다. 가령, Oracle / JSP ASP 베이스의 시스템을 닷넷으로 전환하고자 한다면, 세션 서버 구축 때문에 비싼 비용을 지불하여 MS-SQL 을 구입할 수 도 없는 노릇이지요. 또한, 세션에 추가 정보나 필드 등이 추가 되어야 할 경우 기존 상태 저장소는 사용할 수 없게 되기 때문에, 새로운 방안을 모색해야 할 것입니다.

 

ASP.NET 은 이러한 다양한 상태 공급자를 구현할 수 있도록 SessionStateStoreProviderBase 인 추상 클래스를 제공하고 있습니다. 이 클래스는 System.Web.SessionState 네임스페이스에 존재합니다. 우선 이 클래스와 상속 구현을 위해 아래의 MSDN 문서를 참고하시기 바랍니다.

 

세션 상태 저장소 공급자 구현

 

그리고 Access 데이터베이스를 이용한 세션 상태 공급자의 소스를 구현한 MSDN 소스를 참고하시기 바랍니다.

 

법: 샘플 세션 상태 저장소 공급자

 

소스코드가 복잡하지 않기 때문에, 적절한 다른 종류의 데이터베이스로의 전환은 쉽게 하실 수 있으리라 생각합니다.

 

우리가 직접 세션 공급자(Session Provider) 를 구현한다는 것은 많은 의미를 내포할 수 있습니다. 그 중, 가장 의미 있는 것은 이 Custom Session Provider 를 구현함으로써 개발자나 구축하는 프로젝트는 아무런 코드의 수정 없이 데이터베이스 플랫폼의 전환이 가능하다는 것입니다. 단지, web.config 에서 Session Provider 만 지정해주면 됩니다.

 

 

위의 첨부파일은 MSDN 예제의 Access Database Session 을 저장하는 예제인데, MSSQL Database 로 변경한 소스입니다.

web.config 와 테이블의 내용을 보면 다음과 같습니다.

 

[그림2] Custom Session Provider web.config 에 설정

 

[그림3] DB 테이블에 Custom Sessino Provider 가 세션을 저장한 결과

 

위의 web.config connectionString 에 적절한 id password 를 넣어주는 센스만 보여주신다면, 무리 없이 바로 샘플은 동작할 겁니다. ( Database Table 만드는 스크립트는 코드의 주석에 포함되어 있습니다)

 

 

처음 저의 의도와 달리 포스팅을 점점 날로 먹으려고 하는 것 같네요. 원래 이번 포스팅부터 많은 내용을 익혀서 전달해 드리려고 했는데 요즘 Umc.Core 에 올인하고 있기 때문에 포스팅을 성의 있게 쓰기에 시간이 턱없이 부족하네요. 이렇게 올인해도 집에 와서 코딩하면 20 라인 만들기도 정말 벅차답니다. 만들면서 잘못된 설계 때문에 몇 번이나 엎었는지 ^^; “세션 분산처리도 포스팅 최종회에 함께 포함하도록 합니다.

 

다음 포스팅에 실제 SSO 시스템을 적용한 예제도 준비하려고 했지만, 그렇게 하지 못할 것 같아요. 하지만, Custom Session Provider SSO 시스템에 대한 큰 그림과 세부적인 구현방법은 최대한 자세히 기술할 예정이니, 관심 있는 분은 좋은 팁 배워간다 생각하시고 보시면 될겁니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요



[.NET/ASP.NET] - 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성
[.NET/ASP.NET] - 실전 ASP.NET Session [2] - 상태관리의 종류
[.NET/ASP.NET] - 실전 ASP.NET Session [3] - 다양한 세션 관리 방법
[.NET/ASP.NET] - 실전 ASP.NET Session [4] - 세션상태 마이그레이션

 

 

ASP.NET 은 다양한 세션 관리 방법을 제공하여 줍니다. 서버의 자원은 제한적이기 때문에 In-of-process 방식이 아닌, Out-of-process 의 세션 관리 방법이 필요하다고 이전 시간에 말한바 있습니다. 이런 이유 이외에도, Worker Process 에 의해 세션이 관리된다면 프로세서가 어떤 오류로 인해 종료가 되면 세션도 함께 증발해 버리는 경우도 생깁니다. 이유가 가져다 대면 많지만, 어떤 세션 관리 방법이 있는지 알아보고, 자신의 사이트나 회사의 사이트에 어떻게 적용할 것인지 한번 생각해 봐도 좋을 내용이 될 것입니다.

 

1.    ASP.NET Session State Service

 

ASP.NET Session State Service 라는 서비스가 별도로 존재합니다. 이 서비스는 관리도구->서비스를 통해 프로세서를 시작/종료 할 수 있고, 디폴트로 시작 안함입니다. 이 프로세서는 ASP.NET Worker Process 와는 별도의 프로세서이기 때문에, IIS 가 중단이 되거나 오동작으로 인해 세션이 증발하는 경우는 없습니다.

 

 [그림1] 서비스의 ASP.NET Session State Service

 

위의 [그림1] 에서 시작버튼을 누르게 되면 ASP.NET Session State Service 를 시작할 수 있습니다.

 

우선 여기서, 주의할 부분이 있습니다. ASP.NET Session State Service 를 사용하기 위해서는 processModel 섹션의 webGarden 속성은 반드시 false 이여야 합니다. 갑자기 튀어나온, webGarden 속성은 또 뭐죠?? 이 속성은 다중 프로세서 CPU 에만 적용되는 항목인데 다중 프로세서에서 Worker Process 를 사용할 코어(Core)의 선호도를 지정할 수 있습니다. 만약, ASP.NET Session State Service processModel webGarden 을 함께 설정한다면, 가령 A 라는 세션을 다른 Worker Process 에서 처리를 하는 교착현상(?)이 발생할 수 있습니다.

 

processModel webGarden 참고

<processModel> 구성 문서에 틀린 webGarden 설명과 필드가 포함되어 있다

 

 

webGarden 의 속성을 임의로 바꾸고자 한다면, web.config 에서는 바꿀 수 없습니다. 왜냐하면, machine.config

 

<section name="processModel" type="System.Web.Configuration.ProcessModelSection, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineOnly" allowLocation="false"/>

 

allowDefinition="MachineOnly" 로 설정되어 있습니다. 이 값을 allowDefinition="MachineToApplication" 으로 변경하면, 웹 응용 프로그램의 web.config 에서 processModel 섹션을 재정의 할 수 있습니다.

 

다시 원점으로 돌아와서, 세선 관리를 ASP.NET Session State Service 로 지정하는 방법은 굉장히 간단합니다.

다음과 같이 web.config 를 변경하면, 세션 상태 관리를 ASP.NET Session State Service 로 지정할 수 있습니다.

 

<system.web>

       <sessionState mode="StateServer"

                      stateConnectionString="tcpip=localhost:42424">

</sessionState>

 

tcpip address IP 도 가능하며, 도메인으로도 가능합니다. 그리고 뒤의 42424 는 디폴트로 지정된 ASP.NET Session State Service Port 입니다. 만약, 로컬 서버가 아닌 원격 서버의 ASP.NET Session State Service 를 사용하기 위해서는 방화벽의 42424 포트를 허용해 주시면 됩니다.

 

ASP.NET Session State Service 가 디폴트로 사용하는 42424 포트를 변경해 줄 필요도 생길 수 있습니다. 포트를 변경해 주는 UI 는 제공되지 않지만, 레지스트리를 변경하여 포트 번호를 바꿀 수 있습니다.

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters

 

Port= a5b8 (42424)

 

Port 의 값을 16진수로 대응되는 값을 변경하시고, 반드시 ASP.NET Session State Service 재시작 하시면 변경된 포트를 통해 Service 를 이용할 수 있습니다.

 

간혹, ASP.NET Session State Service 를 시작하였음에도 동작하지 않을 경우, 위의 레지스트리 위치의 값을 확인해 보셔야 합니다.

 

AllowRemoteConnection=1

 

 

값이 1 이 아닌경우, 1로 변경하면 정상적으로 ASP.NET Session State Service 를 이용할 수 있습니다.

 

 

2.    SQL Server

 

SQL Server 를 이용하여 데이터베이스를 통해 세션 상태를 유지합니다. 물리적인 디스크를 통해 I/O 가 일어나므로 가장 느린 상태 관리 방법이지만, 세션의 휘발성의 염려가 없는 가장 안정된 서비스를 제공하는 방법 이기도 합니다.

 

우선, 세션으로 사용할 데이터베이스와 그 외 부수적인(테이블/저장 프로시져) 등을 생성해야 하는데, Visual Studio Command Prompt 를 통해 간단하게 생성할 수 있습니다.

 

 

C:\> aspnet_regsql.exe -S <MachineName> -E -ssadd -sstype p

 

 

[그림2] aspnet_regsql.exe 가 생성한 데이터베이스

 

위 명령을 수행하면 [그림2] 와 같이 ASPState 라는 데이터베이스가 생성이 됩니다. 만약 위의 명령줄에서

 

–sstype p

 

를 제거하면 tempdb 에 테이블이 생성 되어 집니다.

 

ASP.NET 1.1 에서 SQL Server 데이터베이스 생성하는 방법

HOWTO: 영구적으로 SQL Server 세션 상태를 관리할 있도록 ASP.NET 구성

 

데이터베이스가 정상적으로 만들어 졌다면, 다음과 같이 web.config 를 변경하여 상태관리 방법을 변경할 수 있습니다.

 

<system.web>

       <sessionState mode="SQLServer"

                      sqlConnectionString="server=localhost; uid=*******; pwd=********* ">

       </sessionState>

 

이전 포스팅에서 언급한 바, Out-of-process 를 통해 세션 상태를 관리하게 되면 Session 개체에 반드시 Serializable(직렬화할 수 있는) 개체만 Session 에 저장할 수 있습니다.

 

3.    구성 섹션을 암호화

 

본 섹션은 Out-of-process 와 관련이 없는 부분이지만, 경우에 따라 민감할 수 있습니다. 왜냐하면, web.config 를 통해 Server Farm 의 접속 정보가 잠재적으로 노출되어 있기 때문입니다. 서버의 .config 가 기본적으로 System.Web.HttpForbiddenHandler 로 지정되어 있어, 외부의 사용자는 web.config 의 내용을 알 수 없지만, 외부 개발자나 시스템 담당자 외에 공개가 되어서는 안되는 경우 구성 섹션을 암호화 하는 방법이 있습니다.

 

이 부분에 대해서는 아래의 MSDN 링크를 통해 보시면 됩니다.

Web.config 암호화

연습: RSA 컨테이너 만들기 내보내기

 

 

너무 포스팅을 쉬었는지 감을 조금 잃어버렸네요~ ^^; 다음 포스팅은 세션상태를 마이그레이션 하는 방법에 대해 보도록 할 예정입니다. MSSQL 로 제한된 세션 상태를 Oracle 에서 이용하도록 변경이 가능하며, 모든 로직을 감추고 분산처리 하는 방법, 이것을 활용한 SSO 시스템의 전반적인 설계까지 알아보도록 할 예정입니다.



Posted by 땡초 POWERUMC

댓글을 달아 주세요



[.NET/ASP.NET] - 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성
[.NET/ASP.NET] - 실전 ASP.NET Session [2] - 상태관리의 종류
[.NET/ASP.NET] - 실전 ASP.NET Session [3] - 다양한 세션 관리 방법
[.NET/ASP.NET] - 실전 ASP.NET Session [4] - 세션상태 마이그레이션

 

 

이 단원은 ASP.NET 의 어느 책을 보아도 나오는 반드시 나오는 챕터이죠. 그만큼 기본적이고 중요한 부분입니다. 왜냐하면 웹이라는 것은 기본적으로 아무런 상태를 저장할 수 없기 때문입니다. 하지만, ASP.NET 을 이용하면 다양한 방법을 통해 상태를 쉽게 할 수 있고, 쉽게 간과할 수 있는 부분을 다시 한번 되새길 수 있도록 구성해 보았습니다.

 

Application 개체

 

이 프로퍼티는 HttpApplicationState 의 인스턴스 입니다. 대부분의 ASP.NET 의 상태관리 개체는 키(Key) 와 값(Value) 이 쌍을 이루는 컬렉션 형태입니다. 따라서 다음과 같이 사용할 수 있습니다.

 

HttpApplicationState app = HttpContext.Current.Application;

app["Key"] = "Value";

 

Response.Write( app["Key"].ToString() );

 

하지만, Page 클래스에 Application 라는 프로퍼티로 정의가 되어 있기 때문에, 다음과 같이 더 간결하게 사용할 수 있습니다.

 

Application["Key"] = "Value";

 

Application 개체는 웹 응용 프로그램의 전역적인 값을 유지할 수 있습니다. 웹 응용 프로그램의 설정이나 세션에 관계없이 전역적인 변수를 저장하는데 유용합니다. 또한, 프로세서가 실행되고 있는 서버의 메모리에 값을 저장하고 있기 때문에 빠르게 데이터를 엑세스 할 수 있습니다. 웹 응용 프로그램은 Worker Processer 의 가상 디렉토리로써 AppDomain 이라는 응용 프로그램 도메인에 속하게 됩니다. 다시 말하자면, HttpRuntime / HttpApplicationState / Page 개체는 AppDomain 에 격리되고, 그렇기 때문에, Application 개체는 응용 프로그램 간에 값을 공유할 수 없습니다.

 

Application 개체는 프로세서가 실행되는 서버의 메모리에 값을 저장하기 때문에, Application 개체에 저장할 데이터는 작으면 작을 수록 좋습니다.

 

[그림1] IIS ASP.NET 리소스 처리 아키텍쳐

( 위 그림과 더불어 참고 하세요 http://www.windowsdevcenter.com/pub/a/windows/2004/03/02/inside_iis.html )

 

ASP.NET 은 요청에 대해 스레드 풀에 요청을 할당하여 그 스레드로 페이지를 실행시킵니다. 페이지의 수행 주기가 끝나게 되면 해당 스레드는 스레드 풀에 반환되게 됩니다. ASP.NET 에 대한 요청은 이러한 다중 스레드 환경에서 Application 개체의 Input 이 발생하게 되면 동시성에 의해 원치 않는 데이터가 저장될 수 있습니다. 그렇기 때문에, Application 개체의 초기화는 Global.asax Application Start 이벤트를 통해 개체를 초기화 하도록 해야 합니다.

 

만약, Application Start/End 외에 다른 곳에서 Application 에 데이터를 Input 하기 위해 잠금/잠금 해제의 코드를 작성해 주시면 됩니다.

 

Application.Lock();

Application["Count"] = (int)Application["Count"] + 1;

Application.UnLock();

 

위와 같이 다중 스레드에서 Application 개체를 동기화 하기 위해 Lock() UnLock() 메서드를 통해 잠금을 수행할 수 있습니다.

 

Application 사용시

1.      데이터의 크기가 작을 때 경우 이용

2.      메모리에서 I/O 가 발생하기 때문에 잦은 입출력에 용이

3.      잦은 I/O 가 발생하는 페이지에 사용시 반드시 동기화 코드를 작성

 

 

ViewState 개체

 

ViewState 는 현재 페이지의 상태를 유지하기 위해 사용됩니다. 기본적으로 ViewState 히든필드(Hidden Field) 형태로 HTML 로 내려보내지며, 포스트 백이 발생하게 되면 Hidden Field 를 전송하여 페이지 상태를 유지할 수 있습니다.

 

[그림2] 소스 보기를 통해 본 ViewState

 

ViewState 는 계층적인 형태로 표현이 되는데, 자세한 정보는 태요 사이트ViewState 데이터를 분석하자를 참고 하시기 바랍니다.

 

ViewState 는 여느 상태 관리 컬렉션과 같이 간단하게 사용할 수 있습니다.

 

ViewState["CategoryID"] = "1234";

Response.Write(ViewState["CategoryID"].ToString());

 

특별한 기교 없이 쉽게 구현이 가능하지요.

 

ViewState 는 위의 [그림2] HTML 소스를 보는 것과 같이 상태 정보를 HTML 에서 정보를 가지고 있기 때문에 서버의 리소스가 필요하지 않습니다. 서버의 리소스가 필요하지 않기 때문에, 실제로 가장 많이 사용하는 상태 관리 기법이면서, ASP.NET 플랫폼의 서버 컨트롤이나 Form Runat=”Server” ( , Form 의 모든 요소를 서버에서 처리 ) 하기 때문에, 많은 부분의 상태 관리가 자동화 되어 있습니다.

 

이것이 강점이자 단점이 되는 것이 ASP.NET ViewState 입니다. Form 의 상태를 서버에서 처리를 하고, 서버 컨트롤이라는 편리한 ASP.NET 컨트롤을 이용하고, 이 컨트롤들은 스스로 상태 관리 능력을 가지고 있습니다. Control SaveViewState LoadViewState 메서드를 override 함으로써 컨트롤 스스로 상태 관리 능력을 부여할 수 있기 때문입니다. 하지만 GridView DataList 와 같은 많은 기능을 가지고 있는 컨트롤들은 바인딩 되는 DataSource 에 따라 ViewState 는 눈덩이 처럼 불어나게 됩니다. 아무 생각 없이 서버 컨트롤만을 사용하다 보면 ViewState 의 용량만 10 Kb, 20 Kb 가 훌쩍 넘어 버립니다. 우리나라와 같이 네트워크 인프라가 원활한 환경이라면 콧방귀를 뀌고 우습게 여길 수 도 있지만, 모바일 장치나 인터넷 속도가 느린 외국에서 서비스를 해야 할 경우 상황은 달라지게 됩니다.

 

ASP.NET ViewState Serializable 형태여야 합니다. ViewState HTML 코드로 랜더링 하기 위해서 이러한 직렬화 과정을 거치게 되고, 이것을 Base64 인코딩을 통해 [그림2] 와 같이 문자열로 변환하게 됩니다. 포스트백을 통해 Base64 디코딩과 역직렬화 과정을 거쳐 개체로 반환되게 됩니다. 수십/수백명의 동시 접속자가 예상되는 서비스에서는 ViewState 는 곧 CPU 부하를 증가시키고, 서버를 늘릴 수 밖에 없는 비용적인 측면을 생각하면 개인이나 기업에게는 잠재적인 부담일 수 밖에 없습니다.

 

해결책으로 가장 좋은 방법은 ViewState 를 사용하지 않는 것입니다. 대부분의 ViewState 는 서버 컨트롤에서 발생하기 때문에, 서버 컨트롤의 사용량을 줄이는 것이 좋은 방법이 될 수 있습니다. 더 나아가, Form Runat=”Server” 속성을 날려버리고, 여러개의 form 으로 나누어 서버로 전송되는 트래픽의 양을 줄여 ViewState 의 연산을 없애 버리는 것도 좋은 방법입니다.

 

다음 코드는 ViewState 를 사용하지 않는 최적화된 HTML 입니다.

 

<body>

    <form id="form1">

    <div>

             <input id="txtName" name="txtName" type="text" value="<%= txtName %>" />&nbsp;

             <input id="btnSend" name="btnSend" type="submit" value="Send" />

    </div>

    </form>

</body>

 

Form 태그의 Runat=”Server” 속성을 제거해 버렸습니다. 그렇기 때문에, Send 버튼을 클릭하게 되면 txtName 의 텍스트박스는 상태 관리가 되지 않습니다. 포스트백(Submit) 이 발생하면 txtName 의 텍스트박스는 입력된 값이 모두 사라지게 됩니다. Form Runat=”Server” 를 제거하면 기본적인 ViewState 조차 생기지 않습니다.

 

그럼 여기에 상태 관리를 위한 코드를 삽입해 보면..

 

public partial class _Default : PageBase

{

      

       protected string txtName;

 

       protected void Page_Load(object sender, EventArgs e)

       {

             try

             {

                    this.txtName = Request.Params["txtName"];

             }

             catch (Exception ex)

             {

                    Response.Write(ex);

             }

       }

}

 

위 코드를 삽입하게 되면, Send 버튼 클릭 후에도 txtName 의 텍스트박스는 이전에 입력했던 값을 유지하게 됩니다. 서버컨트롤과 자동화된 ASP.NET 의 상태 관리 없이 개발자가 직접 코드를 작성하여 상태 관리를 하는 방법입니다.

 

짧은 제 경험상, 기업의 내부 인트라넷의 경우 다양한 요구사항과 업무 처리를 위해 서버 컨트롤과 더불어 다양한 기능의 상용 컴포넌트와 컨트롤을 사용하기도 합니다. 하지만, 웹 서비스와 같이 불특정 다수에게 노출이 되는 중~대규모 사이트라면 서버컨트롤을 자재하여 사용하기도 하지만 아예 위의 방법처럼 코드를 통해서 상태 관리를 하기도 합니다. 생산성 측면에서 본다면, 당연히 개발 속도는 자동화된 ASP.NET ViewState 를 사용하는 것보다 느릴 수 있지만, 서버로 전송되는 트래픽의 양이 줄고, 서버의 CPU 연산이 줄게 되어 최종 사용자(End User) 측면에서는 빠른 응답 속도를 기대할 수 있습니다.

 

하지만, ViewState 를 포기한다는 것은 굉장히 어려운 문제일 수 있습니다. Form Runat=”Server”를 사용하지 않고, 수동적으로 상태 관리를 하게 되면, 많은 편리한 ASP.NET 의 기능을 사용할 수 없기 때문이죠. 그 대표적인 예가, ASP.NET AJAX ScriptManager 컨트롤 또한 사용할 수 없게 되고, 내부적으로 SaveViewState LoadViewState 를 사용하는 모든 서버 컨트롤(Label 외 몇 가지 컨트롤은 제외…)은 사용할 수 없게 됩니다. 때문에, 적절한 대안을 찾아야 하는데 바로 Control 이란 부모 클래스에는 EnableViewState 속성이 대안이 될 수 있습니다.

 

EnableViewState 는 컨트롤이 ViewState 를 사용할 것인지의 여부를 결정합니다. DataGrid 를 예로 들자면, 기본적인 EnableViewState 속성이 True 이기 때문에, 최초 한번의 DataBind 을 하고, 포스트백이 발생하여도 상태는 유지되지만, DataGrid 의 속성을 EnableViewState=False 로 변경하면, DataSource 의 데이터를 더 이상 ViewState 로 관리하지 않게 됩니다. 모든 컨트롤의 EnableViewState 속성을 변경해야 한다면, Page EnableViewState 도 있습니다. Page EnableViewState 는 더 이상 그 Form 은 모든 ViewState 를 관리 하지 않겠다는 것을 의미하며, 지저분한 ViewState 를 더 이상 생성하지 않습니다. (, 포스트백인지 아닌지의 여부를 감시하는 일부의 Hidden Field 를 생성할 수 있습니다.)

 

위의 내용과 더불어 EnableViewState MAC 이라는 것이 있습니다. 높은 수준의 데이터 무결성이나 데이터의 훼손이 큰 경우 EnableViewStateMac 속성을 True 로 지정해야 합니다. (기본값은 False) 입니다. 지난 아티클의 RewritePath 포스트백(Postback) 문제와 해결 방법을 통해 포스트백의 URL 을 지정해 줄 수 있는데, 이러한 비 정상적인 방법(?) 을 이용하게 되면, 서버 측에서는 ViewState 가 훼손되었거나, 데이터가 변경된 것으로 인지할 수 있습니다. 또한, 가끔씩 UpdatePanel 을 이용해 프로그램을 하다보면 개발자의 잘못된 알고리즘으로 인하여 ViewState 가 손실되거나 변경되는 경우가 있습니다. 이러한 경우들에 대해 EnableViewStateMac=False 를 통해 데이터의 무결성 검사 등의 ViewState 의 상태를 검사하지 않을 수 있게 됩니다.

 

하지만, 결정적으로 ViewState 는 클라이언트에 내려지고, 다시 이 ViewState 는 서버로 전송되는 형태이기 때문에, ViewState 는 언제든지 조작의 가능성이 있습니다. 간단한 툴을 이용해서 ViewState 가 어떤 정보를 가지고 있는지 쉽게 알 수 있기 때문에, ViewState 의 데이터를 항상 신뢰하면 안됩니다. ASP.NET 2.0 부터 이러한 ViewState 를 암호화 할 수 있는 기능이 제공됩니다. 간단히 @Page 지시자에 ViewStateEncryptionMode="Always" 를 넣음으로써 페이지의 ViewState 를 암호화 할 수 있습니다. 모든 웹 응용 프로그램의 페이지에 이러한 속성을 주기 위해서 web.config system.web 섹션에

 

<system.web>

       <pages viewStateEncryptionMode="Always">

 

로 지정해 주기만 하면 됩니다.

 

이것의 기본 속성은 Auto 입니다. Auto 는 아무런 ViewState 암호화가 수행되지 않습니다. , 개발자의 코드를 통해 페이지의 암호화를 지정해 줄 수 있는데,

 

Page.RegisterRequiresViewStateEncryption();

 

의 명시적인 호출로 Auto 상태에서 ViewState 암호화를 지정해 줄 수 있습니다. , 암호화를 수행하게 되면 그만큼의 CPU 의 부하도 늘게 된다는 것 또한 잊어서는 안됩니다.

 

ViewSate 사용시

1.      프로젝트가 어떤 용도의 서비스인지 잘 판단하여, 상태관리를 자동화 할 것인지, 수동화 할 것인지 결정

2.      EnableViewState MAC / ViewStateEncryptionMode 유용할 있지만, 남용하게 되면 CPU 파워만 증가시킨다

 

 

Sessoin 개체

 

이제야 Session 개체가 나왔습니다. 3회차부터 이 Session 개체를 더 자세히 볼 예정이기 때문에, 여기에서의 Session 은 가볍게 보도록 하겠습니다.

 

여느 상태관리 개체와 마찬가지로 사용법은 매우 간단합니다.

 

Session.Add("Key1","Value1");

                          

Session["Key2"] = "Value2";

 

 [그림3] 브라우져 요청 별 쿠키 생성

 

기본적으로 HTTP 프로토콜을 이용한 요청은 독립적으로 요청을 처리합니다. 요청에 대해 상태를 유지할 수 없기 때문에 어떤 사용자에 의한 요청인지 알 수 있는 방법이 없습니다. 그렇기 때문에, Session 은 쿠키와 브라우져에 의존적입니다. 이전 포스팅의 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성에서도 설명했듯이, 브라우져가 사이트에 요청을 할 때 생성이 되고, 브라우져를 닫게 되면 쿠키도 삭제된다고 하였습니다. , 만료시간이 지정된 경우에 텍스트 형태로 사용자의 하드 디스크에 저장이 됩니다.

 

[그림4] 브라우져별 요청에 대한 쿠키 생성

 

브라우져는 의해 처음 사이트에 요청을 하게 되면 쿠키를 생성하게 됩니다. 때문에 브라우져 별로 처음으로 사이트를 요청하게 되면 쿠키를 생성하는데 그것이 바로 ASP.NET 이 상태관리를 위한 Session ID 를 쿠키로 생성하게 됩니다. 이러한 행위는 사용자별로 고유한 세션 저장소에 정보를 저장하기 위해서이며, 사이트에 접속한 여러 사용자를 구별한 수 있는 키(Key) 가 되기도 합니다. 좀 더 정확하게 말하면, 이러한 Session ID AppDomain 별로 웹 응용프로그램의 Application ID 가 세션의 키값으로 사용되어 집니다. 그렇게 때문에, AppDomain 간의 Session 의 값은 공유할 수 없게 됩니다.

 

ASP.NET Session 은 기본적으로 쿠키를 통해 Session ID 를 인식합니다. 하지만, 특정 사용자의 브라우져 상태는 쿠키를 허용하지 않을 수 도 있습니다. 또한 사용자 임의로 쿠키를 허용하지 않도록 할 수 도 있습니다. ASP.NET 은 쿠키 기반의 세션 유지가 아닌 쿼리 문자열을 통해 Session ID 를 유지할 수 도 있습니다.

 

system.web 섹셕의 sessionState 요소를 통해 아래와 같이 cookieless true 로 설정하면, 더 이상 쿠키 기반으로 Session ID 를 유지하지 않고, 쿼리 문자열을 통해 Session ID 를 식별하게 됩니다.

 

<system.web>

       <sessionState cookieless="true"></sessionState>

 

[그림5] 쿼리 문자열을 통한 Session ID 유지

 

ASP.NET 은 보다 자동화된 Session ID 를 유지하도록 해 줍니다. 가령, 사용자의 브라우져나 쿠키를 허용하지 않거나, 임의로 쿠키를 허용하지 않도록 설정한 경우 cookieless AutoDetect 로 설정하게 되면, ASP.NET 쿠키를 통해 Session ID 를 유지할 것인지, 쿼리 문자열로 Session ID 를 유지할 것인지를 스스로 결정하게 됩니다. 기본적으로 cookieless 속성은 디폴트로 UseCookies 로 설정되어 있기 때문에,

 

<sessionState cookieless="AutoDetect"></sessionState>

 

과 같이 개발자가 직접 수정해 주셔야 합니다.

 

기본적은 Session 설정은 In-of-process 를 통해 처리되게 됩니다. In-of-process ASP.NET Worker Process 를 통해 처리가 되며, Worker Process 가 구동되는 서버의 메모리에 저장이 됩니다. Application 개체와 마찬가지로 Session 개체는 In-of-Process 로 처리가 될 경우 웹 응용프로그램의 빌드나 web.config 의 설정이 바뀔 경우 개체의 데이터는 모두 잃어버릴 수 있습니다. 명시적으로 sessionState mode 속성을 지정하지 않으면 디폴트로 InProc 입니다

 

Session 을 잃게 된다는 것은 웹 서비스에게 치명적일 수 있습니다. 한가지 예를 들어보면, 쇼핑몰 사이트가 있습니다. 상품을 결재를 하기 위해서 대부분 여러 단계를 거쳐 인증을 하고, 결재가 진행됩니다. 하지만, 사이트 관리자는 서버의 치명적인 버그를 발견하여 수정하고 웹 어플케이션을 업데이트 한다면, 결재중인 사용자의 Session 은 끊겨버리게 됩니다. 물론, 이러한 결재 오류에 대한 정책이 잘 정립 되어 운영 된다면 문제가 없겠지만, 데이터베이스를 조작하지 못하는 서버 관리자만을 채용하는 소형 쇼핑몰일 경우 이러한 문제는 쉬쉬 하며 넘어갈 일만은 아닐 것입니다.

 

[그림6] 다양한 Session State 유지 계획

 

하지만, 여기서도 문제라면 서버의 메모리는 제한적입니다. 때문에 In-of-process 가 아닌, Out-of-process 로 전환할 필요가 생기게 됩니다. 또한 대형 사이트일 경우 Web Farm 으로 부터 여러 개의 Server Farm 을 구성하여 분산처리 할 경우 보다 나은 성능과 관리의 이점이 있습니다. , 한가지 Out-of-process Serializable 개체만을 Session 에 저장할 수 있다는 제한이 있습니다.(당연하겠지만)

 

다음 아티클에서 Session State 를 유지하는 다양한 방법을 알아 보고, 방법에 대한 보다 나은 이슈를 제시할 예정입니다.

 

용어설명 참고

위키디피아 Web Farm(Server Farm)

Web Garden – MSDN ASP.NET 작업자 프로세스

 

Session 사용시

1.      소규모 사이트일 경우 In-of-process 를 권장

2.      Session 은 어떻게 사용 하느냐도 중요하지만 어떻게 운영하는가에 대한 기술적인 계획이 필요

 


Posted by 땡초 POWERUMC

댓글을 달아 주세요

[.NET/ASP.NET] - 실전 ASP.NET Session [1] - 쿠키를 이용한 상태관리와 위험성
[.NET/ASP.NET] - 실전 ASP.NET Session [2] - 상태관리의 종류
[.NET/ASP.NET] - 실전 ASP.NET Session [3] - 다양한 세션 관리 방법
[.NET/ASP.NET] - 실전 ASP.NET Session [4] - 세션상태 마이그레이션


프로그램의 코드를 짜면서 쉽게 간과할 수 있는 상태관리 오류 등을 범하기도 합니다. 때론, 적절한 상태 저장소를 잘못 선택하여 잘못된 코드와 결과를 보는 경우도 있습니다. 이번 아티클은 그런 오류를 범하지 않고, 적절한 상태관리를 할 수 있도록 방법을 제시해 줄 예정입니다. 또한, 3회 포스팅 부터는 그저 별 것 아닌 Session 이라는 상태 저장소에 대해 좀 더 깊이 알아보고, Session 을 확장하는 방법과 시스템의 전반적인 설계 방법까지 알아볼 예정입니다.

 

1.    쿠키를 이용한 상태관리와 위험성

 

ASP.NET 플랫폼은 다양한 상태관리 방법을 제공해 줍니다. 그렇기 때문에, 개발자는 적절한 상태관리 저장소를 선택하기만 하면 됩니다. 그럼, 상태 관리의 종류와 이것을 선택하기 위한 조건, 적절한 사용 방법도 함께 살펴보겠습니다.

 

1.1.    쿠키 (Cookie) 를 이용한 상태관리

 

우선 쿠키의 생성 주기를 보면, 쿠키는 브라우져가 사이트에 요청을 할 때 생성이 됩니다. 그리고 브라우져를 닫으면 쿠키는 삭제됩니다. 이러한 쿠키에 대한 정보를 브라우져가 관리하게 되지만, 웹 서버에서 쿠키에 대한 만료시간 정보를 보낼 경우, 브라우져는 쿠키 정보를 하드 디스크에 저장하게 됩니다. 그리고 만료된 쿠키는 쿠키를 작성한 웹사이트를 방문할 때 브라우져가 삭제하게 됩니다.

 

[그림1] 자바스크립트로 네이버의 쿠키 정보 확인

 

쿠키는 브라우져마다 다를 수 있지만 최대 4096 Bytes(4KB) 의 텍스트 정보를 저장할 수 있고, 최대 300개의 쿠키를 보존하며, 사이트마다 20개의 쿠키를 허용 합니다. 용량과 개수의 제한이 있기 때문에, 경량의 정보를 저장할 때 유용합니다. 하지만, 쿠키의 만료시간을 지정하게 되면 텍스트로 사용자의 하드디스크에 정보를 저장하기 때문에 메모장을 이용하여 임의로 쿠키 정보를 변경할 수 있습니다. 심지어, 자바스크립트를 이용하여 쿠키를 조작할 수도 있기 때문에, 중요한 정보를 쿠키에 저장하는 것은 매우 부적합 합니다.

 

쇼핑몰의 최근 본 상품과 같이 서버에서 정보를 관리할 필요가 없고, 정보의 보안이 필요 없고, 가벼운 경우 선택하면 됩니다.

 

쿠키는 다음의 경우에 사용되면 됩니다.

1.      1회성 정보일 경우

2.      작은 양의 정보를 저장할 경우

3.      중요하지 않은 정보일 경우 (개인정보나 노출되면 안되는 정보는 절대로 쿠키를 사용하지 마십시오)

 

 

1.2.    쿠키의 위험성

 

위의 사용 조건이 충족 되었더라고 하더라도, 안심하면 안됩니다. 쿠키의 정보가 조작이 되었을 경우, 쿠키 정보를 절대로 신뢰하면 안되기 때문입니다.