정리하며 배우다.

프로젝트를 진행하다가 보면, 얘기치 않게 SVN 저장소 주소가 변경되기도 하는데요. 

초기에는 시스템을 크게 생각하지 않고, 뜻밖의 이사나 부득이한 장비 변경등으로 인해서 줄곳 저장소 주소가 변경되기도 합니다. 이를 예방하기 위해서는 도메인 주소를 이용하면 좋지만, 대부분 프로젝트에서는 IP를 이용한 주소체계를 사용하다 보니 빈번히 발생하게 됩니다. 

Tortoise SVN 사용시 주소 변경하는 법이 어렵지는 않지만 정리하였습니다. 

1. TortoiseSVN Relocate 이용

SVN 저장소에서, 마우스 오른쪽 버튼 클릭시, TortoiseSVN에 대한 메뉴가 보여지는데요. 

해당 메뉴 중 "Relocate" 메뉴를 선택하게 되면, 해당 저장소의 URL 이 보여지게 되는데요.

2. 주소변경

"Relocate" 메뉴 선택시 URL 변경 창이 나오며, 현재 URL 정보도 같이 보여지게 됩니다. 

"From URL" 을 확인 하시고, 변경하려는 URL을 "To URL" 부분에 적어주면 정상적으로 URL 변경이 가능합니다. 

주소 변경시, 내부적으로 사용중인 외부 참조 URL이 있다면 해장 영역도 같이 변경되어야 합니다~~

참조

END

프로젝트를 한번 생성해서 개발을 하다가 새로운 버전의 프레임워크가 나오면, 속성에서 대상 프레임워크만 변경을 해주곤 했었는데요. 이런저런 테스트를 위해서 ASP.NET Core 6의 웹앱 템플릿을 새로 생성하는 과정에서 기존과는 다르게 Startup.cs 가 생성이 안되고, Configure 종속성도 보이질 않아서 찾아보던중에 최소 호스팅 모델에 대해서 알게되어 정리합니다. 추가로 ASP.NET Core 6 환경에서 지속적으로 사용하던 Startup 과 Configure 종속성 주입에 대해서도 같이 정리하였습니다. 

1. 최소 호스팅 모델

ASP.NET Core 앱의 새 .NET 6 최소 호스팅 모델에는 파일 하나와 몇 줄의 코드만 필요합니다. 

6.0으로 마이그레이션하는 앱은 새 최소 호스팅 모델을 사용할 필요가 없습니다.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

최소 호스팅 모델:

• 앱을 만드는 데 필요한 파일 수와 코드 줄이 대폭 줄어듭니다. 코드 4줄과 함께 파일이 하나만 있으면 됩니다.
• Startup.cs 및 Program.cs를 단일 Program.cs 파일로 통합합니다.
• 최상위 문을 사용하여 앱에 필요한 코드를 최소화합니다.
• 전역 using 지시문을 사용하여 필요한 using 문의 줄 수를 없애거나 최소화합니다.

2. ASP.NET Core 5 의 구성

ASP.NET Core 5 에서 프로젝트 생성시 아래와 같은 구성으로 템플릿이 생성이 되는데요.

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

namespace WebAppRPv5
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddRazorPages();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
            });
        }
    }
}

Startup.cs

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

namespace WebAppRPv5
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

Program.cs

Startup.cs와 Program.cs 파일이, ASP.NET Core 6 에서 아래의 형태의 코드로 대체 됩니다. 

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

위의 ASP.NET Core 6 샘플에서는 다음 방법을 보여 줍니다.

• ConfigureServices가 WebApplication.Services로 바뀝니다.
• builder.Build()가 변수 app에 대해 구성된 WebApplication을 반환합니다. Configure는 app을 사용하여 동일한 서비스에 대한 구성 호출로 대체됩니다.

3. 최소 호스팅 모델에서 Startup 사용하기

namespace WebApp4
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

ASP.NET Core 6의 WebApplication 을 생성시 위와 같은 형태의 템플릿이 구성이 되는데요. 

기존에 보아왔던 Startup.cs 파일은 더이상 생성 되지 않습니다. 

ASP.NET Core 5에서 사용하던 Startup Class 를 지속적으로 사용하기 위해서는 추가 마이그레이션 작업을 진행해야하는데요. 

    public class Startup 
    {
        public IConfiguration Configuration { get; }

        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddRazorPages();
        }


        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (!env.IsDevelopment())
            {
                app.UseExceptionHandler("/Error");
                app.UseHsts();
            }
            
            app.UseStaticFiles();

        }

    }

