Framework Version 2 이후의 MVC와 Web API 간의 주된 차이점은 Web API handler 의 경우 HttpTaskAsynHandler 의 Subclass 인 반면 MVC 버전의 MvcHandler 는 IHttpAsyncHandler 를 직접 구현하였다.

 

HttpTaskAsyncHandler 는 Web API 2 에서 지원되는 .NET version 인 .NET 4.5 에만 있다.

 

동일한 ASP.NET process 내에서 MVC와 Web API 를 동시에 구동할 때 ASP.NET 은 HttpApplication을 사용하게된다.

Request 가 들어오면 MapRequestHandler event 에서 사용할 Http Handler 를 결정한다.

이 단계에서 route matching 이 일어나고 request 는 선택된 route 와 관련된 IRoutHandler 를 통해 이동하게된다.

 

IRouteHandler 의 유일한 목적은 request 를 처리(handle)할 수 있는 IHttpHandler 를 생성하는 것이다.

만일 IRouteHandler 가 HttpControllerRouteHandler (Web API route) 라면 Web API 경로가 선택되어 Request 는 HttpControllerHandler 에서 끝마치게되며, 반대로 Route Handler 가 MvcRouteHandler 라면 MVC 경로를 취하여 MvcHandler 로 이동한다.

 

 

(APRESS) ASP.NET Web API 2 Recipes 중에서...

 

 

행복한 고수되셔요. ^^*

 

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 

 

 













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja

아래의 내용을 봤습니다.

 

https://stackoverflow.com/questions/876473/is-there-a-way-to-check-if-a-file-is-in-use

 

저는 아래 구문이 그런데로 나은듯한데요.

 

        private bool IsFileLocked(string filePath)
        {

            try
            {
                using (Stream stream = new FileStream(filePath, FileMode.Open))

                {

                     // File/Stream manipulating code here

                }
            }
            catch (IOException ex)
            {
                return true;
            }
            finally
            {
            }

            //file is not locked
            return false;
        }

 

잠시 생각해보니 궁금한 점이 생기네요.

IsFileLocked Method 에 접근하는 동안 Lock 이 발생하지 않을까요?

파일이 잠겨있는지 확인하는데 Lock 이 걸린다면.

stream 이 Close 될때까지의 시간이 그리 길지 않겠지만 말이죠.(당연히 파일의 크기에 따라 달라지겠죠?)

 

행복한 고수되셔요. ^^

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'.NET > C#' 카테고리의 다른 글

