목차
1. 닷넷의 정의
2. 장점
3. 닷넷UE
4. 닷넷의 내부구조 및 도구
5. 닷넷 빌딩블록 서비스
6. 닷넷 인터넷 접속 기기용 소프트웨어
7. 닷넷 제품
7.1 윈도우 닷넷
7.2 MSN닷넷
7.3소비자 가입 서비스
7.4 오피스닷넷
7.5 비센트랄닷넷
7.6 비주얼스튜디오닷넷
8. 닷넷 FRAMEWORK
2. 장점
3. 닷넷UE
4. 닷넷의 내부구조 및 도구
5. 닷넷 빌딩블록 서비스
6. 닷넷 인터넷 접속 기기용 소프트웨어
7. 닷넷 제품
7.1 윈도우 닷넷
7.2 MSN닷넷
7.3소비자 가입 서비스
7.4 오피스닷넷
7.5 비센트랄닷넷
7.6 비주얼스튜디오닷넷
8. 닷넷 FRAMEWORK
본문내용
프로그램은 맥킨토시에서 실행되지 못하는 것이다.
닷넷 프레임워크의 비밀은 바로 이 컴파일 작업
.NET Framework(실제로는 .NET Framework 라이브러리)를 사용하여 만든 코드(Visual Basic.NET, Visual C#.NET, Visual C++.NET 등과 같은...) 를 컴파일할 때에는 일반적인 컴파일 작업과 다른 방식을 취한다. 네이티브 코드로 바로 컴파일 하지 않고 우선 'Microsoft Intermediate Language(MSIL) 코드'라는 것으로 컴파일 한다. C#으로 만든 코드건 Visual Basic.NET 으로 만든 코드건 .NET 코드는 모두 다 이 MSIL 코드로 컴파일 된다.
MSIL 코드는 네이티브 코드와는 달리 어떠한 OS나 하드웨어적인 정보를 포함하고 있지 않는다. 따라서 이 코드는 아직 컴퓨터 상에서 직접 실행할 수 없다. (Just-In-Time(JIT)'이라는 또 다른 컴파일러가 이 MSIL 코드를 네이티브 코드로 다시 컴파일 해주기 전까지)
JIT 컴파일러가 MSIL 코드를 컴파일 할때 OS에 대한 정보라든지 하드웨어와 관련된 정보들을 포함 시킨 후, 컴퓨터에서 실행 가능한 네이티브 코드로 변환해 준다..
일반적인 컴파일링 형태 (그림 1-1)
.NET 코드의 컴파일링 형태 (그림 1-2)
네이티브 코드로 변환하는 똑 같은 작업인데 굳이 중간에 MSIL 코드로 바꿔서 JIT 컴파일러로 다시 컴파일 하는 이유?
닷넷의 근본 목적인 시스템 통합 임무를 완벽히 수행하기 위함이다.
예를 들어 기존의 컴파일링 방법은 코드를 컴파일 할 때 미리 정해둔 특정 OS나 CPU 아키텍쳐 같은 정보들을 함께 포함 시킨다. 이때의 장점은 그 시스템에 대해 코드가 최적화 되었기 때문에 CPU 액세스 속도면에서나 안정성면 등에서 월등한 성능을 기대할 수가 있다. 근데 문제는 호환성이다. Win98 에 최적화된 네이티브 코드는 WIn2000에서는 문제를 발생 시킬 수 있는 소지가 다분하다. Win2000을 위해서는 거기에 맞게 다시 코드 작업과 컴파일 작업을 해주어야 한다.
하지만 .NET Framework(닷넷 프레임워크)에는 각기 다른 다양한 시스템 아키텍처 정보를 가지고 있는 여러개의 JIT 컴파일러들이 있다. 그중의 하나를 이용하여 MSIL 코드를 그때 그때 주어진 시스템 환경에 적합한 네이티브 코드로 변환하는 것이다. 그것도 미리 컴파일 해놓는 것이 아니고, Just-In-Time이라는 컴파일러 이름처럼 필요할때에만 네이티브 코드로 컴파일 한다. 따라서 .NET 으로 작업한 코드는 모든 시스템에서 최적화 될 수 있게 되었으며 더이상 각 시스템 환경에 따른 호환성 문제를 고민할 필요도 없게 되는 것이다.
MS사가 SUN사의 JAVA와 대결하기위해 내놓은 .NET이 기존에 기업들,개발자들이 JAVA사용의 비중을 .NET이 파고들 수 있을지는 아직 미지수다. 하지만 혁신적인 기술은 무시못할 거센 파도라고 한다. 인터넷상의 개발자들의 JAVA와 .NET의 우위 논란도 치열하다.
닷넷 프레임워크의 비밀은 바로 이 컴파일 작업
.NET Framework(실제로는 .NET Framework 라이브러리)를 사용하여 만든 코드(Visual Basic.NET, Visual C#.NET, Visual C++.NET 등과 같은...) 를 컴파일할 때에는 일반적인 컴파일 작업과 다른 방식을 취한다. 네이티브 코드로 바로 컴파일 하지 않고 우선 'Microsoft Intermediate Language(MSIL) 코드'라는 것으로 컴파일 한다. C#으로 만든 코드건 Visual Basic.NET 으로 만든 코드건 .NET 코드는 모두 다 이 MSIL 코드로 컴파일 된다.
MSIL 코드는 네이티브 코드와는 달리 어떠한 OS나 하드웨어적인 정보를 포함하고 있지 않는다. 따라서 이 코드는 아직 컴퓨터 상에서 직접 실행할 수 없다. (Just-In-Time(JIT)'이라는 또 다른 컴파일러가 이 MSIL 코드를 네이티브 코드로 다시 컴파일 해주기 전까지)
JIT 컴파일러가 MSIL 코드를 컴파일 할때 OS에 대한 정보라든지 하드웨어와 관련된 정보들을 포함 시킨 후, 컴퓨터에서 실행 가능한 네이티브 코드로 변환해 준다..
일반적인 컴파일링 형태 (그림 1-1)
.NET 코드의 컴파일링 형태 (그림 1-2)
네이티브 코드로 변환하는 똑 같은 작업인데 굳이 중간에 MSIL 코드로 바꿔서 JIT 컴파일러로 다시 컴파일 하는 이유?
닷넷의 근본 목적인 시스템 통합 임무를 완벽히 수행하기 위함이다.
예를 들어 기존의 컴파일링 방법은 코드를 컴파일 할 때 미리 정해둔 특정 OS나 CPU 아키텍쳐 같은 정보들을 함께 포함 시킨다. 이때의 장점은 그 시스템에 대해 코드가 최적화 되었기 때문에 CPU 액세스 속도면에서나 안정성면 등에서 월등한 성능을 기대할 수가 있다. 근데 문제는 호환성이다. Win98 에 최적화된 네이티브 코드는 WIn2000에서는 문제를 발생 시킬 수 있는 소지가 다분하다. Win2000을 위해서는 거기에 맞게 다시 코드 작업과 컴파일 작업을 해주어야 한다.
하지만 .NET Framework(닷넷 프레임워크)에는 각기 다른 다양한 시스템 아키텍처 정보를 가지고 있는 여러개의 JIT 컴파일러들이 있다. 그중의 하나를 이용하여 MSIL 코드를 그때 그때 주어진 시스템 환경에 적합한 네이티브 코드로 변환하는 것이다. 그것도 미리 컴파일 해놓는 것이 아니고, Just-In-Time이라는 컴파일러 이름처럼 필요할때에만 네이티브 코드로 컴파일 한다. 따라서 .NET 으로 작업한 코드는 모든 시스템에서 최적화 될 수 있게 되었으며 더이상 각 시스템 환경에 따른 호환성 문제를 고민할 필요도 없게 되는 것이다.
MS사가 SUN사의 JAVA와 대결하기위해 내놓은 .NET이 기존에 기업들,개발자들이 JAVA사용의 비중을 .NET이 파고들 수 있을지는 아직 미지수다. 하지만 혁신적인 기술은 무시못할 거센 파도라고 한다. 인터넷상의 개발자들의 JAVA와 .NET의 우위 논란도 치열하다.
추천자료
[경영정보시스템].NET(닷넷)에 대하여
모바일 디바이스에서 닷넷 애플리케이션 구축하기(2) 데이터 바인딩
모바일 디바이스에서 닷넷 애플리케이션 구축하기(3) 모바일 웹 응용 프로그램 개발하
모바일 디바이스에서 닷넷 애플리케이션 구축하기(4) Mobile Internet Toolkit
.net(XML 웹 서비스를 위한 Microsoft의 플랫폼)
Web Service, UDDI, J2EE, .NET , Sun ONE
마이크로소프트 닷넷 (ASP.NET)
[asp.net]을 이용한 회원정보관리 프로그램
자바(Java)와 닷넷(.net)에 대한 차이점 비교
소개글