프로젝트마다 구성은 다르겠지만, 기본적으로 위와같은 형태로 기존의 Startup Class 를 생성해 줍니다.

// Add services to the container.
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);

그리고 위치는 다르겠지만, Startup Class 에 Configure 종속성을 수동으로 삽입해주면 되는데요.

이렇게 되면, 기존 ASP.NET Core 5 에서 사용하던 구성대로 ASP.NET Core 6 로 마이그레이션이 가능합니다. 

4. ASP.NET Core 5 및 6 호스팅 모델의 차이점

• 개발 모드에서 개발자 예외 페이지 미들웨어는 기본적으로 사용하도록 설정되어 있습니다.
• 앱 이름은 기본적으로 진입점 어셈블리의 이름인 Assembly.GetEntryAssembly().GetName().FullName으로 지정됩니다. 라이브러리에서 WebApplicationBuilder를 사용하는 경우 앱 이름을 라이브러리의 어셈블리로 명시적으로 변경하여 MVC의 애플리케이션 파트 검색이 작동되도록 합니다. 
• 엔드포인트 라우팅 미들웨어는 전체 미들웨어 파이프라인을 래핑하므로 경로를 등록하기 위해 UseRouting 또는 UseEndpoints에 대한 명시적 호출이 필요하지 않습니다. UseRouting은 경로 일치가 발생하는 위치를 지정하는 데 계속 사용할 수 있지만 미들웨어 파이프라인의 시작 부분에서 경로가 일치해야 하는 경우 UseRouting을 명시적으로 호출할 필요는 없습니다.
• 파이프라인은 IStartupFilter가 실행되기 전에 생성되므로 파이프라인을 빌드하는 동안 발생한 예외는 IStartupFilter 호출 체인에 표시되지 않습니다.
• EF 마이그레이션과 같은 일부 도구는 앱의 컨텍스트에서 사용자 지정 논리를 실행하기 위해 Program.CreateHostBuilder를 사용하여 앱의 IServiceProvider에 액세스합니다. 이러한 도구는 앱의 컨텍스트에서 사용자 지정 논리를 실행하는 데 새 기술을 사용하도록 업데이트되었습니다. 이런 식으로 Program.CreateHostBuilder를 사용하는 도구로 Entity Framework 마이그레이션이 있습니다. 새 모델을 사용하도록 도구가 업데이트되었는지 확인하고 있습니다.
• 클래스와 Startup 달리 최소 호스트는 서비스 공급자를 인스턴스화할 때 DI 범위를 자동으로 구성하지 않습니다. 범위가 필요한 컨텍스트의 경우 IServiceScopeFactory.CreateScope를 사용하여 호출 IServiceScope 하여 새 범위를 인스턴스화해야 합니다.
• WebApplicationBuilder를 만든 후에는 앱 이름, 환경 또는 콘텐츠 루트 같은 호스트 설정을 변경할 수 없습니다. 호스트 설정을 변경하는 방법에 대한 자세한 내용은 IHostBuilder 또는 IWebHostBuilder 사용자 지정을 참조하세요. 다음의 강조 표시된 API는 예외를 throw합니다.

참조

https://learn.microsoft.com/ko-kr/aspnet/core/migration/50-to-60?view=aspnetcore-6.0&tabs=visual-studio

END

1. Linq OrderBy()를 사용해서 목록 섞기

public static List<string> Shuffle(List<string> values)
{
    Random rand = new Random();
    var shuffled = values.OrderBy(_ => rand.Next()).ToList();

    return shuffled;
}

Linq의 OrderBy() 메소드를 이용하면, 지정된 비교자를 사용하여 시퀀스의 요소를 정렬합니다.

Random()을 사용해서 순서를 무작위로 섞기 위해 위와 같이 메소드를 구성 할 수 있는데요.

static void Main(string[] args)
{
    List<string> values = new List<string>() { "A", "B", "C", "D", "E" };
    var valuse2 = EtcUtil.Shuffle(values);
    foreach (var item in valuse2)
    {
        Console.WriteLine(item);
    }
}

저는 Method를 구성해서 호출하는 방식을 이용했고, 위와같이 호출하면, 아래의 출력결과를 얻을 수 있습니다. 

출력 : 

2. Fisher-Yates Shuffle 알고리즘을 사용하여 목록 섞기

