Le réseau pour les développeurs > Forums - Accueil > Visual Studio WPF Designer > "Assembly '...' Was Not Found" When including a reference to a local namespace
Poser une questionPoser une question
 

Traitée"Assembly '...' Was Not Found" When including a reference to a local namespace

  • jeudi 8 mai 2008 05:45Paul Hounshell Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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.

Réponses

  • lundi 12 mai 2008 03:23Atul GuptaMVPMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     Traitée
     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.

Toutes les réponses

  • jeudi 8 mai 2008 09:19AlagurajaPandian Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

     

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

     

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

     

    should work..
  • jeudi 8 mai 2008 11:30Paul Hounshell Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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="
  • jeudi 8 mai 2008 11:44Tim DawsonMVPMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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.

  • jeudi 8 mai 2008 11:58Paul Hounshell Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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

  • lundi 12 mai 2008 02:30Marco Zhou Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    I moved this thread from WPF forum to Cider forum for better answers.

    Thanks
  • lundi 12 mai 2008 03:23Atul GuptaMVPMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     Traitée
     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.
  • vendredi 5 septembre 2008 08:54John Taylor Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     A du code
    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
  • mercredi 10 septembre 2008 16:49Marco Goertz - MSFTMSFT, ModérateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mercredi 10 septembre 2008 19:19John Taylor Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mercredi 10 septembre 2008 21:24Brian2p98 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    I'm in the exact same boat.  I can't believe something as basic as this would be overlooked by MS.
  • jeudi 11 septembre 2008 19:05Marco Goertz - MSFTMSFT, ModérateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • jeudi 11 septembre 2008 19:08Brian2p98 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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. 
  • jeudi 25 septembre 2008 08:19sn75 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • jeudi 2 octobre 2008 08:32Lina Larsson Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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







  • samedi 1 novembre 2008 12:24Eamon Nerbonne Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • samedi 8 novembre 2008 11:05¢нℓσє Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     Réponse proposée
    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.

  • mercredi 12 novembre 2008 01:52dbollish Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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.
  • dimanche 25 janvier 2009 23:04asdf989 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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

  • lundi 26 janvier 2009 22:32asdf989 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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/

  • lundi 26 janvier 2009 22:47Mark Wilson-ThomasMSFT, ModérateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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'
  • mardi 27 janvier 2009 20:10asdf989 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     

    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.


     

     


  • jeudi 29 janvier 2009 21:08Mark Wilson-ThomasMSFT, ModérateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     Réponse proposée

    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'
    • Proposé comme réponseJohn Taylor lundi 2 février 2009 19:31
    •  
  • vendredi 30 janvier 2009 11:12Eamon Nerbonne Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    Does this error always occur with paths with # in them?  I tried including one at home, and it just worked fine...
    --Eamon
  • lundi 2 février 2009 18:19John SedlakMVPMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • lundi 2 février 2009 19:31John Taylor Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • vendredi 27 mars 2009 17:52Thrash505 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mardi 7 avril 2009 16:51u2 Bleank Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    I've encountered the same problem with a directory named SourcesC#\  ....
  • vendredi 1 mai 2009 07:27Faram Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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 :)
  • vendredi 15 mai 2009 12:25SRLockley Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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? 
  • mercredi 3 juin 2009 19:26grathad Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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 !
  • dimanche 28 juin 2009 12:53Shaun Wilson Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mardi 30 juin 2009 09:34y-spring Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mardi 30 juin 2009 09:37Shaun Wilson Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mardi 30 juin 2009 09:58y-spring Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • mardi 30 juin 2009 09:59y-spring Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     Réponse proposée
    I forgot to mention: adding ";assembly=" to the xmlns:local reference does not change anything.
    holy sig
    • Proposé comme réponseAriën H samedi 18 juillet 2009 18:16
    •  
  • samedi 18 juillet 2009 18:14Ariën H Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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
  • samedi 5 septembre 2009 12:47Sergey Gusak Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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.
  • lundi 7 septembre 2009 14:59Ramis84 Médailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateurMédailles de l'utilisateur
     
    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.