흥미로운 점은 - .NET 2.0/.NET 3.0/.NET 3.5에 대해 VS2005/VS2008을 실행하면 BackgroundWorker 스레드가 해당 스레드를 시작한 WinForms 폼의 컨트롤을 직접 업데이트하지 않을 수 있습니다. System.InvalidOperationException BackgroundWorker "크로스 스레드 작업이 유효하지 않습니다 : 컨트롤이 '만든 스레드가 아닌 다른 스레드에서 액세스 제어하십시오." 2004 년에 이걸 때리는 것을 기억합니다. 처음에는 백그라운드 스레드가있는 .NET WinForms 앱을 작성하기 시작했습니다. 문제를 둘러싼 몇 가지 방법이 있습니다.이 질문은 대답을 묻는 질문이 아닙니다.VS2010/.NET 4.0의 BackgroundWorker 스레드 액세스의 차이점은 무엇입니까?
저는 최근에 VS2010/.NET 4.0으로 작성되었을 때 이 인 것을 들었습니다. 이런 종류의 객체 액세스 제한은 항상 thread-safe 프로그래밍의 상당히 기본적인 부분 이었기 때문에 이것은 거의 불가능합니다. BackgroundWorker 스레드가 자신이 소유하지는 않지만 상위 UI 양식으로 소유 한 객체에 직접 액세스 할 수있게하는 것은 그 원칙과 반대되는 것으로 보입니다. .NET 4.0 문서를 통한 트롤 (trawl)은이 동작을 설명 할 수있는 명백한 변경을 드러내지 않았습니다.
VS2010/.NET 4.0에서이를 테스트하지 못했습니다. 해당 도구 집합에 대한 액세스 권한이있는 사용자는 해당 종류의 스레드 상호 작용을 허용하도록 모델이 변경되었는지 여부를 확실히 알고 있습니까? 나는 그것을 미래에 활용하거나, 실마리를 배포하고 싶습니다. ;)
네, 개인 랩톱에 VS2010을 설치 한 사람을 찾아서 테스트했습니다. 항상 그렇듯이 예외가 발생합니다. Cluestick이 배치되었습니다. –