Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

.NET Core를 직접 호스팅해 (runtimeconfig.json 없이) EXE만 배포해 실행

(이번 주제는, self-contained 방식이 아닌 framework-dependent인 경우 적용할 수 있습니다.)

닷넷 코어에서 runtimeconfig.json을 없앨 수 있을까요?

닷넷코어 빌드 시 runtimeconfig 파일을 없앨 수 있는지..
; https://www.sysnet.pe.kr/3/0/5352

예전에 유사하게 닷넷 프레임워크에 대해서도 이런 처리를 했었는데요,

.NET EXE 파일을 닷넷 프레임워크 버전에 상관없이 실행할 수 있을까요? - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/1746

마찬가지로 .NET Core를 직접 호스팅하면 runtimeconfig.json을 배포하지 않고도 (정확히는 실행 파일에 포함시켜 배포 후 런타임에 풀어내는 식으로) 실행할 수 있습니다. 이를 위해 호스팅 관련 공식 문서들을 보면,

Native hosting
; https://github.com/dotnet/runtime/blob/master/docs/design/features/native-hosting.md

Sample .NET Core Hosts
; https://github.com/dotnet/samples/tree/master/core/hosting

Write a custom .NET Core host to control the .NET runtime from your native code
; https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting

github에 예제가 2가지로 나뉘는데,

  • HostWithHostFxr - .NET Core 3.0에서 도입된 nethost/hostfxr API를 이용(.NET 3.0 이후의 호스팅 용도로 권장)
  • HostWithCoreClrHost - coreclrhost.h에서 제공하는 API를 이용(기존 .NET Core 2.2 이하의 호스팅에서 선호)/li>

이 글에서는 HostWithHostFxr 방식으로 실습해 보겠습니다.




.NET Core/5 런타임을 호스팅하기 위한 첫 번째 작업은 hostfxr.dll을 찾는 것입니다. 왜냐하면 그 DLL 내에 런타임 호스팅을 위한 API들이 정의되어 있기 때문입니다. 그리고 그 hostfx.dll을 찾는 작업을 nethost에서 담당하는데 이미 nethost를 다루는 것에 대해서는 다음의 글에서 설명했습니다.

Visual C++ - .NET Core의 nethost.lib와 정적 링크
; https://www.sysnet.pe.kr/2/0/12419

일단 위의 단계까지 마무리 된 걸로 가정해 다음의 소스 코드에서 시작해 보겠습니다.

struct get_hostfxr_parameters {
    size_t size;
    const wchar_t* assembly_path;
    const wchar_t* dotnet_root;
};

extern "C" int __stdcall get_hostfxr_path(
    wchar_t* buffer,
    size_t * buffer_size,
    const struct get_hostfxr_parameters* parameters);

#include <iostream>
#include <Windows.h>
#include <shlwapi.h>
#include <assert.h>

#include <fstream>
#include <string>

#pragma comment(lib, "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Host.win-x64\\5.0.0\\runtimes\\win-x64\\native\\libnethost.lib")

int main()
{
    wchar_t hostfxr_path[MAX_PATH];

    {
        size_t buffer_size = sizeof(hostfxr_path) / sizeof(wchar_t);

        int rc = get_hostfxr_path(hostfxr_path, &buffer_size, nullptr);
        // buffer == C:\Program Files\dotnet\host\fxr\5.0.0\hostfxr.dll
    }

    return 0;
}

이후 순서는 문서에 따라 단계별로 하시면 됩니다. ^^

Step 1 - Load hostfxr and get exported hosting functions
; https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting#step-1---load-hostfxr-and-get-exported-hosting-functions

Step 2 - Initialize and start the .NET Core runtime
; https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting#step-2---initialize-and-start-the-net-core-runtime

Step 3 - Load managed assembly and get function pointer to a managed method
; https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting#step-3---load-managed-assembly-and-get-function-pointer-to-a-managed-method

Step 4 - Run managed code!
; https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting#step-4---run-managed-code

따라서, hostfxr.dll로부터 호스팅 관련 API들을 가져온 후,

...[생략]...

