Microsoft MVP성태의 닷넷 이야기
.NET Framework: 2098. dotnet build에 /p 옵션을 적용 시 유의점 [링크 복사], [링크+제목 복사],
조회: 14438
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

dotnet build에 /p 옵션을 적용 시 유의점

csproj를 보면 "PropertyGroup"의 자식으로 다양한 Property를 정의할 수 있는데요,

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net7.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
      
  </PropertyGroup>

</Project>

이런 옵션들을 "dotnet build" 명령행에서 "/p" 인자를 이용해 직접 제어하는 것이 가능합니다. 예를 들어, 다음과 같이 코딩한 경우,

class Program
{
    static unsafe void Main(string[] args)
    {
        int n = 5;
        int* p = &n;

        Console.WriteLine(*p);
    }
}

기본 csproj 상태로는 "error CS0227: Unsafe code may only appear if compiling with /unsafe" 컴파일 오류가 발생하지만, csproj에 이렇게 AllowUnsafeBlocks 옵션을 설정하거나,

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        ...[생략]...

        <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    </PropertyGroup>

</Project>

dotnet build의 경우 동일한 이름의 옵션을 다음과 같이 /p로 연결해서 빌드하면 정상적으로 실행됩니다.

c:\temp\ConsoleApp1\ConsoleApp1> dotnet build /p:AllowUnsafeBlocks=true

c:\temp\ConsoleApp1\ConsoleApp1> dotnet run
5




위에서 설명한 옵션 같은 경우에는, 그 옵션이 적용되지 않으면 컴파일 오류가 발생하기 때문에 적용 여부를 바로 알아챌 수 있는데요, 그렇지 않은 경우, 가령 CheckForOverflowUnderflow 옵션 등은 dotnet build 시 주의해야 합니다.

역시 간단하게 예를 들어볼까요? ^^

short c = -32768;
c--;
Console.WriteLine(c); // 32767

csproj에 CheckForOverflowUnderflow 옵션을 주고 위의 소스 코드를 빌드하면,

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        ...[생략]...

        <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow>
    </PropertyGroup>

</Project>

실행 시 overflow 예외가 발생합니다.

Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.
   at Program.<Main>$(String[] args) in C:\Users\SeongTae Jeong\Dropbox\articles\checked_dotnet_build\ConsoleApp1\ConsoleApp1\Program.cs:line 2

그런데, 이 과정을 (csproj의 CheckForOverflowUnderflow 옵션을 삭제하고) dotnet build로 바꿔보면 어떻게 될까요?

c:\temp\ConsoleApp1\ConsoleApp1> dotnet build
c:\temp\ConsoleApp1\ConsoleApp1> dotnet run
32767

일단 정상적으로 나왔습니다. 그런데, 위의 빌드에 이어서 /p 옵션을 주고 빌드하면,

c:\temp\ConsoleApp1\ConsoleApp1> dotnet build /p:CheckForOverflowUnderflow=true
c:\temp\ConsoleApp1\ConsoleApp1> dotnet run
32767

마치 옵션 값을 무시하는 듯, overflow 예외가 발생하지 않습니다. 이유는 간단합니다. 소스 코드 또는 csproj의 내용이 바뀌어야 재빌드를 하는데, 단순히 명령행 옵션만 바뀌었기 때문에 재빌드를 안 한 것입니다.

재미있는 건, .\bin\Debug\net7.0 디렉터리의 내용을 모두 삭제하고 다시 "dotnet build ..."를 해도 새롭게 빌드하지 않고 .\obj\Debug\net7.0 디렉터리에 빌드돼 있던 바이너리를 복사해 온다는 점입니다.

따라서, /p 옵션을 변경해 다시 빌드해야 한다면 \.obj\Debug\net7.0 디렉터리의 내용을 삭제하든가, 아니면 "dotnet clean" 명령어를 먼저 실행하고 진행해야 합니다.





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

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/29/2023]

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

비밀번호

댓글 작성자
 




... 16  17  18  [19]  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13562정성태2/21/202412291오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/202413936닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/202414222디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/202415841오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/202414825닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/202411298Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/202414077Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/202414215닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/202412922VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/202411344닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/202411572닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/202413812닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/202414279Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/202415858개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/202415223개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/202414978개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/202414394Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/202414149닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/202413382오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/202414122Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/202411778오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/202413135VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/202412470Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/202411713개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/202413086닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/202414672닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
... 16  17  18  [19]  20  21  22  23  24  25  26  27  28  29  30  ...