public static class Extensions
{
    private static Random random = new Random();

    public static void Shuffle<T>(this IList<T> values)
    { 
        for (int i = values.Count - 1; i > 0; i--) 
        {
            int k = random.Next(i + 1);
            T value = values[k];
            values[k] = values[i];
            values[i] = value;
        }
    }
}

Fisher-Yates 셔플 알고리즘은 C#에서 데이터 구조를 Shuffle합니다.  

Fisher-Yates 셔플 알고리즘은 Random.Next() 함수를 사용해 얻은 인덱스값(k)을 현재의 순서 (i) 와 바꿔주는 역활을 합니다. 이 경우 편향되지 않은 배열을 생성해주며, 시간 복잡도 O(n) 으로 빠른편에 속합니다. 

위의 코드는 C#에서 Fisher-Yates 셔플 알고리즘을 사용하여 목록을 셔플하는 방법을 보여줍니다.

static void Main(string[] args)
{

    List<int> values = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    values.Shuffle();

    foreach (var item in values)
    {
        Console.WriteLine(item);
    }
}

static Method 를 이용해서 구현했고, Shuffle() Method 에 this 인자를 이용해서 구성하였기 때문에, 

외부 함수를 맴버 함수처럼 호출 할 수 있게 해줍니다. 

그래서 Extension Method 의 느낌을 더 잘 나타낼수 있습니다. 

출력 : 

참조

https://www.delftstack.com/ko/howto/csharp/shuffle-a-list-in-csharp/

https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle

END

아래 사이트에서 얘기하는 IISRESET을 사용하지 말아야 하는 이유에 대해서는, 
점검 시간이 보장이되고 있는 케이스라면, 크게 신경쓰지 않아도 될 듯 합니다.
또한, 사전에 유저의 진입을 차단할 수 있는 프로세스를 갖춘 웹사이트라면 신경쓰지 않아도 됩니다. 
개선된 IISRESET 명령을 이용하면, 충분히 개선이 될 것으로 생각이 됩니다. 

하지만, 어떠한 이유에서 IISRESET 대신, 다른 명령어를 사용하라는것인지 핵심은 한번쯤 읽어볼만해서 정리하였습니다.
또한, 하나의 IIS 웹서버를 이용해사 다중의 웹사이트를 이용하고 있는 사용자라면, 한번쯤은 참고하셔도 좋을 내용입니다.

IISRESET - IIS를 다시 시작하는 최악의 방법

해당 웹사이트 번역글입니다.

IISRESET

IISRESET은 IIS 서비스를 다시 시작하는 데 사용되는 잘 알려진 도구입니다.
불행히도 이는 가장 큰 문제이기도 합니다.

구성 변경 사항을 선택하거나 잘못된 동작을 하는 IIS 웹 사이트를 재설정하는 데 종종 사용됩니다.
이는 웹사이트의 가용성과 서버의 전반적인 안정성을 적극적으로 손상시킵니다.
이 게시물에서는 이러한 경우가 발생하는 이유와 IISRESET이 IIS 서비스에 어떤 영향을 미치는지 자세히 살펴보겠습니다.

IIS를 재설정하고, 응용 프로그램을 다시 시작하고, 응용 프로그램 풀을 재활용하는 올바른 방법에 대해 자세히 알아보려면 IIS 재설정, 다시 시작 및 재활용 가이드를 참조하세요.

IISRESET을 사용하여 IIS를 다시 시작하면 웹 서버에 어떤 영향을 미치는지 자세히 알아보기 전에 IISRESET이 사용되는 이유를 검토해 보겠습니다.

IISRESET 명령의 히스토리

IISRESET은 Windows Server 2003에 IIS 6.0이 출시되기 이전에 사용되던 명령어입니다.

IIS 5.0 및 이전버전의 IIS에서는 웹 서버가 모놀리식 단일 프로세스 였습니다. 응용프로그램에서 발생할 수 있는 성능 문제를 해결하기 위해 IIS 를 다시 시작 명령이 필요했습니다.

IIS 6.0 에서는 응용프로그램 풀 아키텍처를 도입했습니다.

요청 수신을 담당하는 IIS 시스템 프레임워크(Http.sys 커널 드라이버, W3SVC 리스너 서비스)에서 

웹사이트 응용 프로그램 코드 (호스팅에서 IIS 워커 프로세스, w3wp.exe)가 분리되었습니다. 