[C#] How do you check if a file is in use?  (0) 2017.07.27
[C#] 단일 Process 실행  (2) 2010.11.08
[C#] C# 은 VB.NET 따라쟁이...  (3) 2009.05.07
[C#] C# 컴파일러 오류  (0) 2009.03.06
[C#] 요것 한번 보시죠... VB.NET 에는 없어요. ^^'  (0) 2009.03.06
[C#] Yield  (0) 2009.03.06
Posted by woojja
TAG c#, file lock

다음은 Middleware 의 내용을 번역했습니다.

번역이 많이 부족합니다. 참고로만 사용하셔요 ^^;

 

 

ASP.NET Core 미들웨어 기초

 

 

미들웨어란 무엇인가?
미들웨어란 Request와 Response 를 처리하기위해서 Pipeline 으로 조립된 소프트웨어다.
파이프라인에서 각 구성요소는 Request 를 다음 구성요소로 전달할지 여부를 결정하고, 파이프라인에서 다음 구성요소가 호출되기 이전, 이후에 특정 Action 을 수행하는 것이 가능하다.
Request delegate(요청 대리자, 위임자) 들은 Request Pipelie 을 구성하는데 사용된다.
Request delegate 들은 각 HTTP Request 를 처리한다.


 

Request delegate 는 IApplicationBuilder 인스턴스에서 Run, Map Use 확장 메서드로 구성되며  Startup클래스의 Configure 메서드로 전달된다.
개별적인 Request delegate 는 anonymous(익명) 메서드 (in-line middleware 라 불리는) 로서 in-line 에서 지정하거나 재사용가능한 클래스내에서 정의하는 것이 가능하다.
이런 재사용가능한 클래스와 인라인 익명 메서드는 미들웨어 이거나 미들웨어 구성요소다.
Request pipeline 의 각 미들웨어 구성요소는 pipeline 내에서 다음 구성요소를 호출하거나 적절한 경우 연결(Chain)을 끊는다.

 

Migrating HTTP Modules to Middleware 에서는 ASP.NET Core 와 이전 버전에서의 Request Pipeline 의 차이점에 대해 설명하고 더 많은 Middleware 예제를 제공한다.

IApplicationBuilder를 사용하여 미들웨어 파이프 라인 만들기
ASP.NET Core Request Pipeline 은 Request Delegate 들의 순서로 구성되며 Diagram에서 보듯이 차례대로 호출된다. (검정색 화살표 방향으로 실행이 진행된다.):

 


각 Delegate 는 다음 Delegate 가 실행되기 전후에 작업을 수행하는 것이 가능하다.
Delegate 는 또한 다음 Delegate 로 Request 를 전달할지 결정하는 것이 가능하며 이것을 Request Pipeline 을 단락(Short-circuiting)시킨다 라고 부른다.
Short-Circuiting 은 불필요한 작업을 피할 수 있기 때문에 종종 바람직하다.
예를 들어, 정적파일 Middleware 는 정적파일을 작성하기위한 Request 를 반환하거나 Pipeline 의 나머지 작업을 Short-Circuiting 하는 것이 가능하다.
Exception-handling Delegate 는 Pipeline 의 초기에 호출될 필요가 있으며, 그 결과로 Pipeline 이후단계에서 Exception 을 Catch 하는 것이 가능하다.

가장 단순하고도 실행가능한 ASP.NET Core App은 모든 Request를 처리하는 단일 Request delegate 를 구성한다.
이 경우 실제 Request Pipeline 을 포함하지 않는다.
대신 모든 HTTP Request 에 대해 Response 로 단일 anonymous function 이 호출된다.

 

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello, World!");
        });
    }
}


첫번째 app.Run Delegate 는 Pipeline 을 종료한다.
app.Use 을 사용하여 여러 Request Delegate 들을 연결하는 것이 가능하다.
pipeline 에서 next Parameter 는 다음 Delegate 를 나타낸다.(next Parameter 를 호출하지 않음으로써 Pipeline 을 Short-Circuit 가능하다는 점을 기억하라.)
이 예제처럼 다음 Delegate 전후에 Action 을 전형적으로 수행하는 것이 가능하다.

 

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Use(async (context, next) =>
        {
            // Do work that doesn't write to the Response.
            await next.Invoke();
            // Do logging or other work that doesn't write to the Response.
        });
 
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from 2nd delegate.");
        });
    }
}

 

경고
Response 를 Client 에 전송한 후 next.Invoke 를 호출하지 말 것.
Response 가 시작된 이후에 HttpResponse 를 변경하면 exception 을 발생한다.
예를 들어 headers, status code등의 구성을 변경하는 작업은 exception을 발생한다.
next를 호출한 이후에 Response body 를 작성하라 : 
    protocol violation 의 원인이 될 수 있다. 예를 들어 content-length 보다 더 작성하는
    body format 을 손상할 수도 있다. 예를 들어 CSS 파일에 HTML footer 를 작성하는

HttpResponse.HasStarted 는 Header 가 보내졌는지 그리고/혹은 body 가 작성되었는지 알 수 있는 유용한 Hint 다.

 

순서정하기

Configure method 에 추가된 Middleware 구성요소의 순서는 Request 에서 호출되는 순서를 정의하며,
Response 의 역순이다.
이 순서는 보안, 성능, 기능에 중요하다.

(아래 보이는) Configure mathod 는 다음 Middleware 구성요소를 추가하고 있다.