#pragma comment(lib, "shlwapi.lib")

#define NETHOST_CALLTYPE __stdcall

enum hostfxr_delegate_type
{
    hdt_com_activation,
    hdt_load_in_memory_assembly,
    hdt_winrt_activation,
    hdt_com_register,
    hdt_com_unregister,
    hdt_load_assembly_and_get_function_pointer
};

typedef struct hostfxr_initialize_parameters
{
    size_t size;
    const wchar_t* host_path;
    const wchar_t* dotnet_root;
} hostfxr_initialize_parameters;

typedef void* hostfxr_handle;

typedef int32_t(NETHOST_CALLTYPE* hostfxr_initialize_for_runtime_config_fn)(
    const wchar_t* runtime_config_path,
    const hostfxr_initialize_parameters* parameters,
    /*out*/ hostfxr_handle* host_context_handle);
typedef int32_t(NETHOST_CALLTYPE* hostfxr_get_runtime_delegate_fn)(
    const hostfxr_handle host_context_handle,
    enum hostfxr_delegate_type type,
    /*out*/ void** delegate);
typedef int32_t(NETHOST_CALLTYPE* hostfxr_close_fn)(const hostfxr_handle host_context_handle);

static hostfxr_initialize_for_runtime_config_fn init_fptr;
static hostfxr_get_runtime_delegate_fn get_delegate_fptr;
static hostfxr_close_fn close_fptr;

#pragma comment(lib, "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Host.win-x64\\5.0.0\\runtimes\\win-x64\\native\\libnethost.lib")

static void* load_library(const wchar_t* path)
{
    assert(path != NULL);
    HMODULE h = LoadLibraryW(path);
    assert(h != NULL);
    return (void*)h;
}

static void* get_export(void* h, const char* name)
{
    assert(h != NULL && name != NULL);
    void* f = GetProcAddress((HMODULE)h, name);
    assert(f != NULL);
    return f;
}

int main()
{
    {
        // ...[생략]...

        void* lib = load_library(hostfxr_path);
        init_fptr = (hostfxr_initialize_for_runtime_config_fn)get_export(lib, "hostfxr_initialize_for_runtime_config");
        get_delegate_fptr = (hostfxr_get_runtime_delegate_fn)get_export(lib, "hostfxr_get_runtime_delegate");
        close_fptr = (hostfxr_close_fn)get_export(lib, "hostfxr_close");
    }

    return 0;
}

런타임 호스팅을 시작하고 끝내는 것을 다음과 같이 할 수 있습니다.

#define NETHOST_SUCCESS 0

static bool is_failure(int rc)
{
    // The CLR hosting API uses the Win32 HRESULT scheme. This means
    // the high order bit indicates an error and S_FALSE (1) can be returned
    // and is _not_ a failure.
    return (rc < NETHOST_SUCCESS);
}

// ...[생략]...

int main()
{  
    // ...[생략]...

    hostfxr_handle cxt = nullptr;
    int rc = 0;
    wchar_t config_path[MAX_PATH] = L"...[path_to_runtimeconfig.json]...";

    do
    {
        rc = init_fptr(config_path, nullptr, &cxt);
        if (is_failure(rc) || cxt == nullptr)
        {
            break;
        }

    } while (false);

    if (cxt != nullptr)
    {
        close_fptr(cxt);
    }
}

그리고, 바로 저 init_fptr의 첫 번째 인자에 들어가는 것이 "runtimeconfig.json"의 경로입니다. 그럼, 간단하게 저 파일을 런타임 시에 만들어도 상관없는 것입니다. 원칙적으로는 get_hostfxr_path에서 구한 .NET Core 런타임의 버전을 설정하는 것이 맞겠지만 여기서는 소스 코드의 간결함을 위해 그냥 5.0.0으로 고정시켜 진행합니다.

// ...[생략]...