그래서, 응용프로그램 재시작할 경우 iisreset.exe 가 더이상 필요하지 않습니다. iis를 재시작하는 쉬운방법으로는 남아있지만, 과도한 방법입니다.

IISRESET 명령이 사용되는 이유는

1. Configuration 을 변경하기 위해

• IIS 7.0 이상 모든 IIS 서비스는 Configuration 변경 및 응용프로그램 콘텐츠 변경을 자동으로 감시하고 적용합니다. 
• 이러한 변경 사항은 자동으로 처리되고, 응용 프로그램 또는 응용프로그램 풀이 다시 시작됩니다.
• 즉, IISRESET 을 사용해서, configuration 변경 사항을 선택할 필요는 없습니다.
• IISReset의 사용은 IIS 6.0과 같은 IIS의 이전 버전에서 권장되었으며 IIS 7.0, IIS 7.5 또는 그 이후 버전에서는 지원되지 않습니다. https://techcommunity.microsoft.com/t5/iis-support-blog/iisreset-internals/ba-p/951578

2. 성능 및 안정성 문제를 복구하기 위해

• 웹사이트가 정지가 되었거나, 성능적으로 문제가 있는 웹사이트를 복구하기위해 사용됩니다.

다시 시작하는 것이 전술적으로 유익한 경우에도, IIS 를 재 설정하는 것은 올바른 방법이 아닙니다. 
대신 올바른 응용 프로그램 풀을 이용해서 재활용 하는 것이 좋습니다. 
응용프로그램풀을 재활용 하는 것은 아래와 같이 막대한 이점이 있습니다. 

- 해당 응용 프로그램 풀에만 영향을 미칩니다.
- 중첩된 IIS 재활용을 통해 제로 다운타임 재시작합니다.
- 전체 워밍업으로 다시 시작하는 기능에 지연이 없습니다.
- 다른 웹사이트에 영향이 없습니다.  (다중 웹사이트 운영시)
- 웹서버 전체에 잠재적인 결과가 없습니다.

IISRESET 작동방식

가장 정확한 비유는 서버에서 전원 코드를 뽑아 특정 어플리케이션을 닫는 것이다. 
최소한 서버를 다시 사용하려면, 서버가 다시 부팅 될 때 까지 기다려야 한다.
아래 이미지는 IISRESET을 사용할 때 대략적으로 일어나는 일입니다.

1. Windows 정품 인증 서비스 (WPAS)인 WAS 를 중지하려고 시도합니다.
2. W3SVC를 포함하여 WAS에 의존하는 모든 서비스가 중지됩니다.
3. WAS는 모든 활성 응용 프로그램 풀을 중지하려고 시도합니다.
4. 이는 WAS가 중지되는 동안, 서버의 각 웹사이트에 대한 모든 수신요청이 503 Sevice Unavailable 을 반환하기 시작함을 의미합니다.
5. 이제 모든 IIS 작업자 프로세스가 중지되기를 기다리고 있습니다. shutdownTimeLimit(기본 90초)
6. 작업자 프로세스가 이 시간내에 중지되지 않으면 종료됩니다.
7. 마지막으로 90초 정도 후에 WAS 가 중지됩니다.
8. 그런 다음 IISRESET은 WAS 및 W3SVC 를 다시 시작하려고 시도합니다.

즉, IISRESET이 WAS가 중지될 때 까지 대기 시간이 초과되지 않는 한 WAS를 강제로 종료합니다.

이 경우 명령이 실패하고, 중지된 IIS 서비스를 다시 시작하지 못하여, 웹서버가 영구적으로 비활성화 될 수 있습니다.

IISRESET 이 웹서버 가용성을 해치는 방법

1. IISRESET으로 인해 웹사이트가 중단됨

IISRESET으로 가장 먼저 발생하는 일은 W3SVC 서비스가 중지된다는 점입니다.

즉, 웹사이트 바인딩을 듣는 사람이 없고, 연결이 거부 됩니다. 이는 해당 서버의 모든 웹사이트에서 즉시 발생합니다.

2. IISRESET은 전체 서버에 긴 다운타임을 일으킴

IISRESET이 특정 웹 사이트 또는 응용 프로그램 풀을 대상으로 하지 않기 때문에, 시스템의 모든 응용 프로그램 풀을 중지한다는 것입니다. 

