Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 7개 있습니다.)
사물인터넷: 9. Visual Studio 2017에서 Raspberry Pi C++ 응용 프로그램 제작
; https://www.sysnet.pe.kr/2/0/11358

개발 환경 구성: 339. WSL을 이용해 윈도우 PC 1대에서 Linux 응용 프로그램을 Visual Studio로 개발하는 방법
; https://www.sysnet.pe.kr/2/0/11390

개발 환경 구성: 340. WSL을 이용해 윈도우 PC 1대에서 openSUSE 응용 프로그램을 Visual Studio로 개발하는 방법
; https://www.sysnet.pe.kr/2/0/11391

개발 환경 구성: 428. Visual Studio 2019 - CMake를 이용한 리눅스 빌드 환경 설정
; https://www.sysnet.pe.kr/2/0/11825

개발 환경 구성: 431. Visual Studio 2019 - CMake를 이용한 공유/실행(so/out) 리눅스 프로젝트 설정
; https://www.sysnet.pe.kr/2/0/11833

개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정
; https://www.sysnet.pe.kr/2/0/11844

개발 환경 구성: 727. Visual C++ - 리눅스 프로젝트를 위한 빌드 서버의 msbuild 구성
; https://www.sysnet.pe.kr/2/0/13737




Visual C++ - 리눅스 프로젝트를 위한 빌드 서버의 msbuild 구성

리눅스 프로젝트의 경우,

Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정
; https://www.sysnet.pe.kr/2/0/11844

빌드를 위해 반드시 리눅스 서버 또는 WSL을 필요로 합니다. 비주얼 스튜디오에서는 이런 연결을 개별 프로젝트에서 관리하지 않고 "Tools" / "Options" 메뉴로 뜨는 "Cross Platform" / "Connection Manager"에서 관리하는데요,

[그림 1: Connection Manager]
vs_remote_ssh_1.png

이렇게 구성한 설정은 %LOCALAPPDATA%\Microsoft\Linux\User Data\3.0\store.xml에 별도로 저장됩니다.

사실 개발자 1명이 프로젝트를 관리하는 상황이라면 위와 같은 방식이 문제가 되진 않지만, 여러 개발자가 하나의 프로젝트를 함께 참여하는 상황이라면 다소 불편한 점이 있습니다. 또는, 빌드 서버를 구성한 경우에도 저건 문제가 됩니다. 가령, github에 올린 프로젝트를 빌드 서버에서 받아 컴파일하려고 할 때, 개발자 PC와는 달리 원격 리눅스 서버에 대한 정보가 없어 당연히 빌드가 실패하게 됩니다.

어쩔 수 없이 빌드 서버에서도 리눅스 서버에 대한 정보를 등록해야 하고, 이럴 때 ConnectionManager.exe를 이용할 수 있습니다.

// 아래는 키 파일 경로를 %USERPROFILE%에 설정했으므로 빌드 스크립트를 실행하는 계정이 다르다면 주의해야 합니다.

C:\temp> ConnectionManager.exe add testusr@192.168.100.50 --privatekey "%USERPROFILE%\.ssh\test_rsa"

일단 저렇게 전역적으로 (store.xml에) 등록했어도 빌드에 문제가 발생할 여지가 여전히 남아 있습니다. 왜냐하면, vcxproj 프로젝트 파일에는 그것을 빌드하기 위한 리눅스 서버 정보를 포함하지 않기 때문입니다.

그래서, "그림 1"처럼 구성된 환경에서 msbuild를 이용해 vcxproj 파일을 빌드하면,

c:\temp> msbuild ConsoleApplication1.vcxproj /p:Platform=ARM64 /t:rebuild

msbuild는 "그림 1"의 "Default" 칼럼에 선택된 "192.168.105.25" 서버를 자동으로 선택해 빌드를 수행합니다. 물론, 1개만 등록돼 있다면 문제가 없겠지만, 만약 빌드 서버에서 x64, ARM64 프로젝트를 빌드하도록 스크립트를 구성했다면,

// "Default"로 선택한 리눅스 서버에서 빌드
c:\temp> msbuild ConsoleApplication1.vcxproj /p:Platform=ARM64 /t:rebuild

// "Default"로 선택한 리눅스 서버에서 빌드
c:\temp> msbuild ConsoleApplication1.vcxproj /p:Platform=x64 /t:rebuild

당연히 둘 중의 하나는 플랫폼이 맞지 않는 결과를 가져옵니다.




비주얼 스튜디오 환경에서 각각의 개발자는 Visual C++ 프로젝트 속성 창에서 "Remote Build Machine"을 설정할 수 있습니다.

vs_remote_ssh_2.png