1. Exception/error handling
2. Static file server
3. 인증
4. MVC

 

public void Configure(IApplicationBuilder app)
{
    app.UseExceptionHandler("/Home/Error"); // Call first to catch exceptions
                                            // thrown in the following middleware.
 
    app.UseStaticFiles();                   // Return static files and end pipeline.
 
    app.UseIdentity();                     // Authenticate before you access
                                           // secure resources.
 
    app.UseMvcWithDefaultRoute();          // Add MVC to the request pipeline.
}


 

위 코드에서 UseExceptionHandler 는 Pipeline 에 첫번째로 추가된 Middleware Component 로 이후 호출에서 발생하는 모든 exception 을 catch한다.
호출된 Static file Middleware Pipeline 의 초기에 호출되어 나머지 component를 거치지 않고도 Request 와 short-circuit 를 처리하는 것이 가능하다.
Static file Middleware 는 권한 Check 기능을 제공하지 않는다.
wwwroot 아래에 있는 파일들을 포함하여 Static file Middleware 에 의해 제공하는 모든 파일은 공개적으로 사용가능하다.
static file 의 보안 방법에 대해서는 Working with static files 를 참고하라.

만약 Request 가 static file middleware 에 의해 처리되지 않으면 인증을 수행하는 Identity middleware(app.UseIdentity) 로 전달된다.
Identity 는 인증되지 않는 request 를 short-circuit 하지 않는다.
Identity 가 request를 인증한다고 하더라고 권한부여(그리고 거부) 은 MVC 가 특정 Controller 와 Action 를 선택한 이후에만 나타난다.

다음 예제는   static file 이 Response 압축 Middleware 이전에 static file middleware 에 의해 처리되도록하는 middleware 의 순서를 정하는 모습을 보여준다.
이 middleware의 순서에서 보면 static file 은 압축되지 않는다.
UseMvcWithDefaultRoute 의 MVC response 는 압축이 가능하다.

 

 

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles();         // Static files not compressed
                                  // by middleware.
    app.UseResponseCompression();
    app.UseMvcWithDefaultRoute();
}

 

 

Run, Map, 그리고 Use

Run, Map, 그리고 Use를 사용하여 HTTP pipeline 을 구성한다.
Run method 는 pipeline을 short-circuit 한다.(즉, next request delegate 를 호출하지 않는다.)
Run 은 규칙이며, 일부 middleware component 는 pipeline 의 마지막에 실행하는 Run[Middleware] method 를 노출할 수도 있다.
Map* extention 은 pipeline 을 분기(branch)하기 위한 규칙으로 사용한다.
Map 은 주어진 request 경로와 일치하는 것을 기반으로 request pipeline 을 분기한다.
만약 request 경로가 주어진 경로로 시작한다면 분기는 실행된다.

 

 

public class Startup
{
    private static void HandleMapTest1(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 1");
        });
    }
 
    private static void HandleMapTest2(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 2");
        });
    }
 
    public void Configure(IApplicationBuilder app)
    {
        app.Map("/map1", HandleMapTest1);
 
        app.Map("/map2", HandleMapTest2);
 
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
        });
    }
}


다음 표는 이전코드를 사용한  http://localhost:1234 의  Request 와 Response 를 보여준다.

 

 Request

 Response

 localhost:1234

 Hello from non-Map delegate.

 localhost:1234/map1

 Map Test 1

 localhost:1234/map2

 Map Test 2

 localhost:1234/map3

 Hello from non-Map delegate.

 

 

Map 이 사용되면 일치하는 경로 segment 는 HttpRequest.Path  에서 제거되고 각 request 의 HttpRequest.PathBase 에 추가된다.
MapWhen 은 주어진 predicate 의 결과를 기반으로 result pipeline 을 분기한다.
Func<HttpContext, bool> type 의 모든 predicate 는 request를 Pipeline 의 새로운 분기에 map 하는데 사용하는 것이 가능하다.
다음 예제에서 predicate 는 Query String 에  branch 가 variable 로 포함되어 있는지 검색하기 위해서 사용된다.

 

