XAML의 네임 스페이스 오류에 이름이 없습니다.

VB.NET WPF 응용 프로그램에서 작동하는 VS2012 사용. WPF를 배우는 데 사용하는 간단한 MusicPlayer 튜토리얼 앱이 있습니다. 튜토리얼의 C # 버전을 단계별로 VB.NET으로 변환하고 있습니다.

동일한 네임 스페이스 아래에있는 두 개의 클래스가 앱에 있습니다. XAML에서 네임 스페이스를 참조 할 수 있지만 XAML에서 클래스 개체를 참조하려고하면 오류가 발생하고 컴파일 할 수 없습니다.

이상한 점은 IntelliSense가 xmlns : c = 태그를 통해 네임 스페이스를 참조하고 클래스 개체를 입력 할 때도 잘 작동한다는 것입니다. <c: 그러나 개체에 밑줄이 표시되고 디자이너에서 빌드하거나 작업하려고하면 오류가 생성됩니다.

.vb 클래스 파일은 \ Controls라는 폴더에 있습니다. 메인 프로젝트 루트 네임 스페이스는 의도적으로 비워 둡니다. 클래스는 다음과 같이 코딩됩니다.

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

xaml은 다음과 같습니다.

( <Window >태그에 정의 된 네임 스페이스

xmlns:c="clr-namespace:MusicPlayer.Controls"

(에 정의 된 객체 <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(오류 표시됨) "UpdatingMediaElement"이름이 "clr-namespace : MusicPlayer.Controls"네임 스페이스에 없습니다.

무엇이 잘못되었거나 어떻게 해결해야하는지 잘 모르시겠습니까?

wpf 코드와 VS를 작성할 때 "이름 ABCDE가 네임 스페이스 clr-namespace : ABC에 존재하지 않습니다"라고 말합니다. 그러나 프로젝트를 완전히 성공적으로 빌드 할 수 있습니다. UI 디자인을 볼 수 없거나 코드를 정리하고 싶기 때문에 약간의 불편 함이 있습니다.

다음을 시도하십시오.

• VS에서 솔루션-> 속성-> 구성 속성을 마우스 오른쪽 버튼으로 클릭하십시오.

• 새 대화 상자가 열리면 프로젝트 구성을 디버그에서 릴리스로 또는 그 반대로 변경해보십시오.

그 후 솔루션을 다시 빌드하십시오. 문제를 해결할 수 있습니다.

어셈블리가 클래스가 포함 된 네임 스페이스와 다른 경우 명시 적으로 지정해야합니다.

전의:-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

Xaml Design Shadow Cache를 지워서이 문제가 해결되는 것을 보았습니다. Visual Studio 2015 업데이트 1에 문제가 있습니다.

Visual Studio 2015에서 캐시는 다음 위치에 있습니다.

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

방법:

1. 솔루션 탐색기에서 솔루션을 마우스 오른쪽 단추로 클릭하고 "솔루션 정리"를 선택합니다.
2. Visual Studio 종료
3. ShadowCache 폴더 삭제
4. Visual Studio 프로젝트를 다시 열었습니다.
5. 솔루션 재 구축

그리고 더 이상 네임 스페이스 오류가 없습니다.

제 경우에는 다른 컴파일 오류 때문이었습니다 . 다른 오류가 해결되면이 관련 오류도 목록에서 제거되었습니다. 특히 오류 목록 하단과 최근에 변경 한 페이지의 오류입니다.

따라서이 오류에 직접주의를 기울이지 말고 처음 에는 다른 오류 에 집중하십시오 .

빌드 대상 플랫폼을 x86으로 변경하고 프로젝트를 빌드 해보십시오.

Subversion을 통해 프로젝트 빌드 플랫폼 대상을 x64로 변경 한 것으로 나타났습니다. 이것이 내가 만든 유일한 변화였습니다. 변경 한 후 코드가 잠시 작동 한 후 발생한 동일한 오류가 표시되기 시작했습니다. 테스트를 위해 플랫폼 타겟을 x86으로 변경했는데 갑자기 디자이너가 다시 작업하고있었습니다. 그 후 x64로 다시 변경했는데 문제가 완전히 사라졌습니다. 디자이너가 x32에서 일종의 캐시 된 코드를 빌드하고 x64 빌드 플랫폼을 변경하면 코드를 변경할 때 코드가 손상되는 것으로 생각됩니다.

이것이 다른 사람에게 도움이된다면 Dunno

나는 WPF를 처음 접했고 여전히 VB.net을 사용하는 초보자입니다. 그래서이 오류가 발생하는 것은 내가 정상 회담을 어리석은 일로 인해 발생했다고 가정했습니다. 프로젝트를 공유 드라이브에서 로컬 드라이브 중 하나로 이동하여 제거했습니다. 오류가 사라지고 프로젝트가 더 이상 문제없이 컴파일됩니다. VS2015가 공유 드라이브에있는 프로젝트에 여전히 문제가있는 것 같습니다.

프로젝트가 컴파일되지만 XAML 오류가 표시되는 경우에 대한 또 다른 솔루션 일 수 있습니다.

1. 솔루션 탐색에서 xaml이 포함 된 프로젝트 노드에서
2. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 '프로젝트 언로드'를 선택하십시오.
3. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 '프로젝트 다시로드'를 선택하십시오. 프로젝트가 여전히 "시작 프로젝트"로 선택되어 있는지 확인하십시오. 그렇지 않은 경우 :
4. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 '시작 프로젝트로 설정'을 선택합니다.

다시 빌드하거나 Visual Studio를 닫을 필요가 없습니다.

맙소사 ... 이것은 Visual Studio 2017에서 5 년 후에도 여전히 문제입니다. WPF를 처음 사용했기 때문에 문제가 어떻게 든 저라고 확신했지만 모든 것이 제대로 컴파일되고 실행되었습니다.

재 구축, 정리 및 재 구축, x86 / x64 출력 간 전환, Windows 재부팅, ShadowCache 폴더 정리, XML 네임 스페이스 선언에 "; assembly = {my main assembly name}"추가를 시도했지만 아무것도 작동하지 않았습니다! 한 가지 일 :

내 정적 명령 클래스 (내 경우에는 설계가 내 WPF 명령을 검색하도록하는 것이 었습니다)를 별도의 어셈블리에 넣고 어셈블리 이름을 그 이름으로 변경합니다.

저도 같은 문제를 겪고, 내 경우에는 마크 업 디자인보기 솔루션을 다시달라고 부탁하고이 메시지와 함께 나에게 양식 레이아웃을 보여주지 않았다 Design view is unavailable for x64 and ARM target platforms, 또는 Build the Project to update Design view.

솔루션을 다시 빌드해도 문제가 해결되지 않습니다 (디자인보기도 "이름이 네임 스페이스에 없습니다"오류가 없음).

Solution-> Properties> Configuration Properties의 설정을 가지고 놀았 기 때문이라고 생각합니다.

마침내 두 가지 작업으로 문제를 해결했습니다.

1. 페이지의 빌드 열에있는 모든 확인란 선택 : 솔루션-> 속성-> 구성 속성
2. 솔루션 구성을 디버그 에서 릴리스로 또는 그 반대로 변경합니다 .

Visual Studio2012 업데이트 2의 버그라고 생각합니다.

동일한 문제가 Visual Studios 2013, 서비스 팩 4를 괴롭 힙니다. 또한 동일한 결과로 Visual Studios 2015 Preview에서 시도했습니다.

Visual Studios 팀이 수정하지 않은 WPF 시각화 도우미의 제한 일뿐입니다. 증거로 x86 모드로 빌드하면 시각화 도우미가 활성화되고 x64 모드로 빌드하면 비활성화됩니다.

이상하게도 충분한 정보가 Visual Studios 2013, 서비스 팩 4에서 작동합니다.

최근에 .NET 4.6.2의 WPF 프로젝트에 VS 2015 업데이트 3을 사용 하여이 문제가 발생했습니다. 내 프로젝트의 사본이 네트워크 폴더에 있었고 로컬로 이동하여 문제가 해결되었습니다.

이것은 VS 2015가 네트워크 경로를 좋아하지 않는 것처럼 보이기 때문에 다른 종류의 문제를 해결할 수 있습니다. 그들에게 큰 문제인 또 다른 문제는 내 프로젝트가 네트워크 경로에있는 경우 git 저장소를 동기화하는 것입니다. 또한 로컬로 이동하여 해결됩니다.

이 문제는 다양한 "트릭"을 통해 해결 될 수있는 것 같습니다.

제 경우에는 솔루션 내에서 작업중인 프로젝트 대신 전체 솔루션을 빌드 / 재 구축 / 청소했습니다. "[내 프로젝트] 빌드"를 클릭하면 오류 메시지가 사라졌습니다.

어셈블리 참조를 확인하십시오. 프로젝트 참조에 노란색 느낌표가 있으면 거기에 문제가 있으며 모든 종류의 오류가 발생합니다.

프로젝트 참조가 올바른지 알고 있으면 대상 프레임 워크를 확인하십시오. 예를 들어, 4.5 프레임 워크를 사용하는 프로젝트에서 4.5.2 프레임 워크를 사용하는 프로젝트를 참조하는 것은 좋은 조합이 아닙니다.

나를위한 해결책은 어셈블리 DLL의 차단을 해제하는 것이 었습니다. 표시되는 오류 메시지는이를 나타내지 않지만 XAML 디자이너는 "샌드 박스"어셈블리라고 부르는 것을로드하지 않습니다. 빌드 할 때 출력 창에서 볼 수 있습니다. DLL은 인터넷에서 다운로드되는 경우 차단됩니다. 타사 어셈블리 DLL 차단을 해제하려면 :

1. Windows 탐색기에서 DLL 파일을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
2. 일반 탭 하단에서 "차단 해제"버튼 또는 확인란을 클릭합니다.

참고 : 안전하다고 확신하는 경우에만 DLL 차단을 해제하십시오.

제 경우에는 사용자 정의 컨트롤이 기본 프로젝트에 추가되었습니다. 위의 다양한 솔루션을 시도해 보았습니다. 잘못된 마크 업이 표시되지만 솔루션이 컴파일 및 작동하거나 xmlns : c = "clr-namespace : MyProject; assembly = MyProject"를 추가 한 다음 마크 업이 표시되지만 컴파일 오류가 발생합니다. XML 네임 스페이스에 태그가 없습니다.

마지막으로 새 WPF 사용자 컨트롤 라이브러리 프로젝트를 솔루션에 추가하고 기본 프로젝트에서 해당 프로젝트로 사용자 컨트롤을 이동했습니다. 참조를 추가하고 새 라이브러리를 가리 키도록 어셈블리를 변경했으며 마지막으로 태그가 작동하고 프로젝트가 오류없이 컴파일되었습니다.

나는 모든 답변을 봤지만 아무도 나를 도왔습니다. 마침내 혼자서 해결할 수 있었으므로 다른 사람들에게 도움이 될 수있는 답을 제시했습니다.

필자의 경우 솔루션에는 모델이 포함 된 프로젝트 (예 : 프로젝트 및 어셈블리 이름이 Models )와 뷰 및 뷰 모델이 포함 된 프로젝트가 두 개있었습니다 (우리의 규칙에 따라 프로젝트, 어셈블리 이름 및 기본 네임 스페이스는 Models.Monitor ). . Models.Monitor는 모델 프로젝트를 참조했습니다.

Models.Monitor 프로젝트에서 xaml 중 하나에 다음 네임 스페이스를 포함했습니다. xmlns : monitor = "clr-namespace : Models.Monitor"

나는 의심 그들이 어셈블리 '모델'에서 '모니터'유형을 찾기 위해 노력했다으로 MSBUILD 및 Visual Studio 다음 밖으로 erroring했다 . 해결하기 위해 다음을 시도했습니다.

1. xmlns : monitor = "clr-namespace : Models.Monitor; assembly ="-네임 스페이스가 https://msdn.microsoft.com/en-us/library/ms747086(v=vs에 따라 동일한 어셈블리에있는 경우 유효 함) .110) .aspx
2. 또한 명시 적 네임 스페이스 선언을 시도했습니다. xmlns : monitor = "clr-namespace : Models.Monitor; assembly = Models.Monitor"

위의 어느 것도 작동하지 않았습니다.

마지막으로 포기하고 해결 방법 으로 UserControl을 다른 네임 스페이스 'ModelsMonitor'로 사용하려고했습니다 . 그 후 잘 컴파일 할 수있었습니다.

제 경우에는 네임 스페이스와 클래스의 철자가 똑 같았습니다. 예를 들어 제 네임 스페이스 중 하나는

firstDepth.secondDepth.Fubar

자체 클래스 (예 : firstDepth.secondDepth.Fubar.someclass)를 포함합니다.

하지만 네임 스페이스에 ' Fubar '클래스도 있습니다.

firstDepth.secondDepth

위의 Fubar 네임 스페이스와 동일하게 텍스트로 확인됩니다.

이러지마

제 경우 문제는 프로젝트의 obj 디렉토리 아래에있는 일부 팬텀 파일 때문이었습니다. 다음은 나를 위해 문제를 해결했습니다.

• 깨끗한 프로젝트
• VS 종료
• rm -rf / obj / *
• VS 호출 및 재 구축

나는 또한 이것에 많은 어려움을 겪고있다! Intellisense는 네임 스페이스와 모든 것을 완성하는 데 도움이되지만 컴파일러는 울었습니다. 이 스레드와 다른 스레드에서 찾은 모든 것을 시도했습니다. 그러나 제 경우에는 결국 다음과 같이 작성하는 것이 도움이되었습니다.

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

어셈블리 이름을 비워 둡니다. 이유를 모르겠습니다. 그러나 여기에 언급되었습니다. 어셈블리를 개발 중이므로 어셈블리 특성이 의미가있을 수 있음을 추가해야합니다. 그러나 어셈블리 이름을 입력하면 작동하지 않았습니다. 그래서 이상한.

VB.NET은 C # 에서처럼 폴더 구조를 기반으로 네임 스페이스 정보를 자동으로 추가하지 않습니다. 나는 당신과 동일한 튜토리얼 (24 시간 안에 WPF 학습)을 진행하고 있으며 VB로 동일한 변환을 수행하고 있다고 생각합니다.

책에 설명 된대로 네임 스페이스를 사용하려면 XAML 클래스와 XAML.VB 코드 모두에 네임 스페이스 정보를 수동으로 추가해야합니다 . 그럼에도 불구하고 VB는 VB 에서처럼 어셈블리에 네임 스페이스를 자동으로 할당하지 않습니다.

여기에 네임 스페이스 정보를 자동으로 빌드하도록 프로젝트 템플릿에이를 포함하는 방법을 보여주는 또 다른 문서가 있습니다. 새 항목을 추가 할 때 네임 스페이스를 자동으로 추가합니다.

솔루션 속성 페이지에서 "UpdatingMediaElement"가 포함 된 어셈블리의 플랫폼과 "UpdatingMediaElement"가 하위 클래스를 구성하거나 구현하는 모든 수퍼 클래스 및 인터페이스를 포함하는 어셈블리를 확인합니다. 이러한 모든 어셈블리의 플랫폼은 "AnyCPU"여야합니다.

또 다른 가능한 원인 : 빌드 후 이벤트가 빌드 폴더에서 프로젝트 DLL을 제거하는 것입니다.

명확히하기 위해 : WPF 디자이너는 이름이 네임 스페이스에 존재하고 빌드 후 이벤트가 프로젝트 DLL을 제거하는 경우 프로젝트가 정상적으로 빌드되고 실행되는 경우 에도 "이름 XXX가 네임 스페이스에 없습니다 ..."라고보고 할 수 있습니다. 빌드 폴더 (bin \ Debug, bin \ Release 등). Visual Studio 2015에서 이에 대한 개인적인 경험이 있습니다.

좋아, 불행히도 이러한 팁 중 어느 것도 나를 위해 일하지 않았습니다. 결국 문제를 해결할 수있었습니다. Visual Studio가 네트워크 드라이브에서 잘 작동하지 않는 것 같습니다. 프로젝트를 공유 드라이브에서 로컬로 이동하여이 문제를 해결하고 다시 컴파일했습니다. 더 이상 오류가 없습니다.

더미에 추가.

내 것은 WPF 응용 프로그램의 어셈블리 이름이 참조 된 dll과 동일한 어셈블리 이름이었습니다. 따라서 프로젝트에 중복 된 어셈블리 이름이 없는지 확인하십시오.

솔루션이 네트워크 공유에 저장되어 있었고 열 때마다 신뢰할 수없는 소스에 대한 경고가 표시되었습니다. 나는 그것을 로컬 드라이브로 옮겼고 "네임 스페이스가 존재하지 않습니다"오류도 사라졌습니다.

또한 프로젝트-> 속성을 ​​마우스 오른쪽 버튼으로 클릭하고 플랫폼 대상을 모든 CPU로 변경하고 다시 빌드하면 작동합니다. 이것은 나를 위해 일했습니다.

이 문제는 참조하는 어셈블리가 실제로 빌드되지 않은 경우에도 발생할 수 있습니다. 예를 들어 xaml이 Assembly1에 있고 Assembly1에서도 클래스를 참조하지만 해당 어셈블리에 오류가 있고 빌드되지 않는 경우이 오류가 표시됩니다.

나는 그것에 대해 어리석은 느낌이 들지만, 내 경우에는 사용자 제어를 찢어 버리고 그 결과 관련 클래스에서 모든 종류의 오류가 발생했습니다. 내가 문제의 모든 오류를 해결하려고 시도하면서 xaml이 이러한 참조를 찾기 위해 빌드 된 어셈블리에 의존한다는 사실을 깨닫지 못했습니다 (빌드하기 전에도 문제를 해결할 수있는 C # / vb 코드와 달리).

어셈블리를 프로젝트로 추가했습니다. 먼저 dll에 대한 참조에 특별히 추가 된 ddl을 삭제했습니다.

이 문제는 항상 발생합니다. 내 뷰는 WPF 사용자 지정 컨트롤 라이브러리 프로젝트 (클래스 라이브러리의 변형)에 있습니다. 미리 빌드 된 어셈블리를 참조 할 수 있지만 동일한 솔루션의 다른 프로젝트에있는 코드는 참조 할 수 없습니다. 코드를 xaml과 동일한 프로젝트로 이동하자마자 인식됩니다.

제 경우에는 wpf 프로그램의 아키텍처가 종속성과 정확히 일치하지 않을 때이 문제가 발생합니다. x64 인 종속성이 있고 다른 하나는 AnyCPU 인 종속성이 있다고 가정합니다. 그런 다음 x64를 선택하면 AnyCPU dll의 유형이 "존재하지 않음"이되고, 그렇지 않으면 x64 dll의 유형이 "존재하지 않음"이됩니다. 둘 다 에밀 레이트 할 수는 없습니다.