void write_and_get_config_path(wchar_t* config_path, size_t config_path_size, wchar_t* hostfxr_path)
{
    std::string txt = 
"{\n"
"    \"runtimeOptions\": {\n"
"        \"tfm\": \"net5.0\",\n"
"            \"framework\" : {\n"
"            \"name\": \"Microsoft.NETCore.App\",\n"
"            \"version\" : \"5.0.0\"\n"
"        }\n"
"    }\n"
"}\n";
    
    HMODULE hModule = ::GetModuleHandle(NULL);

    ::GetModuleFileName(hModule, config_path, (DWORD)config_path_size);
    ::PathCchRemoveFileSpec(config_path, config_path_size);
    ::PathCchAppendEx(config_path, config_path_size, L"SampleHostApp.runtimeconfig.json", 0);

    std::ofstream ofs;
    ofs.open(config_path);

    ofs << txt;

    ofs.close();
}

int main()
{
    // ...[생략]...

    wchar_t config_path[MAX_PATH];

    {
        size_t config_path_size = sizeof(buffer) / sizeof(wchar_t);

        write_and_get_config_path(config_path, config_path_size, buffer);
    }

    // ...[생략]...
}

이걸로 일단, runtimeconfig.json은 해결했고 그다음 우리가 만든 .NET DLL에서 시작점을 지정해 함수 포인터를 얻는 작업을 해야 합니다.

int main()
{
    // ...[생략]...

    const wchar_t* dotnet_type = L"SampleHostApp.Program, SampleHostApp";
    const wchar_t* dotnet_type_method = L"Main";
    const wchar_t* dotnet_delegate_type = L"SampleHostApp.MainDelegate, SampleHostApp";

    void* func = nullptr;
    rc = get_managed_export_fptr(
        assembly_path,
        dotnet_type,
        dotnet_type_method,
        dotnet_delegate_type,
        nullptr,
        &func);
    if (is_failure(rc) || func == nullptr)
    {
        break;
    }

    // ...[생략]...
}

여기서 예제로 사용하는 SampleHostApp.dll은 .NET Core 3.1 프로젝트로 아래의 예제 코드를 빌드한 것입니다.

using System;

namespace SampleHostApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("[NETCORE] Hello World!");
      
            Console.WriteLine("# of args: " + args?.Length);
            foreach (string arg in args ?? Array.Empty<string>())
            {
                Console.WriteLine(arg);
            }
        }
    }

    public delegate void MainDelegate(string[] args);
}

또한 지난번과 마찬가지로 이들은 호스팅을 담당하는 C/C++ EXE 내에 리소스로 포함할 것이므로 런타임 시에 다음과 같은 코드로 풀어내야 합니다.

// ...[생략]...

void write_and_get_assembly_path(wchar_t* assembly_path, size_t asm_path_size)
{
    HMODULE hModule = ::GetModuleHandle(NULL);

    ::GetModuleFileName(hModule, assembly_path, asm_path_size);
    ::PathCchRemoveFileSpec(assembly_path, asm_path_size);
    ::PathCchAppendEx(assembly_path, asm_path_size, L"SampleHostApp.dll", 0);

    HRSRC hResource = FindResource(hModule, MAKEINTRESOURCE(IDR_DLLFILE1), L"DLLFILE");
    HGLOBAL hMemory = LoadResource(hModule, hResource);
    DWORD dwSize = SizeofResource(hModule, hResource);
    LPVOID lpAddress = LockResource(hMemory);

    std::ofstream ofs;
    ofs.open(assembly_path, std::ios::binary);

    ofs.write((char*)lpAddress, dwSize);

    ofs.close();
}

int main()
{
    // ...[생략]...

    wchar_t assembly_path[MAX_PATH];

    {
        size_t asm_path_size = sizeof(assembly_path) / sizeof(wchar_t);
        write_and_get_assembly_path(assembly_path, asm_path_size);
    }

    // ...[생략]...
}

자, 그럼 이걸로 끝이군요, 함수 포인터도 잘 구했으니 이제 다음과 같은 식으로 호출만 하면 됩니다.

typedef void (*main_ptr)(intptr_t);
main_ptr mainFunc = (main_ptr)func;

mainFunc(0);




그런데, 여기서 한 가지 문제가 있습니다. 바로 닷넷의 Main 메서드에 전달할 "string [] args" 인자 값을 C/C++에서 딱히 어떻게 구성해야 하는 모르겠습니다. (혹시, 아시는 분은 덧글 부탁드립니다.)