즉, 모든 웹사이트의 중단 시간은 응용 프로그램 풀의 작업자 프로세스가 현재 실행 중인 요청을 완료하는 데 걸리는 가장 긴 시간입니다(종료 시간 제한까지).

왜냐하면, 성능 문제가 있을때, IIS 재시작을 가장 자주 재설정 하기 때문에, 이러한 요청이 완료하는데 매우 오랜 시간이 걸릴 가능성이 높습니다. 따라서 IISRESET을 호출할 때 마다 전체 90초 지연이 예상됩니다.

3. 서버를 중지 상태로 남을 수 있습니다.

IISRESET 에는 기본제한시간이 20초입니다. 기본 응용 프로그램 풀 종료 시간 제한과 같은 90초가 아닙니다.

이는 활성 시스템의 IISRESET 이 WAS가 중지되기 전에 매번 시간 초과됨을 의미합니다. 강제로 WAS 종료를 시도하게 됩니다.

이로 인해 IISRESET을 관리자 권한으로 실행하는 경우에도, IISRESET에 권한 오류가 발생 할 수 있습니다.

Attempting stop...
Stop attempt failed.
Access denied, you must be an administrator of the remote computer to use this command. 
Either have your account added to the administrator local group of the remote 
computer or to the domain administrator global group.

결과적으로 WAS 및 W3SVC 서비스가 이제 중지되고 서버가 영구적으로 다운됩니다.

IISRESET NOFORCE 명령을 사용하고 있다고 가정해 보겠습니다 .

/NOFORCE 명령은 시간 제한을 소진하고 서비스를 종료하지 않고 중지하여 동일한 중지 상태가 됩니다.

개선된 IISRESET 명령

IISRESET을 사용해야 하는 경우, IIS 7.0 이상에서 사용할 수 있는 실패 위험이 낮은 IIS cmd는 다음과 같습니다.

iisreset /stop /timeout:60
taskkill /F /FI "SERVICES eq was"
iisreset /start

이것이 더 잘 작동하는 이유는 기본 IIS 재시작 cmd에서 발생하는 "액세스 거부" 오류를 방지하기 때문입니다.

더 긴 시간 초과를 사용하여 작동한 다음 IISRESET 중지가 시간 초과되면 WAS를 완전히 종료하고 나중에 다시 시작해야 합니다.

이렇게 하면 웹 서버가 영구적으로 다운되는 것을 방지할 수 있습니다.

4. IISRESET을 사용하면, 성능문제를 해결 할 수 없습니다.

서버중단, 높은 CPU, 메모리 누수, 성능 저하는 IISRESET으로 해결 할 수 없습니다. 
서버에 대한 로직을 검증하는 방법으로 수정해야 합니다.

5. 중복 재활용 및 100% 예열의 이점을 거부합니다.

진지하게. 손상되었거나 어려움을 겪고 있는 응용 프로그램 풀을 다시 시작하려는 경우 재활용 방법은 대신 중단 시간이 없고 완전히 예열되며 시작 지연이 없는 다시 시작을 허용합니다.

결론

IIS가 서버를 재설정할 필요가 없으니, IISRESET 을 사용하지 마세요.

이로 인해서 웹사이트 가동 중단 시간이 길어지고, 웹 서버가 작동할 수 없는 상태가 될 수 있습니다.

대신 IIS 서비스를 적절하게 다시 시작하는 방법을 알아보고, Zero 시작 지연 작업을 위해 웹사이트를 구성하는 방법에 대해서 알아보세요.

참조

https://www.leansentry.com/guide/reset-restart-recycle-iis/dangers-of-iisreset#to-recover-from-performance-or-stability-issues

END

프로그램을 개발하면서 소소하게 많이 접하게 되는것이 문자열관련, 날짜관련이 아닐까 싶은데요. 그중 Log 성 데이터를 다루다 보면 문자열 관련된 내용이 꼭 필요하게 됩니다. Log와 관련된 내용을 좀더 가독성이 좋게 만들면 좋을 거 같아서 보간을 이용한 간격을 맞췄는데요. 진행한 김에 같이 정리하였습니다. 

1. string.Format 을 이용한 문자열 출력

string.Format() 의 메소드 매개변수 형식은 아래와 같은데요.

{첨자, 맞춤:서식 문자열}

해당 메소드를 이용하면 위와같은 형태로 문자열을 출력할 수 있습니다. 

2. PadRight() PadLeft() 를 이용한 간격맞춤

