Cообщество разработчиков на платформе Microsoft > Форумы > Visual Studio WPF Designer > "Assembly '...' Was Not Found" When including a reference to a local namespace
Задайте вопросЗадайте вопрос
 

Отвечено"Assembly '...' Was Not Found" When including a reference to a local namespace

  • 8 мая 2008 г. 5:45Paul Hounshell Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    I've got a WPF application with a window and a usercontrol:

     

    Window:

     

    <Window x:Class="UI.Windows.Main"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:local="clr-namespace:UI.Windows.Documents"

    Title="Window1" Height="600" Width="800">

    <DockPanel>

    <!-- Snip -->

    </DockPanel>

    </Window>

     

     

    UserControl:

     

    <UserControl x:Class="UI.Windows.Documents.MyDisplay"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml>

    <Grid>

    <!-- Snip -->

    </Grid>

    </UserControl>

     

     

     

    Now, when I try to look at this in the designer i get an error saying Assembly 'UI' was not found.  I've searched high and low, but the internet is full of references to this being a 2005 issue and the solution is to upgrade to 2008.  I'm already using 2008 (don't even have 2005 installed on the machine), and I still get the problem.

Ответы

  • 12 мая 2008 г. 3:23Atul GuptaMVPМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     Отвечено
     Tim Dawson wrote:

    I have a feeling the Cider designer doesn't actually support this scenario, i.e. a UserControl in the same assembly as what you're designing.

     

    What you say Tim was more for VS 2005. In VS 2008, this works prefectly fine and i have been using UserControl's from same assembly in the XAML without any issues.

     

    Assuming I have an application with namespace as TestWPFApp and a Main window XAML and a UserControl in that, I include the following in my main window XAML

     

    xmlns:local="clr-namespace:TestWPFApp"

     
    and then i can reference the user control below as
     

    <local:myUserControl />

     
    and this works perfectly fine. You may have to build the solution once to create the assembly. Till that time designer may give an error.
     
    In the fact the good part in VS 2008 is that when you type in xmlns:local= the intellisense pops up and provides a list of valid inclusions and the one i added, was listed as an option, so i don't even have to figure the right one out and type it.

Все ответы

  • 8 мая 2008 г. 9:19AlagurajaPandian Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

     

     In the Window xaml can you please try this...

     

    xmlns:local="clr-namespace:UI.Windows.Documents;assembly=UI.Windows.Documents"

     

    should work..
  • 8 мая 2008 г. 11:30Paul Hounshell Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    My project's namespace is actually "UI.Windows", but I tried all of the below lines and all gave me the same error (except for the name of the assembly it couldn't find)

     

    xmlns:local="clr-namespace:UI.Windows.Documents;assembly=UI.Windows.Documents"

    xmlns:local="clr-namespace:UI.Windows.Documents;assembly=UI.Windows"

    xmlns:local="clr-namespace:UI.Windows.Documents;assembly=UI"

    xmlns:local="clr-namespace:UI.Windows.Documents;assembly="
  • 8 мая 2008 г. 11:44Tim DawsonMVPМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    I have a feeling the Cider designer doesn't actually support this scenario, i.e. a UserControl in the same assembly as what you're designing.

  • 8 мая 2008 г. 11:58Paul Hounshell Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    That would seem really odd on 2 counts:

     

    1.) Wouldn't this be the first thing someone would try when trying UserControls for the first time?  It would also seem like an arbitrarily unneccessary requirement that UserControls be in a separate assembly.

     

    2.) In several places in the documentation, Microsoft says that if the namespace you're looking for is in the current assembly, you can omit the assembly part of that uri, or include it but leave the assembly blank.  Either refers to the current assembly.

     

    From MSDN:

     

    Mapping to Current Assemblies

    assembly can be omitted if the clr-namespace referenced is being defined within the same assembly as the application code that is referencing the custom classes. Or, an equivalent syntax for this case is to specify assembly=, with no string token following the equals sign.

     

    http://msdn.microsoft.com/en-us/library/ms747086.aspx

  • 12 мая 2008 г. 2:30Marco Zhou Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I moved this thread from WPF forum to Cider forum for better answers.

    Thanks
  • 12 мая 2008 г. 3:23Atul GuptaMVPМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     Отвечено
     Tim Dawson wrote:

    I have a feeling the Cider designer doesn't actually support this scenario, i.e. a UserControl in the same assembly as what you're designing.

     

    What you say Tim was more for VS 2005. In VS 2008, this works prefectly fine and i have been using UserControl's from same assembly in the XAML without any issues.

     

    Assuming I have an application with namespace as TestWPFApp and a Main window XAML and a UserControl in that, I include the following in my main window XAML

     

    xmlns:local="clr-namespace:TestWPFApp"

     
    and then i can reference the user control below as
     

    <local:myUserControl />

     
    and this works perfectly fine. You may have to build the solution once to create the assembly. Till that time designer may give an error.
     
    In the fact the good part in VS 2008 is that when you type in xmlns:local= the intellisense pops up and provides a list of valid inclusions and the one i added, was listed as an option, so i don't even have to figure the right one out and type it.
  • 5 сентября 2008 г. 8:54John Taylor Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     С кодом
    I disagree that this now works in vs2008 sp1.

    I've got an assembly that contains a usercontrol [ucCustomers] that contains a child userControl [ucToolTip].

    The main usercontrol does not render the local clr-namespace in Cider saying that the child usercontrol was not found.
    Here's the namespace bits:

    <UserControl x:Class="CustomerMangementTool.ucCustomers"
    x:Name="userControl"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
    xmlns:local="clr-namespace:CustomerMangementTool">

    when I add the following to the Xaml, the designer breaks:
    <local:ucTooltip x:Name="myTooltipInstance" />

    The error displayed is: Error 1 The type 'local:ucTooltip' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built...

    NOTE: Blend renders fine, and the project compiles and runs no problem...this is a Cider design-time only issue

    Any ideas...


    www.datadaysolutions.com
  • 10 сентября 2008 г. 16:49Marco Goertz - MSFTMSFT, МодераторМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Interesting, that is supposed to work. When you type <local: does the IntelliSense dropdown include ucTooltip?
    Marco Goertz \ Sr. Dev Lead \ WPF Designer "Cider" \ Microsoft
  • 10 сентября 2008 г. 19:19John Taylor Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Nope, no intellisense at all.
    I've also tried "Cleaning" the solution and rebuilding.

    to recap, this happens when I try to work in the designer view with a usercontrol that contains an instance of another usercontrol from the same assembly.
    www.datadaysolutions.com
  • 10 сентября 2008 г. 21:24Brian2p98 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I'm in the exact same boat.  I can't believe something as basic as this would be overlooked by MS.
  • 11 сентября 2008 г. 19:05Marco Goertz - MSFTMSFT, МодераторМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Well, there is something else going on then. I just created a new WPF Application project with 2 UserControls in that same assembly and I was able to use UC2 inside of UC1 and UC1 inside of Window1 with no problems at all.

    Could you try a brand-new project like that?

    BTW, could you also try to invoke the IntelliSense drop-down manually by pressing Ctrl+J or Edit->IntelliSense->List Members?

    Are you getting IntelliSense everywhere else in XAML?
    Marco Goertz \ Sr. Dev Lead \ WPF Designer "Cider" \ Microsoft
  • 11 сентября 2008 г. 19:08Brian2p98 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    The problem was in using an assembly that references another assembly.  I was able to get around this by adding a namespace attribute to the assembly, but I then had to delete the reference in the project using the assembly and re-add it for it to work.  I've noticed this kind of thing a lot--the need to delete stuff and re-add references when there is a problem.  The IDE does not like WPF. 
  • 25 сентября 2008 г. 8:19sn75 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    obviosuly I have now the same problem but in very unexpected circumstances. I have worked on a custom control at home and it all worked fine. Then I packed the whole project and moved it to another computer in the office and now designer fails! Nothing was changed in the project.

    I have VS2008 Team Edition at home and Express in the office (yes, weird but that is the setup I need). Both SP1 and both run on WinXP.

    So it seems to be related a PC-specific issue. Very unfortunate
  • 2 октября 2008 г. 8:32Lina Larsson Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    We have this problem too. We are 4 people working on the same project. The person who added the user control to the project has no problem but every one else (including me) gets the error: Assembly 'CompanyName.ProductName' was not found. Verify that you are not missing an assembly reference. Also, verify that your project and all referenced assemblies have been built. The text in the designer reads: Problem Loading The document contains errors that must be fixed before the designer can be loaded. Reload the designer after you have fixed the errors. 

    This happens in all our xaml-files that references an external assembly. Of course we all have the assembly and can reach it with no problem from the code behind file. We can all build an run the solution. 

    I'm using: 
    Microsoft Visual Studio 2008 Version 9.0.30729.1 SP 
    PresentationFramework.dll 3.0.6920.1453

    We are in the startup of a big WPF project and we really need this to work. If VS2008 can't handle it, are there any other tools that we can use until it works in VS2008? I'm thinking of Blend or even better a free xaml-tool? 


    Regards

    Lina Larsson







  • 1 ноября 2008 г. 12:24Eamon Nerbonne Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Is it possible that this is a x64 issue?  I have a similar issue with a control, but if I set the compilation to x86 it works fine.  I need to support both x64 and x86 separately due to native dependencies, which is another frustrating story - I can't seem to teach VS.NET to use a different reference for x86 and x64.  Basically, the designer is a 32-bit process and can't load 64-bit controls, it seems.

    --Eamon
  • 8 ноября 2008 г. 11:05¢нℓσє Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     Предложенный ответ
    After few days of trial and error, finally managed to display user control on main window.
    If you were using StaticResource on styling certain controls, please use DynamicResource
    I'm using VS.net 2008 in Vista

    Step 1:
    Initially, do as instructed by Atul Gupta

    Step 2:
    Create a ResourceDictionary file at project location (eg. namely 'AppStyles.xmal'). Add in all your style settings.

    Step 3:
    At App.xmal, direct the setting to your ResourceDictionary file (eg. AppStyles.xmal)

    <Application x:Class="ProjectName.App"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        StartupUri="Window1.xaml"       
         >
        <Application.Resources>
            <!-- Merge the Resources & Styles from AppStyles resource dictionaries to share throughout the application -->
            <ResourceDictionary>
                <ResourceDictionary.MergedDictionaries>
                    <ResourceDictionary Source="Resources\AppStyles.xaml"/>
                </ResourceDictionary.MergedDictionaries>
            </ResourceDictionary>
        </Application.Resources>
       
    </Application>

    Step 4 :
    Change / replace all StaticResource to DynamicResource at usercontrol window. Solution rebuild might be needed after that.


    Special thanks to Sacha Barber's excellent demo code at codeproject.com
    www.codeproject.com/KB/WCF/WCFWPFChat.aspx

    Hope this will help.

    • Изменено¢нℓσє 8 ноября 2008 г. 11:06
    • Предложено в качестве ответа¢нℓσє 8 ноября 2008 г. 11:07
    • Изменено¢нℓσє 8 ноября 2008 г. 11:10
    • Изменено¢нℓσє 8 ноября 2008 г. 11:11
    •  
  • 12 ноября 2008 г. 1:52dbollish Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I've encountered a similar issue. I have tracked it down to being a 64-bit issue with the designer. I had a WPF User control project that was being built to both x86 and x64 configurations. When built in X64, the XAML designer cannot find the reference to the control library. The only workaround I could find was to change the project configuration for the WPF User control project to Any CPU insteand of specific x86 or x64 configurations. Is this a known issue with the XAML designer and is it going to be fixed? I can forsee the case where I need to build targeted CPU versions instead of Any CPU so any insight would be appreciated.
  • 25 января 2009 г. 23:04asdf989 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I've got the same problem. BS!!!

     

    I started a new thread about it.

     http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6379d330-f382-4b4d-a690-e89326ab4c72

  • 26 января 2009 г. 22:32asdf989 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Bumping this thread bug until microsoft fixes it!!!

    Its not x64  issue. Its not a 'put ;assembly= at the end of your clr-namespace' issue.

     Here's 4 other threads talking about this.

     
    http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6379d330-f382-4b4d-a690-e89326ab4c72
    http://social.msdn.microsoft.com/Forums/en-US/vswpfdesigner/thread/174000a1-5166-49ea-92db-c02c0a8bcb13
    http://social.msdn.microsoft.com/Forums/en-US/vswpfdesigner/thread/0a244e58-dc0a-4f13-80ce-438f1e135320
    http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/fc02cd12-8e79-46e5-86d0-729fcd31bcac/

  • 26 января 2009 г. 22:47Mark Wilson-ThomasMSFT, МодераторМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    Hi asdf989

    I'm sorry that you're hitting this issue with the WPF designer in Visual Studio 2008 ("Cider"). I'm a Program Manager on the Cider team. I would like to work with you to reproduce the issue you're seeing and ensure it gets appropriate attention.

    It would really help to ensure we are looking at the same problem, if you could construct a simple project which reproduces the issue for you on your machine, then share that project with me by email at mwthomas at microsoft dot com. 

    Thanks

    Mark Wilson-Thomas

     


    Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'
  • 27 января 2009 г. 20:10asdf989 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     

    Wow. Amazing. I'ver never had anyone EVER respond to a post about a bug who could actually do anything about it.

    Cheers. I'll email you right away with a detailed description of the problem.

     

    The summary is:

     

    It must be something wrong with the overall VS 2008 IDE configuation because every demo /sample project I've downloaded is broken in the same way. Its not tied to User controls like I thought. Its a more general failure which may be a good thing oddly enough.

    Broken for me.

    Project 1)

    http://download.microsoft.com/download/f/6/e/f6e32974-726e-4054-96af-9c747bf89a6e/DataBindingLab.exe

    This is microsofts WPF example. Its broken in the same way.

    Project  2)

     http://blog.norberteder.com/dlcounter/Downloader.php?d=54

    This is some dudes wpf binding example. Its broken in the same way.

     

    ScreenShots:

    Project 1)

     http://www.onyx-records.com/private/Boken%20databindinglab.jpg

    Project 2)

    http://www.onyx-records.com/private/Boken%20BindingDemo.jpg

     

    Things I've tried:

    1) Adding assembly to the end like.

    xmlns:local="clr-namespace:BindingDemo;assembly="

    xmlns:local="clr-namespace:BindingDemo;assembly=BindingDemo"

    2) Changing the project to x86

    3) Rebuilding and closing reopening the xaml designer.

    4) Turning off Resharper

     

     What I'm using

    1) VS 2008 SP1 9.0.30729.1 SP

    2) .net framework 3.5 sp1

     3) windows xp pro

    4)resharper (turned off but still installed)

     

     Thanks all I can think to write for now.


     

     


  • 29 января 2009 г. 21:08Mark Wilson-ThomasMSFT, МодераторМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     Предложенный ответ

    Hi all

    working with asdf989, we discovered that the issue was that he had a # character in the path to his projects. Moving to a path without a # in it solved the problem. The designer has problems resolving paths with # in them (this is a known issue).

    I doubt that this is going to be the problem everyone is facing; please let me know if you are facing this problem and do not have a # in your project path; send me mail at mwthomas at microsoft dot com.

    Thanks

    Mark Wilson-Thomas

    Program Manager, WPF+Silverlight Designer, Visual Studio.


    Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'
    • Предложено в качестве ответаJohn Taylor 2 февраля 2009 г. 19:31
    •  
  • 30 января 2009 г. 11:12Eamon Nerbonne Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Does this error always occur with paths with # in them?  I tried including one at home, and it just worked fine...
    --Eamon
  • 2 февраля 2009 г. 18:19John SedlakMVPМедали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I am having a similar problem. I was working with the new WPF controls and was adding the Ribbon after getting the DataGrid to work. It is now saying that it cannot find the RibbonControlsLibrary assembly no matter what I do.

    The weird thing about this is that it was working. It is as if I did something that fubar'd the project. My path does not have any odd characters in it either and the application actually runs fine, it is just the designer and intellisense that are broken. Here is the error.

    Error 1 Assembly 'RibbonControlsLibrary' was not found. Verify that you are not missing an assembly reference. Also, verify that your project and all referenced assemblies have been built. M:\Code\Applications\TaskDestroyer\trunk\MainWindow.xaml 6 13 TaskDestroyer

    Edit: It seems restarting my system fixed the issue...

    http://focusedgames.com
  • 2 февраля 2009 г. 19:31John Taylor Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    My issue WAS down to the # character in the path, we had "c#" as one of the folder names in our VSS tree. Thanks for identifying the issue
    John
    www.datadaysolutions.com
  • 27 марта 2009 г. 17:52Thrash505 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    At first I thought "why would anyone have a # in there path or filenames?". Then I realized that I have all my WPF projects under "C:|_Main\Projects\C# WPF\". I changed the path to "C:\_Main\Projects\CSharp WPF\", rebuilt everything and things worked out just nicely.

    Can someone from Microsoft either fix the '#' thing or at least make this issue more well known. This costed me several hours of wasted time on an issue that was discovered a while ago.

    Thanks,
    Thrash505
  • 7 апреля 2009 г. 16:51u2 Bleank Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I've encountered the same problem with a directory named SourcesC#\  ....
  • 1 мая 2009 г. 7:27Faram Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I had the same problem. I had C# in my projects folder path. Code ran fine, displayed properly in Blend
    but VS2008 xaml designer always gave up with the "assembly not found...." error.
    Changed folder name from C# to Csharp and everything works as it should.
    Thanks for the tip Mark Wilson :)
  • 15 мая 2009 г. 12:25SRLockley Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I am having this problem, and read with interest the issue of path resolution. I have changed the output directories of all my projects to a single ".\bin" directory. This is to resolve runtime referencing problems for dlls written in native c++

    Question. Can the Xaml editor find assemblies that are not output to the default paths that come with VS2008 when you set up a module? 
  • 3 июня 2009 г. 19:26grathad Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Awsome, i don't believe a # in a file name can do the trick, it's the solution for me ... I guess now why all the project on my desktop worked fine and not the real ones in the C# directory.
    Thanks a lot !
  • 28 июня 2009 г. 12:53Shaun Wilson Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I've run into this problem at run-time, works fine in the designer. I suspect it's related to my AssemblyVersion changing on every build. I'm not sure if this qualifies as a framework problem, compiler problem or designer problem.

     


    Shaun Wilson // MySpace.com // Engineering - Infrastructure Group
  • 30 июня 2009 г. 9:34y-spring Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I've run into this problem at run-time, works fine in the designer. I suspect it's related to my AssemblyVersion changing on every build. I'm not sure if this qualifies as a framework problem, compiler problem or designer problem.

     


    Shaun Wilson // MySpace.com // Engineering - Infrastructure Group

    The problem is in the two-pass compilation of WPF projects: If you have a slow PC (or a big project) and you are using version wildcards ( [assembly: AssemblyVersion("1.0.0.*")] ) then you'll end up with an assembly having version "1.0.0.12345" but the .baml-resource nested inside the assembly references "1.0.0.12343" although the original xaml only contained something simple as 'xmlns:local="clr-namespace:Company.AppName"'. (You can verify this with Reflector).
    This can happen with a totaly fresh build -- from time to time you even can have luck and both compilations occur for the same time-number-representation and everything works well 'till the next build.

    Very frustrating because we use version wildcards to ensure that every build only uses the exactly assemblies it was build against.
    holy sig
  • 30 июня 2009 г. 9:37Shaun Wilson Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    My problem was that I had a dyanmic AssemblyVersion attribute combined with signing the assembly.

    You might try adding ";assembly=" to the end of the clr-namespace:.. string to ensure the runtime is checking the calling/owning assembly and not attempting to resolve an external assembly.

    You may also see this if you are using an obfuscator that doesn't "play-well" with BAML/WPF.

    If you provide a verbose exception detail, it may be helpful.

    Shaun Wilson // MySpace.com // Engineering - Infrastructure Group
  • 30 июня 2009 г. 9:58y-spring Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    There is no obfuscation being done. The assembly is signed with a strong key (.snk) but this doesn't affect any version numbers.

    The problem is that every WPF assembly is compiled twice (just look at the MSbuild scripts) -- and the second compilation gets a different version number (this is the bug).

    So I end up at runtime with the following error which clearly states that the baml includes a reference to version "0.906.29.19489" but in fact the resulting assembly got "0.906.29.19492":

    System.Windows.Markup.XamlParseException occurred
      Message=" Die Datei oder Assembly \"MyAppName, Version=0.906.29.19489, Culture=neutral, PublicKeyToken=ec279e9c96512601\" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)  Fehler in Objekt \"System.Windows.ResourceDictionary\" in Markupdatei \"MyAppName;component/app.xaml\", Zeile 10, Position 6."
      Source="PresentationFramework"
      LineNumber=10
      LinePosition=6
      NameContext="MergedDictionaries"
      StackTrace:
           bei System.Windows.Markup.XamlParseException.ThrowException(String message, Exception innerException, Int32 lineNumber, Int32 linePosition, Uri baseUri, XamlObjectIds currentXamlObjectIds, XamlObjectIds contextXamlObjectIds, Type objectType)
           bei System.Windows.Markup.XamlParseException.ThrowException(ParserContext parserContext, Int32 lineNumber, Int32 linePosition, String message, Exception innerException)
           bei System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
           bei System.Windows.Markup.BamlRecordReader.Read(Boolean singleRecord)
           bei System.Windows.Markup.TreeBuilderBamlTranslator.ParseFragment()
           bei System.Windows.Markup.TreeBuilder.Parse()
           bei System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
           bei System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
           bei MyCompany.MyAppName.App.InitializeComponent() in d:\svnWORK\Kundenprojekte\MyAppName\MyCompany.MyAppName\App.xaml:Zeile 1.
           bei MyCompany.MyAppName.App.Main() in D:\svnWORK\Kundenprojekte\MyAppName\MyCompany.MyAppName\obj\Debug\App.g.cs:Zeile 0.
           bei MyCompany.MyAppName.AppRunner.Main() in D:\svnWORK\Kundenprojekte\MyAppName\MyCompany.MyAppName\AppRunner.cs:Zeile 21.
      InnerException: System.IO.FileLoadException
           Message="Die Datei oder Assembly \"MyAppName, Version=0.906.29.19489, Culture=neutral, PublicKeyToken=ec279e9c96512601\" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)"
           Source="mscorlib"
           FileName="MyAppName, Version=0.906.29.19489, Culture=neutral, PublicKeyToken=ec279e9c96512601"
           FusionLog="Der Assemblymanager wurde geladen aus:  C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\\mscorwks.dll\r\nAls EXE-Datei ausgeführt.  D:\\svnWORK\\Kundenprojekte\\MyAppName\\MyCompany.MyAppName\\bin\\Debug\\MyAppName.vshost.exe\r\n--- Ein detailliertes Fehlerprotokoll folgt. \n\r\n=== Zustandsinformationen vor Bindung ===\r\nLOG: Benutzer = ZETEKO\\Markus\r\nLOG: DisplayName = MyAppName, Version=0.906.29.19489, Culture=neutral, PublicKeyToken=ec279e9c96512601\n (Fully-specified)\r\nLOG: Appbase = file:///D:/svnWORK/Kundenprojekte/MyAppName/MyCompany.MyAppName/bin/Debug/\r\nLOG: Ursprünglicher PrivatePath = NULL\r\nAufruf von Assembly : WindowsBase, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.\r\n===\r\nLOG: Diese Bindung startet im default-Load-Kontext.\r\nLOG: Die Anwendungskonfigurationsdatei wird verwendet: D:\\svnWORK\\Kundenprojekte\\MyAppName\\MyCompany.MyAppName\\bin\\Debug\\MyAppName.vshost.exe.config\r\nLOG: Die Computerkonfigurationsdatei von C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\\config\\machine.config wird verwendet.\r\nLOG: Verweis nach der Richtlinie: MyAppName, Version=0.906.29.19489, Culture=neutral, PublicKeyToken=ec279e9c96512601\r\nLOG: Download von neuem URL file:///D:/svnWORK/Kundenprojekte/MyAppName/MyCompany.MyAppName/bin/Debug/MyAppName.DLL.\r\nLOG: Download von neuem URL file:///D:/svnWORK/Kundenprojekte/MyAppName/MyCompany.MyAppName/bin/Debug/MyAppName/MyAppName.DLL.\r\nLOG: Download von neuem URL file:///D:/svnWORK/Kundenprojekte/MyAppName/MyCompany.MyAppName/bin/Debug/MyAppName.EXE.\r\nWRN: Der Vergleich des Assemblynamens führte zum Konflikt: Revisionsnummer.\r\nERR: Das Setup der Assembly konnte nicht abgeschlossen werden (hr = 0x80131040). Die Suche wurde beendet.\r\n"
           StackTrace:
                bei System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
                bei System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
                bei System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
                bei System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
                bei System.Reflection.Assembly.Load(String assemblyString)
                bei System.Windows.Markup.ReflectionHelper.LoadAssemblyHelper(String assemblyGivenName, String assemblyPath)
                bei System.Windows.Markup.ReflectionHelper.LoadAssembly(String assemblyName, String assemblyPath)
                bei System.Windows.Markup.BamlMapTable.GetAssemblyFromAssemblyInfo(BamlAssemblyInfoRecord assemblyInfoRecord)
                bei System.Windows.Markup.BamlMapTable.GetTypeFromTypeInfo(BamlTypeInfoRecord typeInfo)
                bei System.Windows.Markup.BamlMapTable.GetTypeFromId(Int16 id)
                bei System.Windows.Markup.BamlRecordReader.GetElementAndFlags(BamlElementStartRecord bamlElementStartRecord, Object& element, ReaderFlags& flags, Type& delayCreatedType, Int16& delayCreatedTypeId)
                bei System.Windows.Markup.BamlRecordReader.BaseReadElementStartRecord(BamlElementStartRecord bamlElementRecord)
                bei System.Windows.Markup.BamlRecordReader.ReadElementStartRecord(BamlElementStartRecord bamlElementRecord)
                bei System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
           InnerException:

    holy sig
  • 30 июня 2009 г. 9:59y-spring Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     Предложенный ответ
    I forgot to mention: adding ";assembly=" to the xmlns:local reference does not change anything.
    holy sig
    • Предложено в качестве ответаAriën H 18 июля 2009 г. 18:16
    •  
  • 18 июля 2009 г. 18:14Ariën H Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    Hi,

    I ran into a simmular problem. I had good compilible WPF application. After a throw away my 'obj' and 'bin' directory the same error occured. After restoring the 'bin' and 'obj' it compiled again. 
    Is this a egg or chicken problem?!

    Normaly when you build an application from scratch, there is already a dll bofore you add some controls
  • 5 сентября 2009 г. 12:47Sergey Gusak Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I had the same problem as John Taylor, but there was no # symbol. I solved it by specifying "...;assembly=" instead of just "..." in the namespace declaration.
  • 7 сентября 2009 г. 14:59Ramis84 Медали пользователяМедали пользователяМедали пользователяМедали пользователяМедали пользователя
     
    I had this annoying problem as well. I solved it like many others by adding ";assembly=" last on the same line as xmlns for the namespace.