그래서 위의 경우처럼 실행하면 Main 메서드의 string [] args에 null이 전달되어 다음과 같은 식의 실행 결과를 얻게 됩니다.

E:\DotNetSamples\x64\Debug> netcore_host.exe test
[NETCORE] Hello World!
# of args:

하지만, 이렇게 Main 메서드 만을 부르는 식이라면 더 간단하게 호스팅을 처리하는 방법이 hostfx.dll에 있습니다. 바로 hostfxr_main 함수인데, 이것을 사용하면 별다른 호스팅 코딩 없이 모두 자동화되어 처리가 됩니다.

int main()
{
    wchar_t hostfxr_path[MAX_PATH];

    {
        size_t buffer_size = sizeof(hostfxr_path) / sizeof(wchar_t);

        int rc = get_hostfxr_path(hostfxr_path, &buffer_size, nullptr);
        if (is_failure(rc))
            noreturn_runtime_load_failure(rc);

        void* lib = load_library(hostfxr_path);

        hostfxr_main_fptr = (hostfxr_main_fn)get_export(lib, "hostfxr_main");
    }

    wchar_t config_path[MAX_PATH];

    {
        size_t config_path_size = sizeof(config_path) / sizeof(wchar_t);
        write_and_get_config_path(config_path, config_path_size, hostfxr_path);
    }

    wchar_t assembly_path[MAX_PATH];

    {
        size_t asm_path_size = sizeof(assembly_path) / sizeof(wchar_t);
        write_and_get_assembly_path(assembly_path, asm_path_size);
    }

    int nArgs = 0;
    LPWSTR* szArglist = CommandLineToArgvW(GetCommandLineW(), &nArgs);

    PCWSTR* argv = new PCWSTR[2 + ((short)nArgs) - 1];
    argv[0] = config_path; // 첫 번째 요소에 runtimeconfig.json 파일 경로
    argv[1] = assembly_path; // 두 번째 요소에 .NET DLL 경로

    for (int i = 0; i < nArgs - 1; i++)
    {
        argv[2 + i] = szArglist[i + 1]; // 세 번째 이후는 명령행에 전달된 인자
    }

    hostfxr_main_fptr(2 + (nArgs - 1), argv); // 내부에서 자동으로 호스팅도 시작하고 Main 메서드도 호출

    delete[] argv;
    LocalFree(szArglist);

    if (cxt != nullptr)
    {
        close_fptr(cxt);
    }

    return 0;
}




참고로, 위의 예에서 get_managed_export_fptr를 이용한 호출 방식은 내부에 반드시 델리게이트 타입이 정의되어 있어야 합니다. 예제의 경우 그래서 MainDelegate 타입을 포함했던 것입니다.

마찬가지로 닷넷 호스팅 문서의 예제에서는,

HostWithHostFxr
; https://github.com/dotnet/samples/tree/master/core/hosting/HostWithHostFxr

ComponentEntryPoint라는 델리게이트를 정의해 놓고 그 양식에 맞는 닷넷 메서드를 호출하고 있습니다.

public delegate int ComponentEntryPoint(IntPtr args, int sizeBytes);

재미있는 것은, .NET 5에서의 함수 포인터가 적용되면서 델리게이트를 생략할 수 있게 되었다는 점입니다. 이에 대한 예제는 DNNE에서 제공하는 platform.c의 get_callable_managed_function 코드에서 확인할 수 있습니다.

// ...[생략]...

#define UNMANAGEDCALLERSONLY_METHOD ((const char_t*)-1)

// ...[생략]...