간혹 문자열의 간격을 조정해야 하는 상황이 발생하게 되는데요. 

이때는 PadRight(), PadLeft() 메소드를 이용하시면 우측간격과, 좌측간격을 조정해서

위와 같은 형태로 출력화면을 컨트롤 할 수 있는데요.

3. $을 이용한 문자열 보간

$ 문자는 문자열 리터럴을 보간된 문자열로 식별합니다. 보간된 문자열은 보간 식이 포함될 수 있는 문자열 리터럴입니다. 보간된 문자열이 결과 문자열로 해석되면 보간 식이 있는 항목이 식 결과의 문자열 표현으로 바뀝니다.

var name = "Mark";
var date = DateTime.Now;

// Composite formatting:
Console.WriteLine("Hello, {0}! Today is {1}, it's {2:HH:mm} now.", name, date.DayOfWeek, date);
// String interpolation:
Console.WriteLine($"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.");
// Both calls produce the same output that is similar to:
// Hello, Mark! Today is Wednesday, it's 19:40 now.

C# 10부터 보간된 문자열을 사용하여 상수 문자열을 초기화할 수 있습니다. 보간된 문자열 내의 모든 보간 식이 상수 문자열인 경우에만 이 작업을 수행할 수 있습니다.

4. 보간을 이용한 출력

위 예제에서는 string.Format() 메소드를 이용했지만, 보간을 이용하면 간단하게 구문을 줄 일 수 있습니다. 

앞에 $ 리터럴 문자만 넣어주시면 보간을 이용 할 수 있는데요. 

코딩에 대한 부분이 간편해진 것을 볼 수 있습니다. 

5. 보간을 이용한 간단한 줄맞춤 서식

PadRight(), PadLeft() 메소드도 보간을 이용하면, 간편하게 +/- 정수형을 이용해서 좌측/우측 간격을 조절할 수 있어서 간편하게 이용할 수 있습니다. 

참조

END

Linux는 버전에 대한 영향을 받는 OS 이다 보니, 이전에 설치한 버전을 확인해야 하는 경우가 빈번히 발생을 하는데요. 이때 알아두면 좋을 명령어 및 방법을 정리하였습니다. 

01. uname -a

$ uname -a 옵션의 경우 모든 정보를 출력하는데요. --help 옵션으로 확인시 -a 옵션을 제외한 내용들이 순차적으로 출력이 됩니다. 

Linux localhost.localdomain 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

커널이름 -s : Linux

호스트이름 -n : localhost.localdomain

커널릴리즈 -r : 3.10.0-957.el7.x86_64

커널 버전 -v : #1 SMP Thu Nov 8 23:39:32 UTC 2018

하드웨어 -m : x86_64

프로세스 타입 -p : x86_64

하드웨어 플랫폼 -i : x86_64

운영체제 -o : x86_64 GNU/Linux

의 순서로 출력이 됩니다. 

02. os-release 파일을 이용한 버전확인

다음은 os-release 파일을 이용해서도 버전 정보를 확인 할 수 있는데요. 

아래 두가지 명령어로 확인이 가능합니다.

$ cat /etc/os-release

$ grep . /etc/os-release

03. hostnamectl 을 이용한 버전확인

hostnamectl 명령어를 이용해서도 버전을 확인할 수 있습니다. 

hostnamectl 명령어는 호스트에 대한 정보 및 호스트 이름을 변경할 때 사용하는 명령어 인데요. 

상태를 확인 할때도 사용하게 됩니다. 

$ hostnamectl status

status 옵션은 생략가능한 기본 옵션이여서, 호스트 정보를 확인 할 때 사용도 되지만, OS 및 버전정보도 같이 보여주기 때문에 해당명령어를 이용해서도 버전정보를 확인 가능합니다. 

04. lsb_release -a

lsb_release 명령어는 리눅스의 배포판 버전을 확인하는 명령어 입니다. 

아래와 같은 명령어로 확인이 가능합니다. 

$ lsb_release -a

05. lsb_release 가 설치 안되 있을 경우.

간혼, lsb_release 명령어가 설치가 안되어 있을 경우가 있습니다. 해당 명령어를 입력할 경우 아래와 같이 명령어를 찾을 수 없다는 메시지가 출력되는 경우인데요. 

해당 경우 yum 명령어를 이용해서 lsb 를 설치해주시면 됩니다. 

$ yum install redhat-lsb

https://rhrhth23.tistory.com/145

END