public class Startup
{
    private static void HandleBranch(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            var branchVer = context.Request.Query["branch"];
            await context.Response.WriteAsync($"Branch used = {branchVer}");
        });
    }
 
    public void Configure(IApplicationBuilder app)
    {
        app.MapWhen(context => context.Request.Query.ContainsKey("branch"),
                               HandleBranch);
 
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
        });
    }
}

 

 

다음 표는 이전코드를 사용한  http://localhost:1234 의  Request 와 Response 를 보여준다.

 

 Request

 Response

 localhost:1234

 Hello from non-Map delegate.

 localhost:1234/?branch=master

 Branch used = master

 

 

다음 예처럼  Map 은 nesting 을 지원한다.:

 

app.Map("/level1", level1App => {
       level1App.Map("/level2a", level2AApp => {
           // "/level1/level2a"
           //...
       });
       level1App.Map("/level2b", level2BApp => {
           // "/level1/level2b"
           //...
       });
   });

 

 

다음 예제 처럼 Map 은 한번에 다양한 segments 또한 일치(match)시키는데 사용하는 것도 가능하다.:

 

app.Map("/level1/level2", HandleMultiSeg);

 

 

 

내장(Built-in) Middleware

ASP.NET Core 에는 다음 미들웨어 구성 요소들이 들어 있다.

 

 Middleware   

 설명

 Authentication

 인증 지원을 제공한다.

 CORS

 Cross-Origin 자원공유 를 구성한다.

 Response Cahching

 Response Caching 을 위한 지원을 제공한다.

 Response Compressing

 Response 압축을 위한 지원을 제공한다.

 Routing

 request Route를 정의하고 제한한다.

 Session 

 User Session 관리를 위한 지원을 제공한다.

 Static Files

 Static file과 directory Browsing 을 위한 지원을 제공한다.

 URL Rewriting Middleware

 URL rewriting 과 request 의 redirecting 을 위한 지원을 제공한다.

 


Middleware 작성하기
Middleware 는 일반적으로 class 내에서 encapsulate 되어있고 extention method 로 노출된다.
다음은 Query string 으로 부터 현재 request 의 문화권을 설정하는 Middleware 로 살펴보기 바란다.

 

 

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Use((context, next) =>
        {
            var cultureQuery = context.Request.Query["culture"];
            if (!string.IsNullOrWhiteSpace(cultureQuery))
            {
                var culture = new CultureInfo(cultureQuery);
 
                CultureInfo.CurrentCulture = culture;
                CultureInfo.CurrentUICulture = culture;
            }
 
            // Call the next delegate/middleware in the pipeline
            return next();
        });
 
        app.Run(async (context) =>
        {
            await context.Response.WriteAsync(
                $"Hello {CultureInfo.CurrentCulture.DisplayName}");
        });
 
    }
}

 

 

참고 위의 Sample Code 는 middleware component 를 생성하것을 시연하는데 사용된다.
ASP.NET Core 의  내장 localization 에 관해서는 Globalization 과 Localization 을 참고하라.

 

예를 들어, http://localhost:7997/?culture=no 와 같이 culture(문화권 코드)를 전달하여 middleware 를 테스트하는 것이 가능하다.

 



다음 code 는 class 에 middleware delegate 가 Class 로 이동한다.

 

 

using Microsoft.AspNetCore.Http;
using System.Globalization;
using System.Threading.Tasks;
 
namespace Culture
{
    public class RequestCultureMiddleware
    {
        private readonly RequestDelegate _next;
 
        public RequestCultureMiddleware(RequestDelegate next)
        {
            _next = next;
        }
 
        public Task Invoke(HttpContext context)
        {
            var cultureQuery = context.Request.Query["culture"];
            if (!string.IsNullOrWhiteSpace(cultureQuery))
            {
                var culture = new CultureInfo(cultureQuery);
 
                CultureInfo.CurrentCulture = culture;
                CultureInfo.CurrentUICulture = culture;
 
            }
 
            // Call the next delegate/middleware in the pipeline
            return this._next(context);
        }
    }
}

 

 

