디버거는 서버 1s 8.3에서 작동하지 않습니다.
서버 1C에서 디버깅을 시작하는 방법...
기본적으로 1C:Enterprise 클라이언트-서버 아키텍처를 사용할 때 1C 코드 디버깅 모드는 클라이언트 측에서만 작동합니다. 서버 프로시저 및 기능은 클라이언트 시스템에 표시되지 않습니다.
1C 서버에서 디버깅을 사용하려면 다음 단계를 수행해야 합니다.
1. 서비스 관리자(버전 8.3용)에서 "Server Agent 1C: Enterprise 8.3" 서비스를 찾아서 중지합니다.
2. 시스템 레지스트리 편집기를 엽니다. 명령줄 또는 시작 메뉴 도구 - 실행 ... 및 명령을 사용할 수 있습니다. regedit.
3. 레지스트리에서 분기를 찾습니다.
- 버전 1C 8.1의 경우
- 버전 1C 8.2의 경우
- 버전 1C 8.3의 경우
4. ImagePath 속성을 변경하고 "-debug" 지시문을 줄 끝에 추가합니다. 결과 속성 문자열은 "C:\Program Files (x86)\1cv8\8.3.6.2152\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program 파일(x86)\1cv8\srvinfo" --디버그
그 후 디버거로 1C 서버 코드를 안전하게 확인하고 필요한 곳에 중단점을 설정할 수 있습니다.
질문: 서버에서 및 디버깅이 작동하지 않습니다.
답변:
질문: 서버에서 디버깅이 작동하지 않습니다.
플랫폼: 8.3.4.482
그것은 아침에 작동했습니다. 지금은 아닙니다. 서버에서 디버깅이 활성화됩니다. 디버깅은 클라이언트에서 작동합니다.
내가 시도한 것 :
얇고, 두껍고, UV, NOT UV - 그것은 중요하지 않습니다.
클라이언트에서 캐시를 지웠습니다. 서버에 없음 - 아직 할 수 없습니다.
디버그 -> 연결 - 서버와 클라이언트가 연결되어 있습니다.
클러스터에서 베이스를 삭제/추가했습니다.
다른 1C 사용자의 상황은 비슷합니다.
내 동료와 기본 디버깅 작업에서. 디버깅은 어떤 기반에서도 작동하지 않습니다. 관리자는 아무것도하지 않았습니다 ...
또 어디를 봐야 할까요? (서버 캐시 지우기 제외).
답변:() CACHE 및 Restart는 하지 않았습니다. 데이터베이스에 대한 경로를 다시 작성했습니다. 도움이되지 않았습니다.
() 그냥 그랬다. 이제 문제를 해결하고 싶습니다.
질문: 파일 옵션 디버깅이 작동하지 않습니다
컨피규레이터에서 시작한 클라이언트가 잘 디버깅되는 상황인데 사용자 모드에서 시작한 다음 컨피규레이터에서 디버깅을 위해 이 연결을 선택하면 이해할 수 없는 일이 발생합니다.
1) 아무것도 디버깅되지 않음
2) 중단점의 색상이 빨간색에서 회색으로 변경됩니다.
플랫폼 8.3.12.1440
8.3.11.3133을 설정했는데 상황이 바뀌지 않았습니다.
누군가 찾아왔나요?
답변: http를 통해 디버깅할 때 작동했습니다.
무슨 일인지 모르겠어.
질문: 서버 1C Enterprise 8.3이 작동하지 않습니다(중단).
답변:
질문: 로컬 컴퓨터에서 1s를 실행할 때 서버 디버깅이 작동하지 않습니다.
여보세요. 1s(8.3, MSSQL, 호환 모드 8.2.13, UPP 1.3.111.1) 디버깅이 서버에서 작동하는 서버에 대한 터미널 연결에서는 모든 것이 정상입니다. 그러나 로컬 컴퓨터에서 동일한 데이터베이스에 연결합니다(구성자 사용 + 구성자에서 "디버깅 시작" 클릭) - "연결(디버깅 항목)" 창에서 서버 유형과의 연결이 나타나지 않습니다. "원격 컴퓨터에서 디버깅 항목 검색" 확인란을 선택합니다. + 서버 이름(또는 주소) 옆에 필수 항목을 씁니다. 여기서 1c, - 서버 유형과의 연결이 나타나지만 서버 디버깅이 작동하지 않습니다. 일반 모듈에 중단점을 넣으면 프로그램이 중단되지 않습니다. 고칠 수 있는지 알려주실 수 있나요?
서버 디버깅이 작동하지 않습니다. 왜 그런 겁니까?
답변:() 주제별 - 서버의 포트 1560-1591에서 무슨 일이 일어나고 있는지 확인하십시오.
질문: 서버의 두 인스턴스 실행(8.3.8.x x86 및 8.3.9.x x64)
답변:
질문: 새 COMObject, 클래스가 파일에 등록되지 않았지만 서버에서 작동합니다.
8.3.9.1850
처리중이다
파일에 (x84와 같은) 제공
(ExternalProcessing.Queryer.Form.Form.Form(2404)): 생성자(COMObject) 호출 오류
obMSScriptControl = 새 COMObject("MSScriptControl.ScriptControl");
때문에:
-2147221164(0x80040154): 등록되지 않은 클래스
동시에 서버(x84)에서는 잘 작동합니다.
왜 그런 겁니까?
답변:설립하다
새로운 플랫폼(8.3.9)이 있었습니다. 이 플랫폼에서 지속적으로 출시되었습니다.
질문: 클라이언트에서 서버로 데이터 패킷 전송
여보세요!
알려주세요,
데이터가 포함된 Excel 파일이 있습니다.
데이터베이스는 클라이언트-서버 모드에서 작동합니다.
Excel에서 문서의 표 부분으로 데이터를 전송하고 싶습니다.
엑셀이 서버에 설치되어 있지 않기 때문에 클라이언트에서 연결을 생성합니다.
클라이언트에서 라인을 순환하고 문서의 pt를 변경합니다.
그것은 매우 빠르게 작동하지 않습니다.
조언에 미리 감사드립니다!
답변: 트리트5,
1C 8.2 및 8.3에서 디버깅이 작동하지 않는 경우
Stop 1C:Enterprise 8.2 서버 에이전트 서비스
레지스트리 편집기를 실행합니다. 레지스트리 편집기를 열려면 Windows + R(또는 시작-실행)을 누르고 명령 프롬프트에서 regedit를 입력해야 합니다.
레지스트리 분기 찾기
"ImagePath" = 속성을 찾고 행에 "-debug"를 추가합니다.
우리는 서비스를 기록하고 시작합니다.
예시:
전원을 켜기 전에:
""C:\Program Files (x86)\1cv82\8.2.18.109\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files(x86)\ 1cv82\srvinfo""
디버깅을 활성화한 후:
""C:\Program Files (x86)\1cv82\8.2.18.109\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files(x86)\ 1cv82\srvinfo" -디버그"
Q: MMC 스냅인이 작동하지 않음(스냅인 오류)
인사말! 정상적으로 업데이트하기 위해 1C 서버 클러스터를 통해 데이터베이스에서 사용자를 쫓아내고 싶지만 어떤 이유로 1C 서버 장비가 작동하지 않습니다. NET.Framework 4.5.2에 있는 것 같습니다(모든 것이 Windows Server 2008 R2 SP1에서 작동함). 다시 설치하고 싶습니다. 위험합니까? 1C가 작동할까요?
나중에 추가됨:
NET Framework 4.5.2를 다시 설치\제거해도 전혀 도움이 되지 않았습니다. 즉, 분명히 유일한 방법은 1C 서버 클러스터 관리 콘솔을 다시 설치하는 것입니다. RoamingData의 MMC 폴더를 보니 거기에 비어 있습니다. 일반적으로 Xs이지만 이 문제를 풀지 않고 필요한 작업을 해결했습니다.
답변:업데이트한 버전에 따라 CMD에서 관리자로 실행합니다.
cd C:\Program Files\1cv8\8.3.6.2100\bin
regsvr32 /n /i:사용자 radmin.dll
또한 업그레이드 중에 관리 콘솔 설치를 포함하지 않았을 수 있습니다(설치 프로그램을 실행하고 확인란 선택).
1C 8.1 서버에서 디버깅을 활성화하려면응용 프로그램 서버를 다시 시작하고 레지스트리로 이동해야 합니다. 즉
"이미지 경로"=
기본:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv81\server"
그리고 그것은 필요합니다:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "C:\Program Files\1cv81\server"
일련의 작업 1C 8.2:
1. 서비스 중지 1C: 엔터프라이즈 8.2 서버 에이전트
2. 지점의 레지스트리에서 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:Enterprise 8.2 서버 에이전트\매개변수 이미지 경로추가하다 -디버그그리고 저장합니다. 다음과 같이 나타납니다. "C:\Program Files\1cv82\8.2.10.82\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv82\srvinfo" -debug
3. 서비스를 작성하고 시작합니다.
먼저 -debug 전에 공백을 놓쳤습니다. 내가 말할 수있는 것 : 결과는 훌륭했습니다. 단일 데이터베이스가 발견되지 않았고 기업이 어떤 식 으로든 시작되지 않았습니다.
당신은 또한 관심이있을 수 있습니다
- 23.07.2014
1C-Enterprise 8용 SQLServer 2005-2008의 작동 기능. 아래에 출원: 1C
- VMware Mirage로 PC 및 모바일 컴퓨터 관리 2013년 3월 13일
8, 디버깅 절차의 상당한 재작업이 필요합니다(아래에서 자세히 설명). 이는 버전 8.3.7.1759에 반영되었습니다. 첫째, 이 절차를 위해 범용 인터페이스가 생성되었으며, 둘째, 이러한 변경으로 인해 프로그램 자체의 추가 개발이 보장됩니다. 결국, 이제 Configurator 뿐만 아니라 Development Tools의 도움으로 디버깅 작업을 할 수 있습니다. 새 버전부터 1C 서버에서 디버깅을 활성화하는 방법을 고려하십시오.
새 프로토콜 사용
이전 버전에서 구현된 이전 디버거는 TCP/IP 프로토콜을 사용하여 클라이언트 및 서버 응용 프로그램을 관리합니다.
현재 이러한 프로토콜의 사용으로 인해 1C:Enterprise 프로그램의 인터넷 액세스가 제한되기 시작했으며 모바일 응용 프로그램의 작동에 불편을 초래했습니다.
따라서 로컬 그리드 외부에 있을 수 있는 정보베이스에 대한 무료 액세스를 위해 이제 유연한 HTTP 프로토콜을 사용할 수 있습니다.
새로운 아키텍처
이전에는 구성 디버깅을 수행할 때 직원이 인포베이스에 연결해야 했습니다. 이렇게 하려면 그에게 관리자 권한을 부여해야 했습니다.
새 버전에서는 데이터베이스에 직접 연결할 필요가 없습니다. 클라이언트와 동일한 데이터베이스만 있으면 충분합니다. 그리고 파일에서 로드할 수 있습니다.
모바일 애플리케이션
HTTP 프로토콜을 사용하여 이제 서버 데이터, 클라이언트 데이터 및 응용 프로그램을 디버그할 수 있습니다.
기타 변경 사항
새 버전에서는 디버그 절차에서 로컬 변수의 값을 변경할 수 있습니다. 이를 위해 새로운 빠른 보기 창이 구현되었습니다.
계산 모드가 비동기식으로 변경되어 결과를 기다리지 않고 계속 작업할 수 있습니다.
개발 도구의 디버거
새 절차와의 상호 작용은 특별히 설계된 범용 프로그래밍 인터페이스에서 수행됩니다. 한편으로 이 인터페이스는 Configurator에서 사용됩니다. 한편, 새로운 1C:Enterprise Development Tools 환경에서 구현됩니다.
지금은 어떤 모습인가요
프로그램 변경 후 절차는 다음 시나리오에 따라 진행됩니다.
이제 이전과 같이 디버거와 개체만 포함되는 것이 아닙니다. 이제 추가 요소인 서버가 체인에 추가되었습니다.
추가될 뿐만 아니라 디버거와 개체 간의 정보 교환의 주요 요소 역할을 합니다. 그리고 교환 자체는 대기열에 있는 메시지를 통해 발생합니다.
그리고 이 교환은 HTTP 프로토콜을 통해 이루어지므로 이제 데이터가 정확히 어디에 위치할 수 있는지는 중요하지 않습니다.
서버 요청은 추가 연결 요청의 형태로 디버거와 개체에 의해 형성됩니다. 그들이 나타나면 적절한 응답이 전송됩니다.
다양한 시나리오에서 디버깅 활성화
응용 프로그램 개발자에 대한 변경 사항은 없습니다. 중요한 차이점은 새 메커니즘을 활성화해야 한다는 것입니다. 결국 기본적으로 지금은 비활성화되어 있습니다.
두 시나리오 중 하나를 선택하면 모드가 시작될 때 어떤 일이 발생하는지 생각해 보겠습니다.
파일 스크립트
파일 버전 시작 시 구성 설정에서 "HTTP 프로토콜을 통한 디버깅"이라는 새로운 메커니즘의 사용을 지정해야 합니다.
그러면 Configurator가 자동으로 로컬 서버 사용을 제안합니다. 이 조건을 수락하고 프로그램을 구성자 모드에서 다시 시작해야 합니다.
그 후 새로 시작된 Configurator는 다음 세션에서 선택한 새 방법을 저장합니다. 그러나 동일한 정보 기반에 대해. 따라서 다른 정보 베이스에 액세스할 때 해당 정보도 활성화해야 합니다.
활성화된 메커니즘은 이제 특수 dbgs.exe 응용 프로그램인 디버거 서버를 자동으로 시작합니다. 작업 관리자 창에 표시됩니다.
ownerPID 매개변수의 값은 바인딩된 애플리케이션의 ID와 일치합니다.
Configurator를 통해 디버깅 세션을 시작하면 서버에 자동으로 연결됩니다. 그리고 연결된 개체를 반영합니다.
1C 프로그램이 새 메커니즘 없이 활성화된 경우 1C 서버에서 수동으로 디버깅을 활성화해야 합니다. 이제 서버 주소를 지정해야 합니다.
도구 - 옵션으로 이동
항목 설정에 있습니다.
연결 - 설정으로 이동합니다.
동시에 여러 데이터베이스에서 파일 스크립트를 사용할 때 중요한 뉘앙스를 고려해야 합니다. 각 구성자(HTTP 메커니즘이 활성화된 상태)는 자체 서버를 보냅니다.
따라서 여러 Configurator가 열려 있는 경우 Client에 연결하려면 올바른 Configurator를 지정해야 합니다.
클라이언트-서버 시나리오
이전의 경우와 같이 클라이언트-서버 시나리오에 따라 1C 서버에서 디버깅은 모드를 시작하여 시작됩니다. 이것은 새로운 HTTP 메커니즘의 사용을 지정합니다. 이것은 다음과 같은 방식으로 수행됩니다.
ragent.exe -디버그 -http
실행되면 디버거가 자동으로 뒤에서 시작됩니다.
ownerPID 매개변수의 값은 1C 클러스터 관리자의 식별 번호에 해당합니다.
프로그램은 지금 클러스터의 디버그 서버를 사용하도록 제안을 생성합니다(이전 시나리오에서와 같이 로컬 서버가 아님). 동의하고 다시 시작합니다.
미래에는 모든 것이 파일 스크립트처럼 진행될 것입니다. Server Base Configurator가 실행된 경우에만 로컬 디버거 서버가 더 이상 시작되지 않습니다.
우리 간행물이 1C 서버에서 디버깅을 활성화하는 방법에 대한 문제를 해결하는 데 도움이 되었기를 바랍니다.
버전 8.3.7.1759에서 구현되었습니다.
디버깅 메커니즘을 크게 재설계했습니다. 여기에는 몇 가지 이유가 있습니다. 첫째, 우리는 현재 사용 가능한 모든 응용 프로그램을 디버그할 수 있는 기능을 제공하고자 했습니다. 둘째, 기존 디버거 아키텍처는 현재 추세에 발맞추고 미래에 발전할 수 있도록 변경이 필요했습니다. 셋째, 1C:Enterprise 구성기뿐만 아니라 .
주요 이점
변경 사항의 범위에 대한 아이디어를 제공하기 위해 새 메커니즘의 주요 이점을 간략하게 나열하겠습니다.
HTTP를 통한 디버깅
이전 디버깅 메커니즘은 1C:Enterprise 구성기에 구현된 디버거가 디버깅 개체(클라이언트 및 서버 응용 프로그램)와 직접 상호 작용한다는 사실을 기반으로 했습니다. 이 상호 작용은 TCP/IP 프로토콜을 사용하여 수행되었습니다.
그러나 인터넷에 1C:Enterprise 응용 프로그램이 출시되고 특히 모바일 응용 프로그램이 등장하면서 이러한 접근 방식은 한계와 불편의 원인이 되었습니다. 항상 TCP/IP 프로토콜을 사용하여 디버거가 디버깅 항목을 "통과"할 수 있는 것은 아닙니다. 결국 디버거가 실행 중인 로컬 네트워크 외부에 있을 수 있습니다.
따라서 새로운 메커니즘에서 우리는 전송 프로토콜로 더 "모든 지형" HTTP 프로토콜을 선택했습니다. 그런데 이 프로토콜은 클라이언트 응용 프로그램에서 정보 베이스에 연결하는 데에도 사용됩니다.
최신 디버깅 아키텍처
이전 디버깅 메커니즘의 기능은 구성자를 사용하여 정보 베이스에 연결해야 한다는 것이었습니다. 결과적으로 디버깅 개발자는 모든 관리 기능에 대한 전체 액세스 권한을 가졌습니다.
새로운 디버깅 메커니즘은 더 이상 디버깅 중인 정보 베이스에 연결할 필요가 없습니다. 이제 디버거에 필요한 주요 사항은 클라이언트에 대해 작동하는 동일한 구성입니다. 그것을 얻으려면 디버그된 정보 베이스에 연결할 필요가 없습니다. 예를 들어 파일에서 로드할 수 있습니다.
모바일 애플리케이션 디버깅
HTTP 프로토콜을 사용하여 모바일 플랫폼에서 실행되는 응용 프로그램을 디버깅할 수 있게 되었습니다. 또한 클라이언트, 서버 및 백그라운드 작업과 같은 모든 컨텍스트를 디버그할 수 있습니다.
이제 디버깅하는 동안 쓰기 가능한 모든 변수의 값을 변경할 수 있습니다. 지역 변수를 빠르게 확인하고 변경할 수 있도록 별도의 창을 구현했습니다. 그리고 디버거에 의해 표시되는 표현식의 평가는 이제 비동기 모드에서 수행됩니다.
개발 도구에서 디버깅
새로운 디버깅 메커니즘을 생성할 때 우리는 상호작용을 위한 새로운 범용 프로그래밍 인터페이스를 구현했습니다. 이 인터페이스는 1C:Enterprise configurator에서 사용되며 새로운 개발 환경은 이제 동일한 인터페이스를 사용합니다. 따라서 이제 에서 작업할 때 모든 디버깅 옵션을 사용할 수 있습니다.
디버그 프로세스 아키텍처
새 디버그 아키텍처는 다음과 같습니다.
디버깅에는 디버거, 디버그 항목 및 새 항목이 포함됩니다. 디버그 서버.
디버거와 디버그 항목 간에 정보가 직접 전송되지 않습니다. 모든 상호 작용은 디버그 서버를 통해 구성됩니다. 이것은 메커니즘의 주요 요소입니다. 디버그 서버에는 디버거와 디버그 개체가 서로 정보를 전달하는 메시지 대기열이 있습니다.
디버거 자체와 디버그 항목은 모두 HTTP를 통해 디버그 서버와 통신합니다. 따라서 이러한 디버그 항목이 있는 위치는 이제 중요하지 않습니다.
디버그 서버와의 통신은 디버거 및 디버그 항목에 의해 시작됩니다. 이를 위해 추가 연결이 구성됩니다. 주요 목적은 디버그 서버에 정보가 있는지 확인하는 것입니다. 그리고 그것이 나타나면 이 정보를 얻으십시오.
따라서 상호 작용은 단방향입니다. 정보는 디버그 서버에서 디버거 및 디버그 항목으로 지속적으로 전달됩니다.
정보 베이스 식별
이전 메커니즘은 연결 문자열을 사용하여 정보 베이스를 식별했습니다. 이 결정으로 인해 디버깅 항목과 구성자를 일치시키는 데 어려움이 있는 경우가 있습니다. 첫째, 대소문자를 구분하고 둘째, 일부 컨텍스트를 디버깅할 때 플랫폼이 자동으로 연결 문자열을 형성하기 때문입니다. 그리고 컨피규레이터에서 인포베이스를 연결할 때 지정한 것과 항상 일치하는 것은 아닙니다. 이러한 상황을 찾아 수정하면 디버깅 프로세스가 복잡해집니다.
새로운 메커니즘에서 연결 문자열을 제거했습니다. 이제 우리는 사용하고 있습니다 정보 베이스 식별자. 파일 infobase에서 이러한 식별자는 클라이언트 연결이 처음 연결될 때 생성됩니다. 서버 정보 베이스에서는 클러스터에 등록된 정보 베이스의 ID가 이러한 식별자로 사용됩니다.
여기서 좋은 추가 사항은 현재 플랫폼에서 이전 디버깅 메커니즘을 유지했다는 것입니다(향후 제외될 수 있음). 그리고 원하거나 필요한 경우 사용할 수 있습니다. 따라서 이전 메커니즘을 개선했으며 이제 연결 문자열이 아닌 정보 베이스 식별자도 사용합니다.
일반적인 디버깅 시나리오
애플리케이션 개발자의 관점에서 일반적인 디버깅 시나리오는 변경되지 않았습니다. 유일한 중요한 차이점은 새 디버깅 메커니즘을 활성화해야 한다는 것입니다. 기본적으로 비활성화되어 있기 때문입니다.
그럼에도 불구하고 디버깅을 시작할 때 지금 일어나는 일에 대해 알아가는 것이 좋습니다. 일부 비표준 작업 시나리오에서 유용할 수 있기 때문입니다.
파일 옵션
파일 모드에서 디버깅을 시작하기 전에 구성기 설정에서 새 디버깅 메커니즘을 사용하도록 지정해야 합니다. " HTTP를 통한 디버깅».
이 경우 구성자는 자동으로 로컬 디버그 서버를 사용하라는 메시지를 표시합니다. 이에 동의하고 구성기를 다시 시작해야 합니다.
설정한 디버깅 방법은 Designer 세션 간에 저장되지만 정보 베이스의 컨텍스트에 저장됩니다. 따라서 다른 정보 베이스의 경우 다시 활성화해야 합니다.
이제 구성 프로그램이 시작되거나 다시 시작될 때 플랫폼은 디버그 서버도 자동으로 시작합니다. 이것은 독립 실행형 dbgs.exe 응용 프로그램입니다. 작업 관리자에서 볼 수 있습니다.
소유자PID 매개변수에는 이 디버그 서버를 소유하는 애플리케이션의 ID가 포함됩니다. 이 경우 1C:Enterprise 구성기입니다.
이제 구성기에서 1C:Enterprise 디버깅 세션을 시작하면 디버그 서버에 자동으로 연결되고 구성기에서 연결된 디버깅 항목을 볼 수 있습니다.
1C:Enterprise 세션이 디버깅 없이 시작된 경우 이전과 같이 디버거에 연결할 수 있습니다. 이제 디버그 서버의 주소를 지정해야 합니다.
디버그 항목 설정에서 이 주소를 찾을 수 있습니다.
한 번에 여러 파일 기반으로 작업하는 것과 관련된 특이한 순간이 있습니다. 파일 버전에서 http 디버깅이 활성화된 각 구성자는 다른 포트에서 디버그 서버의 자체 복사본을 실행합니다.
따라서 한 번에 여러 구성자가 열려 있는 경우 클라이언트 응용 프로그램을 디버거에 연결하려면 그 중에서 올바른 구성자를 선택해야 합니다.
클라이언트-서버 옵션
클라이언트-서버 모드에서 디버깅을 시작하기 전에 이전과 같이 디버그 모드에서 1C:Enterprise 서버를 시작해야 하지만 새 HTTP 메커니즘이 디버깅에 사용되도록 지정해야 합니다. 예를 들면 다음과 같습니다.
ragent.exe -디버그 -http
이러한 방식으로 서버를 시작하면 디버그 서버도 시작됩니다.
ownerPID 매개변수에는 1C:Enterprise 클러스터 관리자의 ID가 있습니다.
이제 구성기 설정에서 파일 기반의 경우와 같이 새 디버깅 메커니즘을 사용하도록 지정해야 합니다. " HTTP를 통한 디버깅».
이 경우 구성자는 자동으로 로컬 서버가 아닌 클러스터 디버그 서버를 사용하도록 제안합니다. 이에 동의하고 구성기를 다시 시작해야 합니다.
디버그 항목 연결
구성자에서 디버깅 세션을 시작할 때 응용 프로그램은 디버깅 항목(클라이언트 및 서버 모두)을 디버그 서버에 자동으로 연결합니다.
동시에 이전과 마찬가지로 실행 방법에 관계없이 구성자에서 디버그 항목의 자동 연결을 구성할 수 있습니다. 이제 이러한 기회가 훨씬 더 풍부해졌습니다.
첫째, 플랫폼은 이제 선택할 수 있는 모든 가능한 디버깅 항목을 제공합니다.
그리고 두 번째로 더 미묘한 튜닝 방법이 등장했습니다. 이것은 미리 만들어진 선택을 사용하는 것입니다.
디버그 항목을 연결할 때와 사용 가능한 디버그 항목을 볼 때 이러한 필터를 사용할 수 있습니다.
선택 항목에서 디버깅 항목 자체 외에도 관심 있는 세션의 특정 사용자를 지정할 수 있으며, 데이터 분리를 사용하는 경우 디버깅할 정보 베이스 영역을 지정할 수도 있습니다.
변수, 개체 속성 및 비동기식 평가 변경
새로운 디버깅 메커니즘을 사용하면 디버깅하는 동안 변수 값을 변경할 수 있습니다. 이전 메커니즘에서는 그러한 가능성이 없었습니다.
가장 일반적인 작업으로 보이는 지역 변수를 편리하게 보고 변경할 수 있도록 "창"을 구현했습니다. 지역 변수».
외견상, 그것은 당신에게 친숙한 "스코어보드"와 매우 유사합니다. 그러나 첫째, 이 창은 이미 모든 지역 변수로 자동으로 채워져 있고 둘째, 이제 변수 값을 변경할 수 있습니다.
셀에서 직접 기본 유형의 값을 변경할 수 있습니다 " 의미»:
다른 값을 변경하려면 표현식 입력 창을 사용할 수 있습니다.
좋은 보너스는 상황별 도움말이 이 창에서 완전히 작동한다는 것입니다.
정확히 같은 방식으로 쓰기에 사용할 수 있는 모든(로컬뿐만 아니라) 변수, 속성의 값을 변경할 수 있습니다. 표현식 계산 창(Shift+F9 명령으로 호출됨)에서 "값" 셀과 별도의 대화 상자를 사용하여 변수 값을 변경할 수 있습니다.
그런데 이제 표현식 평가 자체가 비동기적으로 수행됩니다. 이것은 구성자가 디버그 항목의 계산을 명령한다는 것을 의미합니다. 그리고 언젠가는 이 계산이 서버에서 예상됩니다. 계산이 완료되면 결과가 즉시 구성기로 전송됩니다. 계산이 오랜 시간 동안 실행되면 이러한 계산의 결과가 나중에 구성기에 비동기적으로 전달됩니다. 이 접근 방식을 사용하면 구성기에서 긴 계산을 기다리지 않고 작업을 계속할 수 있습니다.
관련 출판물
-
연결 오류 코드 및 설명
VPN 연결을 시작할 때 오류가 발생하면 세 자리 코드를 기억하거나 적어 두어야 합니다. 일반적으로 오류는 ...
-
4x100 휠이 VAZ 이전에 맞을까요?
4는 볼트 구멍의 수입니다. 98과 100은 원의 지름(mm)입니다. 거리를 계산해보면...