void* get_callable_managed_function(
    const char_t* dotnet_type,
    const char_t* dotnet_type_method,
    const char_t* dotnet_delegate_type)
{
    assert(dotnet_type && dotnet_type_method);

    // Check if the runtime has already been prepared.
    if (!get_managed_export_fptr)
    {
        prepare_runtime();
        assert(get_managed_export_fptr != NULL);
    }

    char_t buffer[DNNE_MAX_PATH];
    const char_t assembly_filename[] = DNNE_STR(DNNE_TOSTRING(DNNE_ASSEMBLY_NAME)) DNNE_STR(".dll");
    const char_t* assembly_path = NULL;
    int rc = get_current_dir_filepath(DNNE_ARRAY_SIZE(buffer), buffer, DNNE_ARRAY_SIZE(assembly_filename), assembly_filename, &assembly_path);
    if (is_failure(rc))
        noreturn_export_load_failure(rc);

    // Function pointer to managed function
    void* func = NULL;
    rc = get_managed_export_fptr(
        assembly_path,
        dotnet_type,
        dotnet_type_method,
        dotnet_delegate_type,
        NULL,
        &func);

    if (is_failure(rc))
        noreturn_export_load_failure(rc);

    return func;
}

void* get_fast_callable_managed_function(
    const char_t* dotnet_type,
    const char_t* dotnet_type_method)
{
    return get_callable_managed_function(dotnet_type, dotnet_type_method, UNMANAGEDCALLERSONLY_METHOD);
    // return get_callable_managed_function(dotnet_type, dotnet_type_method, 0x05);
}

즉, 닷넷 모듈에 정의한 메서드 중 UnmanagedCallersOnly 특성이 부여된 경우라면 그 메서드를 호출할 때는 델리게이트 타입을 명시할 필요 없이 -1 값을 전달하면 되는 것입니다.

이 글의 예제 코드는 github에 올려 두었습니다.

DotNetSamples/Cpp/netcore_host
; https://github.com/stjeong/DotNetSamples/tree/master/Cpp/netcore_host

개선해야 할 점이 있다면, 리눅스를 지원하지 않아 윈도우에서만 실행이 됩니다. (원하시는 분은 PR 넣으셔도 됩니다. ^^)




만약 nethost에 대한 의존성이 싫다면, 사실 그냥 만들어도 됩니다. 중요한 것은, "C:\Program Files\dotnet\host\fxr\5.0.0\hostfxr.dll" 경로를 찾는 것이기 때문에 윈도우라면 레지스트리 또는 %ProgramFiles%에서 검색하면 (100%는 아니겠지만) 대부분의 경우 해결이 됩니다. 물론, nethost 만큼 다양한 방식으로 검색해 반환하려면 꽤나 코드가 들어갈 텐데요, 원한다면 nethost 관련 소스 코드는 다음의 경로에서 찾을 수 있습니다.

runtime/src/installer/corehost/cli/nethost/CMakeLists.txt
; https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/nethost/CMakeLists.txt

runtime/src/installer/corehost/cli/nethost/nethost.cpp
; https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/nethost/nethost.cpp

runtime/src/installer/corehost/cli/fxr_resolver.cpp
; https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/fxr_resolver.cpp

core-setup/src/corehost/common/pal.windows.cpp
; https://github.com/dotnet/core-setup/blob/master/src/corehost/common/pal.windows.cpp

runtime/src/installer/corehost/cli/apphost/static/hostfxr_resolver.cpp
; https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/apphost/static/hostfxr_resolver.cpp

실제로 위의 코드를 보면, nethost에서 %ProgramFiles% 또는 %ProgramFiles(x86)%의 경로에 "host" + "fxr" 문자열의 하위 경로 2개가 존재하면 그 이하 폴더를 열거하는 식의 코드를 볼 수 있습니다.

혹은, nethost를 비롯해 닷넷 관련 모듈은 "COREHOST_TRACE=1" 환경 변수로 인한 로그를 꽤나 자세하게 남기므로 그 로그를 통해 nethost의 동작을 유추하는 것도 가능합니다. (첨부 파일은 제 컴퓨터에서 실행한 예제 코드의 trace 로그입니다.)

그나저나, 정리해 놓고 나니 한 가지 아쉬움이 남는군요. ^^ 닷넷 프레임워크의 경우 DLL을 메모리로부터 로드하는 AppDomain.Load 버전을 제공하므로 정말로 한 개의 모듈로 실행하는 것이 가능했습니다. 반면, 닷넷 코어는 runtimeconfig.json과 닷넷 DLL에 대한 경로를 필요로 하므로 사용 전 반드시 파일에 써야 하는 단점이 있습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 11/25/2020 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 




