생각지도 못했는데, 이거 제대로 안 나오고 있네요.
요로케 세팅했구요.
CollectionsMarshal.AsSpan() 의 내용을 좀 볼라했드만
이렇게 나옵니다.
설마 설마 하는 마음으로 다른 것들도 눌러보니 다 저렇게 throw null; 이거나 빈 내용으로 나오네요.
이거 저만 그런건가요?
2개의 좋아요
아, 커뮤니터 버전 17.0.2 x64 입니다.
1개의 좋아요
저도 마찬가지에요 ^^; 이런 생산적인 커뮤니티 좋습니다.
일단, 소스코드 확인은 https://source.dot.net 을 이용하시고요,
저는 엣지의 기능으로 설치해서 사용하고 있습니다.
1개의 좋아요
이 글을 보면 되어야 하는 것 처럼 보이는데요, 아래 노트의 ILSpy 관련 엑세스 조항 동의와 관련이 있어 보입니다. 관련 내용 검색해서 원인 알게 되면 다시 공유 해볼께요.
1개의 좋아요
뭔가 이상하네요.
decompile 관련된 이슈가 잘 검색이 안 되는군요.
ILSpy 도 VS2022에 preview 라고 붙어있는데다
extension으로 직접 받아서 실행해도 결과가 똑같이 나옵니다.
(저 throw null; 이 아예 ILSpy에서 생성한 결과네요.)
이정도면 커뮤니티에서 이슈가 있어야할 거 같은데 잘 검색이 안 되는 이유가 뭘까요?
제가 뭔가 검색을 잘 못하고 있는 건가요…?ㅅ?
1개의 좋아요
이 글에 의하면… 흐음… 기능 동작이 아직 안되는 것 같습니다!
그나마 희망적인 건 이 이슈가
epic으로 등록되었다는 점입니다. (epic으로 등록되었다는 의미는 MS가 앞으로 해결 할 중요도로 설정했다는 의미입니다)
2개의 좋아요
In Progress! -ㅁ-;;;
이거 구글링보다 그냥 로슬린 깃헙에서 검색하는 게 더 많이 나오는 군요.
앞으론 그냥 깃헙 이슈를 보는 걸로…;;;
근데 #58271 이슈는 2018년에 리포팅된건디…;;
이쯤되면 그냥 내년에 출시하지 그랬어… 라는 느낌이 자꾸만 드는군요…
(아직 VS2019 가 쌩쌩하니까 뭐…)
1개의 좋아요
제 생각에는 구현의 어려움 보다는 전체 글을 다 읽어보지는 않아 정확하지는 않지만 정책에 의한 것으로 보이는데요, 일단은 source.dot.net을 이용하시는 것으로… 쿨럭
2개의 좋아요
참고로 저는 ILSpy로 디컴파일이 잘 되는것은 확인 했습니다. (ILSpy 2022 Preview 설치했어요)
1개의 좋아요
전 또 뭘 잘못했을까요…;ㅅ;
1개의 좋아요
아 이게 throw null;이 나오는 힌트가 될 수 있겠군요. 일단, 메타데이터는 소스코드없이 코드 바디가 throw null;이라고 해요.
1개의 좋아요
음… 이게 좀 다르군요.
제가 ILSpy로 접근한 건 VS2022에서 decompile 된 코드에서 표시한 어셈블리인데요
Snippet
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0\ref\net6.0\System.Runtime.InteropServices.dll
요거를 ILSpy 로 읽었더니 reference assembly 로 마킹되었다는 경고와 함께 throw null; 을 표시하네요.
근데 ILSpy에서 직접 Manage Assembly lists 에서
Microsft.NETCore.App 6.0 을 추가한 다음
System.Runtime.InteropServices.dll 가 아닌 System.Private.CoreLib.dll 을 로딩해서
읽으면 정상적으로 소스 코드가 보입니다.
음… 얘긴 즉슨, VS2022 가 ILSpy 를 사용하는 건 맞다는 얘기 같군요.
어쨌든 지금은 좀 불편해도 웹소스를 따라다는 게 답이네요…-ㅂ-;;;
2개의 좋아요
이건 참조 어셈블리이기 때문에 그렇게 보이는 것입니다.
C# 7.1 - 참조 어셈블리(Ref Assemblies)
; .NET Framework: 748. C# 7.1 - 참조 어셈블리(Ref Assemblies)
.NET Core 쪽이 그런 식으로 참조 어셈블리를 함께 제공하고 있기 때문에 비주얼 스튜디오에서 소스 보기를 하면 그렇게 나오는 것입니다.
어쩔 수 없습니다. 이건 마이크로소프트가 한 번 더 어셈블리의 진본을 찾아서 연결해 주어야 하는데 아무래도 단순한 작업은 아닌지 꽤나 시간이 흘렀는데도 구현해 주지 않고 있습니다.
아쉬운데로, 소스 보기를 정확히 하려면 디버깅을 시작해서 모듈 창을 띄운 후 나오는 어셈블리의 경로를 알아내 ILSpy 같은 도구를 이용해 역어셈블하면 됩니다.
4개의 좋아요
@kevin13 아하! 이것였군요 ~ㅁ~
올리신 글을 몇 번을 봤는데도 제가 직접 당해보질 않으니 그 땐 그냥 그랬는데… ;ㅂ;
와… 그런데 이거 습관이 무섭다고,
생각없이 F12 눌러서 throw null; 뜨는 거 보고… 왜 안나왘! 이러고 있습니닷 -ㅂ-;;
근데 거기에서 표시된 어셈블리 자체가 이미 Ref Assembly 라서 이거
ILSpy로 따라 가는 것도 한 번 체크를 해줘야하는군요.
region에 표시된 경로에 이미 ref 가 표시되어 있습니다. 표시한 어셈블리가 이미 ref assembly 이죠.
저 경로에 있는 어셈블리를 decompile 하면 똑같이 throw null;로 표시됩니다.
그래서 이거 VS 디버깅에 표시되는 모듈을 보면
그런데 경로가 다르긴 한데 저것도 Ref Assembly 입니다.
어쨌든 저 경로로 ILSpy 에서 로딩해보면
References 항목에 저렇게 Ref Assembly 임을 표시하고 있는데요.
근데 References 는 잘 안 눌러보게 되잖아요.
그래서 그냥 그런가보다 하고 타입을 따라가다보면
이미 System.Runtime.InteropServices 네임스페이스에 CollectionMarshal 타입이 없어요;;;
그리하야 어셈블리 항목을 다시 눌러보면
저렇게 TypeForwardedTo 로 선언되어 있는게 보입니다. 그리고 저걸 눌러보면
실제 연결된 어셈블리와 타입으로 이동하게 되고, 소스코드 역시 잘 보이게 됩니다.
결론은…
VS에서 지원해줄 때까지는 잘 모르는 어셈블리라면 한 번은 헤딩을 해야한다는 거군요. ;ㅂ;
2개의 좋아요
역시 jetbrain이 짱이군요.
2개의 좋아요