하지만, 이 정보는 (위의 예제에서) ConsoleApplication1.vcxproj 파일에 저장되지 않고 별도로 ConsoleApplication1.vcxproj.user 파일에 저장됩니다. 즉, 소스코드의 형상관리에서 제외되기 때문에 빌드 서버에서 소스 코드를 가져와도 저 파일은 공유되지 않는 것입니다.

대신 해당 설정은 msbuild를 따르기 때문에 원한다면 *.vcxproj.user 내용을 *.vcxproj 파일에 적용해도 됩니다. 예를 들어, user 파일은 다음의 내용을 담고 있는데,

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="Current" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    <RemoteTarget>1638701483;192.168.105.25 (username=, port=22, authentication=Password)</RemoteTarget>
  </PropertyGroup>
</Project>

이 설정을 vcxproj에 그대로 이식할 수 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="Current" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  ...[생략]...

  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
  ...[생략]...
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
    <UseDebugLibraries>false</UseDebugLibraries>
    <PlatformToolset>Remote_GCC_1_0</PlatformToolset>
    <RemoteTarget>1365766831;169.254.238.200 (username=, port=22, authentication=Password)</RemoteTarget>
  </PropertyGroup>
  ...[생략]...
</Project>

이것을 이용하면, 빌드 서버를 위해 "'$(Configuration)|$(Platform)'=='Release|x64'"와 같이 Release 빌드의 경우 RemoteTarget으로 지정한 외부 서버에서 수행하도록 할 수 있습니다. 반면, 개발자 PC에서는 user 파일에 Debug 빌드를 둬 각자가 원하는 서버로 빌드하는 유연함을 가질 수 있습니다.




또 다른 방법으로는, msbuild 명령줄에서 /p:RemoteTarget=... 옵션을 직접 전달하는 것입니다. 이때의 인자는 ConnectionManager.exe를 통해 구한 "Connection ID"를 쓰면 됩니다.

C:\temp> ConnectionManager.exe list
Reading stored connections from 'C:\Users\testu\AppData\Local\Microsoft\Linux\User Data\3.0\store.xml'

Connection ID |            Host | Username | Port | Authentication Type
-----------------------------------------------------------------------
    567696872 |       127.0.0.1 |    testu |   22 | Password
   1365766831 | 169.254.238.200 |    testu |   22 | Password
   1638701483 |  192.168.105.25 |    testu |   22 | Password

아래는 그 예제입니다.

// 169.254.238.200 서버는 ARM64 서버로 가정,
c:\temp> msbuild ConsoleApplication1.vcxproj /p:RemoteTarget=1365766831 /p:Platform=ARM64;Configuration=Release / /t:rebuild

// 192.168.105.25 서버는 x64용 서버로 가정,
c:\temp> msbuild ConsoleApplication1.vcxproj /p:RemoteTarget=1638701483 /p:Platform=x64;Configuration=Release / /t:rebuild

아마도 대부분의 경우, 리눅스 빌드로는 x64, ARM64 2가지 정도를 지원하게 될 텐데요, 그렇다면 자연스럽게 컨테이너를 이용한 빌드를 하게 될 것이고, 결국 fingerprint에 대한 관리까지 고려해야 할 것입니다. ^^




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/21/2024]

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)
13541정성태1/29/20249610VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20249499Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20249300개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20249901닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/202410685닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/202410300닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/202410726닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/202410130닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/202410122닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/202410174닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/202410556닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20249832닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
13529정성태1/15/202410035닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
13528정성태1/14/202410192Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
13527정성태1/14/202410278오류 유형: 892. Visual Studio - Failed to launch debug adapter. Additional information may be available in the output window.
13526정성태1/14/202410612닷넷: 2201. C# - Facebook 연동 / 사용자 탈퇴 처리 방법
13525정성태1/13/20249751오류 유형: 891. Visual Studio - Web Application을 실행하지 못하는 IISExpress
13524정성태1/12/20249780오류 유형: 890. 한국투자증권 KIS Developers OpenAPI - GW라우팅 중 오류가 발생했습니다.
13523정성태1/12/20249767오류 유형: 889. Visual Studio - error : A project with that name is already opened in the solution.
13522정성태1/11/202410596닷넷: 2200. C# - HttpClient.PostAsJsonAsync 호출 시 "Transfer-Encoding: chunked" 대신 "Content-Length" 헤더 처리
13521정성태1/11/202410255닷넷: 2199. C# - 한국투자증권 KIS Developers OpenAPI의 WebSocket Ping, Pong 처리
13520정성태1/10/20249930오류 유형: 888. C# - Unable to resolve service for type 'Microsoft.Extensions.ObjectPool.ObjectPool`....' [1]
13519정성태1/10/20249623닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출파일 다운로드1
13518정성태1/9/202410357닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
13517정성태1/8/20249502스크립트: 63. Python - 공개 패키지를 이용한 위성 이미지 생성 (pystac_client, odc.stac)
13516정성태1/7/20249649닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...