1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12502정성태1/21/2021418.NET Framework: 1016. .NET Core HttpClient의 HTTP/2 지원파일 다운로드1
12501정성태1/21/2021399.NET Framework: 1015. .NET 5부터 HTTP/1.1, 2.0 선택을 위한 HttpVersionPolicy 동작 방식파일 다운로드1
12500정성태1/21/2021415.NET Framework: 1014. ASP.NET Core(Kestrel)의 HTTP/2 지원 여부파일 다운로드1
12499정성태1/23/2021424.NET Framework: 1013. .NET Core Kestrel 호스팅 - 포트 변경, non-localhost 접속 지원 및 https 등의 설정 변경파일 다운로드1
12498정성태1/23/2021396.NET Framework: 1012. .NET Core Kestrel 호스팅 - 비주얼 스튜디오의 Kestrel/IIS Express 프로파일 설정
12497정성태3/2/2021534.NET Framework: 1011. C# - OWIN Web API 예제 프로젝트 [1]파일 다운로드2
12496정성태1/19/2021528.NET Framework: 1010. .NET Core 콘솔 프로젝트에서 Kestrel 호스팅 방법 [1]
12495정성태1/20/2021574웹: 40. IIS의 HTTP/2 지원 여부 - h2, h2c [1]
12494정성태1/19/2021555개발 환경 구성: 522. WSL2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법 [2]
12493정성태1/18/2021565.NET Framework: 1009. .NET 5에서의 네트워크 라이브러리 개선 (1) - HTTP 관련 [1]파일 다운로드1
12492정성태1/17/2021287오류 유형: 695. ASP.NET 0x80131620 Failed to bind to address
12491정성태1/18/2021545.NET Framework: 1008. 배열을 반환하는 C# COM 개체의 메서드를 C++에서 사용 시 메모리 누수 현상 [1]파일 다운로드1
12490정성태1/15/2021678.NET Framework: 1007. C# - foreach에서 열거 변수의 타입을 var로 쓰면 object로 추론하는 문제 [1]파일 다운로드1
12489정성태1/13/2021479.NET Framework: 1006. C# - DB에 저장한 텍스트의 (이모티콘을 비롯해) 유니코드 문자가 '?'로 보인다면?
12488정성태1/13/2021649.NET Framework: 1005. C# - string 타입은 shallow copy일까요? deep copy일까요?파일 다운로드1
12487정성태1/13/2021519.NET Framework: 1004. C# - GC Heap에 위치한 참조 개체의 주소를 알아내는 방법파일 다운로드1
12486정성태1/12/2021599.NET Framework: 1003. x64 환경에서 참조형의 기본 메모리 소비는 얼마나 될까요?
12485정성태1/11/2021595Graphics: 38. C# - OpenCvSharp.VideoWriter에 BMP 파일을 1초씩 출력하는 예제파일 다운로드1
12484정성태1/9/2021572.NET Framework: 1002. C# - ReadOnlySequence<T> 소개파일 다운로드1
12483정성태1/8/2021577개발 환경 구성: 521. dotPeek - 훌륭한 역어셈블 소스 코드 생성 도구
12482정성태1/8/2021468.NET Framework: 1001. C# - 제네릭 타입/메서드에서 사용 시 경우에 따라 CS8377 컴파일 에러
12481정성태1/7/2021438.NET Framework: 1000. C# - CS8344 컴파일 에러: ref struct 타입의 사용 제한 메서드파일 다운로드1
12480정성태1/9/2021779.NET Framework: 999. C# - ArrayPool<T>와 MemoryPool<T> 소개파일 다운로드1
12479정성태1/6/2021472.NET Framework: 998. C# - OWIN 예제 프로젝트 만들기
12478정성태1/6/2021600.NET Framework: 997. C# - ArrayPool<T> 소개파일 다운로드1
12477정성태1/6/2021696기타: 79. github 코드 검색 방법 [1]
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...