다음 extension method 는 IApplicationBuilder 를 통해서 middleware 를 노출한다.:

 

using Microsoft.AspNetCore.Builder;
 
namespace Culture
{
    public static class RequestCultureMiddlewareExtensions
    {
        public static IApplicationBuilder UseRequestCulture(
            this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<RequestCultureMiddleware>();
        }
    }
}

 

 

The following code calls the middleware from Configure:

 

 

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.UseRequestCulture();
 
        app.Run(async (context) =>
        {
            await context.Response.WriteAsync(
                $"Hello {CultureInfo.CurrentCulture.DisplayName}");
        });
 
    }
}

 

 

Middleware 는 Constructor 에 의존성(dependencies)를 노출함으로써 명시적 의존성 원칙(Explicit Dependencies Principle) 을 따라야한다.
Middleware 는 Application lifetime 당 한번 생성된다.
Request 내에서  Middleware와 함께 service 를 공유할 필요가 있다면 아래 Pre-request dependency 를 참고하라.
Middleware component 는 constructor parameter 를 사용하여 dependecy injection으로 부터 자신의 dependency 를 해결하는 것이 가능하다.
UseMiddleware<T> 는 추가 parameter 를 직접 허용하는 것도 가능하다.


Per-request dependencies
middleware 가 request 당 생성되는 것이 아닌 app startup 에 생성되었기 때문에 각 request 가 진행되는 동안 middleware constructor 가 사용하는 scoped lifetime service 는 다른 dependency-injected type 과 공유되지 않는다. 
만약 scoped service 를 여러분이 생성한 middleware 와 다른 Type 간에 공유해야만 한다면
이 service 들을 Invoke method 의 Signature 에 추가하라.
Invoke method 는 dependency injection 에 의해 채워지는 추가 parameter 를 수락하는 것이 가능하다.

 

 

public class MyMiddleware
{
    private readonly RequestDelegate _next;
 
    public MyMiddleware(RequestDelegate next)
    {
        _next = next;
    }
 
    public async Task Invoke(HttpContext httpContext, IMyScopedService svc)
    {
        svc.MyProperty = 1000;
        await _next(httpContext);
    }
}

 

 

Resources
· Sample code used in this doc
· Migrating HTTP Modules to Middleware
· Application Startup
· Request Features

 

 

 

 

행복한 고수되십시요.

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'.NET > ASP.NET Core' 카테고리의 다른 글

[ASP.NET Core] MiddleWare  (0) 2017.07.10
[ASP.NET Core] Application Startup  (0) 2017.06.11
Posted by woojja

다음은 Application Startup in ASP.NET Core hDocs.microsoft.com/en-us/aspnet/core/fundamentals/startup) 의 내용을 번역했습니다.

 

.

 

 

Application Startup in ASP.NET Core

 

Startup Class 는 응용 프로그램에 대한 모든 Request 를 처리하는 Request pipeline을 구성한다.

Startup Class

ASP.NET Core Apps 는 Startup class 를 필요로한다.. 관례상 Startup class 는 "Startup" 이라 부른다.

Main program WebHostBuilderExtensions 의  UseStartup<Tstartup> method 내에 startup class 이름을 지정한다.

 

다양한 환경에 대해 별도의 Startup class 를 구성하는 것도 가능하며, runtime 이 그 중 적합한 하나를 선택하게된다.

WebHost Configuration 이나 Option 에서 StartAssembly 를 지정한다면 Hosting 은 지정한 startup assembly 를  Load 하고 Startup 이나 Startup[Environment] Type 을 검색한다.

 

StartupLoader 의 FindStartupType다양한 환경에서의 작업 (Working with multiple environment) 을 참조하자.

UseStartup<TStartup> 를 사용한 접근을 권장한다.

 

Startup class 의 생성자는 dependency injection 을 통해 제공하는 종속성을 수락하는 작업이 가능하다.

IHostingEnvironment 를 사용한 Configuration 소스를 구성하는 작업이 가능하고, ILoggerFactory 를 사용하여  Logging Provider 를 구성하는 작업이 가능하다.

 

Startup class 는 Configure Method 를 반드시 포함해야하며 선택적으로 ConfigureServices Method 를 포함하는 것이 가능하다. 이 두 Method 는 Application 이 시작할 때 호출된다.

이 Class 는 이 Method 의 환경별 (environment-specific) 버전을 포함하는 것 또한 가능하다. 

 

Application startup 동안 예외처리 에 대해 배워보자.

 


Configure Method


Configure Method 는 ASP.NET application 이 HTTP Request 에 대해 Respond 하는 방법을 지정하는데 사용한다. request pipeline 은 dependency injection 에 의해 제공되는 IApplicationBuilder 에 추가되는 middleware  를 추가하므로써 구성된다.

 

default web site template 를 이용한 다음 예제에서 몇가지 확장 Method 들이 BrowserLink, 오류페이지, 정적파일, ASP.NET MVC, Identity 들을 지원하는 pipeline 을 구성하는데 사용된다.

 

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();
 
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
        app.UseBrowserLink();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }
 
    app.UseStaticFiles();
 
    app.UseIdentity();
 
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

 

각 Use 확장 메소드는 request pipeline 에 middleware component 를 추가한다.

예를 들어, UseMvc 확장 메서드는 routing middleware 를  request pipeline 에 추가하고 MVC 를 기본 handler로 구성한다.


IApplicationBuilder를 사용하는 방법에 대한 자세한 정보는 Middleware 를 살펴보자.

IHostingEnvironment 와 ILoggerFactory와 같은 추가적인 서비스도 method signature 에 지정할 수 있으며, 이 경우 이 서비스들은 사용가능하다면 삽입(injected)될 것이다.

ConfigureServices method

ConfigureServices method 는 선택 사항이다. 하지만 사용될 경우 runtime 에 의해 Configure method 보다 먼저 호출된다. (일부 기능은 request pipeline 에 연결되기 전에 추가된다).

Configuration option 은 이 method 에 설정된다.


실질적인 Setup 이 필요한 기능들은 IServiceCollection 의 Add[Service] Extension method 다.

default web site template 를 이용한 다음 예제는  Entity Framwork, Identity, MVC 를 위한 Service 를 사용하기위해 app 을 구성한다.

 

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
 
    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores<ApplicationDbContext>()
        .AddDefaultTokenProviders();
 
    services.AddMvc();
 
    // Add application services.
    services.AddTransient<IEmailSender, AuthMessageSender>();
    services.AddTransient<ISmsSender, AuthMessageSender>();
}

 

service container 에 서비스를 추가하는 작업은 dependency injection 을 통해 application 내에서 Service 를 사용할 수 있다.

 

Startup 에서 사용가능한 Service

 

ASP.NET Core 의 dependency injection 은  application 의 startup 동안 여러 application service 를 제공한다.

Startup class 의 생성자나 Startup class 의 Configure 나 ConfigureService method 중 한 method 의 parameter 로 적당한 Interface 를 추가함으로써 이런 Service 를 요청하는 것이 가능하다.

 

Startup class 의 각 method 를 호출되는 순서대로 살펴보면, 다음 Service 들이 parameter 로 요청될 것이다.

• Constructor 에서 : IHostingEnvironment, ILoggerFactory
• ConfigureServices method에서 : IServiceCollection
• Configure method 에서 : IApplicationBuilder, IHostingEnvironment, ILoggerFactory, IApplicationLifetime

 

추가 자료

 

이제 제 공부차원에서 https://docs.microsoft.com/en-us/aspnet/core 에 있는 내용들을 하나씩 올려보려고 합니다.

 

행복한 고수되십시요.

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 

 













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'.NET > ASP.NET Core' 카테고리의 다른 글

[ASP.NET Core] MiddleWare  (0) 2017.07.10
[ASP.NET Core] Application Startup  (0) 2017.06.11
Posted by woojja
2017.05.31 18:08

 

안녕하셔요?

Object  instance 의 Copy 에 대해서 알아보려고 합니다.

Clone 이죠.

 

Object 를 "=" 을 사용해서 대입하면 주소값이 들어가므로 그 값들을 다른 instance로 복사하기 위한 작업입니다.

 

Key Point 는 "ICloneable" interface 를 구현한다는 것인데요.

바로 Source 를 보도록 하겠습니다.

 

 

  1. public class MyBuffer : ICloneable
  2. {
  3.     public int id;
  4.     public List<String> items;
  5.  
  6.     public MyBuffer()
  7.     {
  8.         id = 0;
  9.         items = new List<String>();
  10.     }
  11.  
  12.     public bool IsEmpty
  13.     {
  14.         get { return items.Count == 0; }
  15.     }
  16.  
  17.     public void Clear()
  18.     {
  19.         id = 0;
  20.         items = new List<String>();
  21.     }
  22.  
  23.     public MyBuffer Clone()
  24.     {
  25.         return (MyBuffer)this.MemberwiseClone();
  26.     }
  27.  
  28.     object ICloneable.Clone()
  29.     {
  30.         return Clone();
  31.     }
  32. }

 

 

이 녀석을 호출하는 것도 살펴봐야겠죠?

 

 

  1. public MyBuffer SomeFunction()
  2. {
  3.     MyBuffer myBuffer = new MyBuffer();
  4.     myBuffer.id = 0;
  5.     myBuffer.items.Add("AAA");
  6.     myBuffer.items.Add("BBB");
  7.     myBuffer.items.Add("CCC");
  8.     myBuffer.items.Add("DDD");
  9.     MyBuffer cloneBuffer = myBuffer.Clone();
  10.     myBuffer.Clear();
  11.     return cloneBuffer;
  12. }

 

 

글자 보기가 조금 그렇네요. ㅡㅡ;

Copy As Html 기능을 사용한건데 VisualStudio 테마으 글자 색을 따라가다 보니 저렇게 나오는 듯합니다.

CSS 를 한번 살펴봐야겠군요.

 

 

행복한 고수되셔요. ^^;

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja
TAG .NET, CLONE

오래된 Error Message 를 소개하고자 합니다. ^^;

 

"Collection was modified; enumeration operation may not execute."

 

위 Message 는 한글 에러로는

"컬렉션이 수정되었습니다. 열거 작업이 실행되지 않을 수도 있습니다." 라는 에러로 나타납니다.

 

foreach (VB.NET 의 경우 For Each) 문은 IEnumerable, IEnumerable<T> 를 구현한 배열이나 컬렉션의 요소들을 반복하여 접근하는 작업을 합니다만

For Each 반복과정에서 배열이나 Collection 의 변경이 생기는 경우 내부에서 사용하는 iterator 가 무효화 되어 사용할 수 없게되어 InvalidOperationException 이 발생하게 됩니다.

 

따라서 For Each 작업을 하기 위해서는 For 문을 사용하거나

반복에 사용할 대상을 미리 List 로 취합한뒤 그 List 를 대상으로 작업을 하시기 바랍니다.

 

 

행복한 고수되십시요.

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja

Pro ASP.NET MVC 5 를 정리하고 있습니다.


SportsStore Site 를 작성하면서  필요한 Nuget Package 들 입니다.


Install-Package Ninject -version 3.0.1.10 -projectname SportsStore.WebUI
Install-Package Ninject.Web.Common -version 3.0.0.7 -projectname SportsStore.WebUI
Install-Package Ninject.MVC3 -Version 3.0.0.6 -projectname SportsStore.WebUI
Install-Package Moq -version 4.1.1309.1617 -projectname SportsStore.WebUI


Install-Package Ninject -version 3.0.1.10 -projectname SportsStore.UnitTests
Install-Package Ninject.Web.Common -version 3.0.0.7 -projectname SportsStore.UnitTests
Install-Package Ninject.MVC3 -Version 3.0.0.6 -projectname SportsStore.UnitTests
Install-Package Moq -version 4.1.1309.1617 -projectname SportsStore.UnitTests
Install-Package Microsoft.Aspnet.Mvc -version 5.0.0 -projectname SportsStore.UnitTests


Install-Package Microsoft.Aspnet.Mvc -version 5.0.0 -projectname SportsStore.Domain



행복한 고수되십시요.


woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja
2017.02.10 11:07

조금 늦은 정보이지만

 

ASP.NET Core 를 살펴보다가 Raspberry Pi 에 포팅에 대한 기사를 보았고 이에 대한 정보를 찾았다.

 

.NET Core Roadmap

 

 

2017년 1분기내에는 올라간다고 하니 그전에 Raspberry Pi 에 친해져야겠다. ㅋㅋㅋ

 

 

모두 행복한 고수되셔요~~

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja

Visual Studio 2015 Enterprise with Update 3 설치시 계속 에러가 발생하여 설치가 되지 않는 상황이 발생했다.


해결책을 검색하다가 겨우 찾은 해결책...



http://stackoverflow.com/questions/34889317/error-installing-visual-studio-2015-enterprise-update-1-with-team-explorer




아래 내용은 위 링크 페이지의 핵심 내용을 적습니다.

The actual solution

  1. Uninstall Visual Studio 2015 Enterprise from Programs and Features
    • I also uninstalled the 2015 C++ runtimes and Entity Framework 2015 libraries as well
  2. Reboot machine if prompted
  3. Rename or delete folders-
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0
    • C:\Program Files\Microsoft Visual Studio 14.0
    • C:\users\user\Documents\Visual Studio 2015
    • C:\users\user\AppData\Roaming\Microsoft\VisualStudio\14.0
    • C:\users\user\AppData\Local\Microsoft\VisualStudio\14.0
    • C:\users\user\AppData\Local\Microsoft\VSCommon\14.0
  4. Go to the registry editor (start >> run >> regedit) and remove/rename the following registries-
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0
    • HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0
    • HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config
  5. close all your Visual Studio instances
  6. download Visual Studio 2015 Enterprise RTM not update 1
  7. Extract the .iso file by using an extraction tool, such as WinRar.
  8. Clear %temp% before going to start Visual Studio 2015 installation
  9. Install Visual Studio 2015 using this extracted setup installer

And... tada, the installation was finally successful! I hope this helps others that have a similar issue that isn't resolved by repairing the C++ runtimes alone.

Once RTM was installed successfully I was able to run the Update 1 installer and update successfully. Since then, I have also installed Update 2 with no issues.




Batch File



@echo.
@echo This will remove all files, directories and registry keys about VISUAL STUDIO 2015
@echo.
@pause

rd "C:\Program Files (x86)\Microsoft Visual Studio 14.0" /S
rd "C:\Program Files\Microsoft Visual Studio 14.0" /S
rd "C:%homepath%\Documents\Visual Studio 2015" /S
rd "C:%homepath%\AppData\Roaming\Microsoft\VisualStudio\14.0" /S
rd "C:%homepath%\AppData\Local\Microsoft\VisualStudio\14.0" /S
rd "C:%homepath%\AppData\Local\Microsoft\VSCommon\14.0" /S

@echo.
@echo Removing Registry Keys
@pause

REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0
REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0
REG DELETE HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0
REG DELETE HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config

@echo.
@echo. FINISHED!
@pause




행복한 고수되십시요. ^^


woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\


 

파일 첨부 :

install.bat

 













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja


ViewBag, TempData, ViewData, Session 의 수명



행복한 고수되십시요.


woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\













저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by woojja